Re: Adding block scopes to an assembly language

"Randall Hyde" <rhyde@shoe-size.com>
29 Apr 2000 23:55:15 -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: "Randall Hyde" <rhyde@shoe-size.com>
Newsgroups: comp.compilers
Date: 29 Apr 2000 23:55:15 -0400
Organization: Compilers Central
References: 00-04-206
Keywords: assembler

> I'm interested in giving block scopes to an assembly language, in
> particular for the ADSP2181 dsp.


Can't help you with that, but you might want to take a look at the
way I did it in HLA (the High Level Assembler) for the 80x86.
see http://webster.cs.ucr.edu for details.


.. snipped examples..


> But my question is, "what is the proper way to go about this?" I could
> start hacking away with a C compiler, but I suspect that would take much
> longer than is necessary.
>
> Are LEX and YACC the way to go? If yes, what would be overall scheme to
> accomplish this?


I'm assuming (unlike John's reply) that you don't have access to the
sources for the existing assembler. Let me make a few suggestions
about your two choices above.


(1) I wrote HLA using Flex and Bison. That was the biggest mistake I
ever made. Now HLA's source code is not a wonder of software
engineering (in fact, it's a prototype and, by definition, awful);
however, I could have done much more using only C/C++ with half the
statements.


(2) Flex and Bison are affectionately known as "the 80% solution." In
my experience, that other 20% really kills you. You will be able to
hack together a quick program that does what you want using Flex and
Bison (i.e., a prototype). But if you want to make it robust, have
good error checking, etc., forget Flex and Bison; IMO they're more
trouble than they're worth.


(3) Plan on extending your language. Today you need BEGIN and END.
Tomorrow you will probably want to enhance it a bit. Whatever you do,
don't cave in to the "Quick & Dirty" siren call; you will definitely
regret this later. E.g., the HLA system contains between 150,000 to
200,000 lines of source code; I'd originally expected it to be on the
order of 50,000 lines. Obviously, things got out of control.


(4) I don't know how you debug your code, but do keep in mind that
your preprocessing is probably going to mess up the symbols that are
fed as input to a symbolic debugger (assuming you use one). I'd
strongly recommend using named blocks, e.g.,


BEGIN thisblock;
        .
        .
        .
END thisblock;


and merging the block identifier ("thisblock" in the example above)
with the new ID you generate. This will help reduce the debugging
effort.
Randy Hyde


Post a followup to this message

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