Re: High Level Assemblers vs. High Level Language Compilers

"Randall Hyde" <rhyde@cs.ucr.edu> writes:
>>> since C is really just a very very high level macro assembler.
>
>I totally agree with Alfred. C is a terrible macro assembler simply
>because it's macro facilities are so weak...


Um... note the number of ">" thingeys. the article you're quoting was
disagreeing with this statement and making a distinction between high
level assembly -- which would be more appropriately termed high-level
memory image formatting -- vs. compilation.


In the former case, the code directs the formatting of memory images,
in the latter case the code IS the memory image (modulo translation).


The closest equivalent to high-level assembly would be if the C
macro processor, itself, were made into a full-fledged programming
language.


>>There were two major problems which were unresolved which blocked
>>that line of development: (1) a comprehensive scheme for properly
>>handling the weirdness associated with the way assemblers allow for
>>references to yet-to-be-defined addresses but yet allows them to
>>be used in assembler directives and expressions (a VERY nasty
>>recursion issue lurks beneath this),
>
>This problem doesn't get resolved via multi-phase assembly? Maybe I
>don't understand the exact nature of the problem you are describing.


Code such as this:


segment A:
...
If (address A1 - address B1 < 1000) {
      generate this code
} else {
      generate this code
}
A1:
...


segment B:
...
B1:
...


which illustrates, actually, both major issues: (1) the resolution of
conditional code generation in the presence of forward or unresolved
references and (2) the problem of resolving conditional code
generation in the presence of references that are only made available
at LOAD TIME (e.g., if the absolute addresses of the segments are only
defined by the loader).


This is only the simplest example of this kind of phenomenon.


Either the general problem must be dealt with or it must be avoided or
limited by the use of more or less ad hoc expediencies, such as the
one commonly used by assemblers (of distinguishing pass 1 time
assembly from pass 2 time).


>In HLA, I differentiate these two *VERY DIFFERENT things* by referring
>to them as the "compile-time language" and the "run-time language".


Right. The former gives you a high-level assembler. The latter a
compiler. What you're calling HLA is actually a mix of the two,
since you're doing some compilation of high level source language
(your "run time language").


>Our definitions of a "high level assembler" definitely diverge at this
>point. You're after a "reconfigurable assembler" (i.e., you want to
>provide a parser generator as part of the package).


Reconfigurability and high-levelness in a high-level assembler are
in essence all about the same thing. The main benchmark test of a
high-level code generator tool is whether it can (in principle) define
the entire binary formatting for the mnemonics of the given CPU by macros.


A parser generator of not needed even for a universal assembler.
At most, you require a general syntatic framework for expression
syntax:


Ex -> "(" Ex ")" | [Ex] "[" Ex "]" | Ex "?" Ex ":" Ex | "{" Ex "}"
            unary Ex | Ex binary Ex | Ex postfix | constant


plus a set of assemble-time directives for defining arities and
precedences, exactly as in Prolog:


Prefix: fx Op, Prec; fy Op, Prec
Postfix: xf Op, Prec; yf Op, Prec
Infix: xfx Op, Prec; xfy Op, Prec; yfx Op, Prec


>>define move(accum + @ (reg R), #D) { ... }
>>
>>which matches (for instance) to "move A + @R3, #35.
>
>Overloaded macros is something HLA doesn't directly support, though
>overloading is not necessary to do what you're trying here.


All processors define overloaded mnemonics. So, it's an absolute
necessity in order to reach the benchmark.


>I'd been working on HLA for a couple of years when this post appeared
>(indeed, HLA v1.0 was released around September, just two months
>later), but John concisely sums up the reason I designed and
>implemented HLA in the first place.


C-AS came out in 1992 and these issues were discussed extensively
here over the last decade.

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