Sorry, wrong list.
David Essex wrote:
> Jeff Chimene wrote:
>
>
>
>>That's certainly the approach I'd take if I
>>was starting from scratch.
>
>
> Well, actually NOT from scratch.
> You have a scanner/parser, run-time, syntax tree.
> I would say about 40-50% complete. Over optimistic ? Maybe.
>
> In any case I think it can be done, with the proper sponsor, financing.
>
>
> > The biggest hurdle I see is official incorporation into GCC.
> > Perhaps that's not as big a hurdle as it seems.
>
> Not likely to happen any time soon.
> But then again, other compilers use the GCC back-end.
> Some, such as GCC-Pascal, eventually became part of GCC (FSF supported
> projects).
>
>
>
>>On the debugging side, here is another possible approach. It's
>>basically the one that's appeared in various guises in this thread:
>>http://www.mono-project.com/Debugging
>>
>>Ignoring the JIT stuff, it would seem that cobc is well on the way to
>>supporting the necesary call-backs as demonstrated by those Python
>>data dump routines.
>>
>>Given the wealth of scripting languages supported by OC, it's really a
>>matter of designing and implementing useful COBRTL routines for them
>>to call.
>>
>>COBOL_OC_DUMP is certainly useful.
>
>
> Which ever approach chosen, you still have to find a way to pass
> debugging information (COBOL->C->binary-object).
> No small task, I don't think.
>
> Perhaps the simplest possible approach is to add 'READY/RESET TRACE'
> COBOL extension. In combination with 'DISPLAY', it is a good tool for
> debugging classic type COBOL programs.
>
>
> Cheers.
|
