gnubol: Cobol internals consideration

["Glen Colbert" <gcolbert@uswest.net>]

> Original Contributor not defined:
> The COBOL to C, would give us a compiler, since you would end up with
> binaries produced by GCC. We would have, in effect, a COBOL compiler
> with a software which first parsed to C, and then used GCC to produce
> the binaries. It gets the COBOL to binary machine language, therefore
> it does the job. There are benefits to doing it this way, such as
> portability. This would allow the COBOL compiler to be very easily
> used on a wide variety of computer hardware very easily, for the
> compiler to also be moved to new archectures easily as well.
> In fact,> many of the other GNU compilers

Which ones?

> for various langauges are designed in this matter.


I would like to first acknowledge Tim and Fred and Fred and others who have
responded to my initial posting of anyone working on Cobol.  I really do
understand that building a compiler on a solid foundation is vital to
developing a tool that can last as long as Cobol has.

Cobol was never meant to be a programmer environment.  The important
consideration has always been what happens in memory at runtime.  The
problem with converting Cobol to 'C' is that 'C' requires data typing.
Cobol doesn't really define data types, but rather simply defines memory
usage.  Doing this is 'C' could be accomplished by defining the entire
WORKING-STORAGE section as one large structure, with structures and unions
used to provide for REDEFINES.  'C' data types as intermediate storage
during move and manipulation operations will result in numerous differences
in run-time results (rounding, truncation, etc.)  This will be further
exacerbated in moving from platform to platform where _int_ is no longer the
same as _int_ and long no longer means long.

A 'C' version of WORKING-STORAGE would be better defined as a single large
character array, with the variables being defined by their type, offset, and
length into the array.  This would, basically, undo any 'C' data typing.
Each manipulation (moves, addition, etc.) would be performed on a character
by character operation.

A 'core dump' of an aborted program should show the memory exactly (byte by
byte) as defined in the WORKING-STORAGE and other data section.

Writing an assembler in 'C' is a different thing than writing a Cobol to 'C'
translator.  The compiler should not require a separate 'C' compilation to
create an executable (although most generate assembler output).  If GNUcobol
is going to interface into the standard debugging tools as Cobol (and not as
'C'), I believe that this approach will be required.

Porting to all of the potential assembler formats is a considerable task.
One approach to minimize this task could be to write a 'virtual machine'
that executes the compiler's 'assembler output' and call it part of the
run-time system.

I feel that a better approach is to go directly to assembler.  Because of
the relative simplicity of the low-level Cobol operations, this would not be
as significant a task as it would be for most other languages.  This would
only be true, however, if the run-time entry points, procedures, and
functions were kept simple and VERY well documented.

The best approach might be to write the first iteration using the 'virtual
machine' concept, then port virtual machines to real machines in a phase II.

Writing a 'virtual machine' in 'C' provides all of the portability of using
gcc as an intermediate compiler, while allowing for full integration with
standard debugging tools at a later date.  Taking the Cobol to 'C' approach
will require a complete re-engineering later in the project.


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.