Re: gnubol: procedure types

[Tim E Josling <TIMJOSLING@prodigy.net>]

I did toy with the idea of putting more into the preprocssor. Why not?

1. You need to do a rescan because the definition of token is different in the
preprocessor than in the compiler proper. For example, in the preprocessor, PIC
9(1) is 4 tokens. In the compiler it is 2 tokens. This allows

 REPLACE ==MAX_LENGTH== by ==100==.

 pic x(MAX_LENGTH).

The rescan is sensitive to intervening spaces. This gets quite ugly to do from
the existing token list. I had to do some of this because some tokens need to be
rescanned because replace or capy replacing can turn two tokens into one or vice
versa..

The output phase of the preprocessor just takes the list of tokens and outputs
them, taking care of spaces, new lines, debugging lines etc.

2. Memory management. If I added a lot more to the preprocessor, I would need to
think about doing some freemains. Which would be a lot of work.

3. Ugliness. The preprocessor is not that pretty and I would not do everything
the same way again.

4. Not a big deal performance wise. In Unix or DOS/Win file IO is buffered so
usually the work files between the phases (preprocess, compile, assemble, link)
do not make it to disk.

In the compiler itself, I already have the code to read the tokens into a list,
post lexical analysis. That is where I am planning to do the things you are
talking about (eg adding the magic tokens to help bison).

Once I have a tree built out of the parse, some validation (eg that the data
division level structures are kosher), build the symbol tables, more validation
that needs the symbol tables. Then send it to GCC-back end.

Tim Josling

RKRayhawk@aol.com wrote:

> ... - putting more into the preprocessor
> ... - reducing IO





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