Re: Compiling forward references
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 30 Aug 2007 15:35:08 +1200
"Robert" <no@xxxxxx> wrote in message
news:s69cd3pnb0j1b3dpqqht8thtl8osesjji7@xxxxxxxxxx
Does this look like a worst case?
01 a LIKE b.
01 b LIKE c.
01 c LIKE d.
...
01 y LIKE z.
01 z PIC X.
A simple-minded compiler would take 25 forward sequential scans to resolve
a. If the
compiler ran every other scan backwards, definitions would be resolved in
two passes, but
that's not a good solution either.
The right solution would put the names a, b, c ... z into a tree or hash
table, with a
link to definitions in the source program. Think of it as a dictionary, if
that helps.
Then the resolution is not done by multiple sequential passes of the whole
source code but
rather by high speed lookups.
Compilers already do that. When they compile MOVE a TO b, do you think
they find a and b
by sequentially reading through the source? Of course not.
Given that compilers already have a tool for rapidly finding names,
resolving meta
references can be done with recursive invocation of that tool. When a
needs the definition
of b, push the context, search for b, receive b's definition, pop context,
replace LIKE
phrase with definition.
If the stack overflows, you've got a circular reference.
I don't understand why such a simple problem is causing heartburn.
Neither do I. :-)
That means that either, there are people here who would rather have a
problem than a solution (it adds meaning to their lives, perhaps...:-)), or,
the rest of us simply don't understand the problem...
Pete.
--
"I used to write COBOL...now I can do anything."
.
- References:
- Compiling forward references
- From: Robert
- Compiling forward references
- Prev by Date: Compiling forward references
- Next by Date: Re: CONSTANT ENTRY (was "forward" references (was: COBOL subscript range checking))
- Previous by thread: Compiling forward references
- Next by thread: Re: Compiling forward references
- Index(es):
Relevant Pages
|
