Re: gnubol: good work in the preprocessor

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

Bob,

Thanks for the kind words and the feedback. Good pick up on the yytext bug. I
think I have a way around that that won't cause too much grief.

By the way the cobgo* modules are just experimental, to try out btyacc and the
parser issues we have been discussing. Thus the "xxx;" reminders to fix up
things. The cobgp* modules are the preprocessor and should be in better shape.

As for performance, I will tune later. I am adopting the XP principle of the
simplest thing that can possibly work. At present on my PII-333 the preprocessor
does 10,000 lines in under one second, and with 10mb peak used. So on my (128mb)
machine I could do 100,000 lines in 10 seconds.

The MVS COBOL compiler does several IOs per line of code (from memory, anyway it
is heaps). This is to save memory. But it costs cycles and time. My approach is
if you have a 1,000,000 line program, get 1gb of ram.. If you have a 2,000,000
line program, I doubt anyone can help you.

Of course on a mainframe that is too costly. But I am not going to hand code a
compiler in assembler which is the only answer for the golden MIP machines. Nor
do I intend to write a STOW macro, ever again.

Eg. In the preprocessor. I read the whole file into memory. I lex it into tokens
in memory. I do no freemains (but I could). You optimistically assumed I only
have a few tokens active at a time, but it isn't true.

Maybe I am building some things that are hard to tune but I taking the risk. In
the compiler I will try harder to separate the layers as you suggest, and it
should be easier there than in the preprocessor.

In the preprocessor, specifically the REPLACE verb, it is mangling tokens from
across lines and files, so line/file/charno is a token attribute. Anything else
would be more complex and slower I think.

As you recognised I am trying to get to a point of critical mass ASAP. So I ask
your indulgence to a certain extent.

I hope this isn't too incoherent. I have jet lag and took a sleeping tablet a
while ago...

I started on the bison parser for the nucleus today. I intend to find the bad
conflicts and add magic tokens to fix them. The magic tokens represent some kind
of manual fixup (eg distinguishing 88 levels from data items; identifying things
that have reference modifications; some of the if processinr etc). I don't
suggest this is viable but at least I will know where I stand.

Tim Josling

RKRayhawk@aol.com wrote:

> ...Lots...


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