Re: Adding block scopes to an assembly language

htak@eskimo.com (Henry S. Takeuchi)
1 May 2000 13:16:05 -0400

          From comp.compilers

Related articles
Adding block scopes to an assembly language d_ross@iders.mb.ca (Derek Ross) (2000-04-27)
Re: Adding block scopes to an assembly language d_ross@iders.mb.ca (Derek Ross) (2000-04-29)
Re: Adding block scopes to an assembly language rhyde@shoe-size.com (Randall Hyde) (2000-04-29)
Re: Adding block scopes to an assembly language htak@eskimo.com (2000-05-01)
| List of all articles for this month |

From: htak@eskimo.com (Henry S. Takeuchi)
Newsgroups: comp.compilers
Date: 1 May 2000 13:16:05 -0400
Organization: Eskimo North www.eskimo.com (800) 246-6874
References: 00-04-206
Keywords: assembler, symbols

On 27 Apr 2000 10:51:41 -0400, Derek Ross <d_ross@iders.mb.ca> wrote:


>I'm interested in giving block scopes to an assembly language, in
>particular for the ADSP2181 dsp.
> [...snip...]
>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
>labels.


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.
> {...snip...}
> 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
Seattle, Washington
(USA)
[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]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.