Re: gnubol: Re: Cobol Compiler Suggested Tasks

[Tim Josling <tej@melbpc.org.au>]

Matthew Vanecek wrote:

> There will be a lot of similarities in the different types of I/O...,
> so we should be able to reuse a lot of
> code.

Yes and this will make it simpler for everyone too. And common
error message layouts etc.

> 
> mmmm, S/390 assemblerrrrr.... Always seemed much easier to me than does
> x86 assembler, for what little I know, anyhow.

How do others do packed decimal? With subroutines. None of the
free compilers use packed decimal instructions. I know Ada does
not for sure. 

There is a version of gas for 390, but I don't know which
instructions it supports. I know the x86 one does not support the
packed to binary instructions. 

GCC is based on the concept that everything is done in registers.
This causes problems for machines that have instructions that do
not involve registers (eg 390 MVC, CVD, AP etc; also java chips
which are stack based). For the 390 one solution is to use inline
assembler code in some manner (gcc does this already for eg
memcpy on certain platforms - there are about 20-30 of these
'BUILTINS'). 

> 
> Tim,
> I was kindof wondering, how many passes over the code does the parser
> do?

There is the preprocessor, which is analagous to the C
preprocessor and takes care of continuation lines, copy, replace,
removes comment-entries (like AUTHOR etc) etc. That outputs a new
text file that is pretty clean in format, it passes line numbers
through (although the main compiler ignores them at the moment).

In the compiler proper, there is not really a 'pass' concept in
the sense that older compilers used it. This was largely a way of
managing very limited memory plus tapes. My model is this:

a) Read file into memory.

b) lexical analysis and keyword detection (dependent on the
dialect selected eg pedantic will only recognize ansi standard
keywords - see cobclex.l). This outputs a linked list of tokens.

c) Parse up to procedure divison. This fills in a basic symbol
table needed for the hacks in (d). It also creates part of the
parse tree. 

d) Hack tokens in procedure division to allow parsing with bison
to work (ie magic tokens to give bison some help with what's
coming up).

e) Parse procedure division, completing the parse tree. The parse
phase does as little as possible, beyond build the parse tree.

f) Build full symbol table, analyse the parse tree to check all
references are there and are valid and unique. Minimal work done
here at present.

g) Convert parse tree into something closed to the gcc TREE
concept - ie simplify the constructs into smaller units like
move, add, if from the original constructs like search, perform
etc. This phase tiny at the moment. Minimal work done here at
present.

h) Cobol specific optimization. Nonexistant at present.

i) Interface to gcc tree to optimize and output the code.

So the bottom line is that you will have access to all the parse
information at once, and there should be no issue with being
constrained by the number of passes. I hope this helps.


Tim Josling

--
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.