|Adding block scopes to an assembly language email@example.com (Derek Ross) (2000-04-27)|
|Re: Adding block scopes to an assembly language firstname.lastname@example.org (Derek Ross) (2000-04-29)|
|Re: Adding block scopes to an assembly language email@example.com (Randall Hyde) (2000-04-29)|
|Re: Adding block scopes to an assembly language firstname.lastname@example.org (2000-05-01)|
|From:||email@example.com (Henry S. Takeuchi)|
|Date:||1 May 2000 13:16:05 -0400|
|Organization:||Eskimo North www.eskimo.com (800) 246-6874|
On 27 Apr 2000 10:51:41 -0400, Derek Ross <firstname.lastname@example.org> wrote:
>I'm interested in giving block scopes to an assembly language, in
>particular for the ADSP2181 dsp.
>What I want to do is to create two keywords, BEGIN and END, for the
>code, and then apply a preprocessing step to properly expand the
And our moderator wrote:
>[... Adding simple block structure is not very hard. One way to do it is
>to tag each symbol with the block where it's defined. Keep a block
>counter and a stack of active blocks.
> When looking up a symbol, search for the symbol
>with the block on the top of the stack, if not found with the next one
>on the stack, etc. until you run out of stack or find it. -John]
There is a little more to this because of forward referenced labels,
which are so prevalent in assembly language code.
In a single pass design, forward labels cannot be resolved until the
label is defined. Undefined labels cannot be detected until the end
of a block. At this point, you can promote the as-yet undefined
labels to the next block level.
In a multi-pass design, the forward labels must be defined in the
symbol table with their defining block numbers. Or else the symbol
table must be partitioned, one partition per block. In the latter
case, a stack of symbol table partitions must be kept.
Much like keeping the symbol table information for C++ structs and
classes, the symbol table information cannot be discarded at the end
of the block. (There's no point in defining them in the first pass,
if you undefine them before resolving them in the second.)
Henry S. Takeuchi
[It's true, either you make two passes which is the the traditional
approach, or you keep chains of unresolved references and backpatch
when they're resolved. In these days of gigantic main memories I'd be
inclined to slurp in the whole file and then make two passes over the
in-memory data. -John]
Return to the
Search the comp.compilers archives again.