|Assemblers can be fast yale!harvard!ames!hplabs!hpccc!culberts (Bruce Culbertson) (1987-12-16)|
|Re: Assemblers can be fast ihnp4!usl!usl-pc!jpdres10 (Green Eric Lee) (1987-12-19)|
|Re: Assemblers can be fast ucbvax.Berkeley.EDU!sun!wrs!dg (1987-12-22)|
|Re: Assemblers can be fast firstname.lastname@example.org (1988-01-04)|
|Re: Assemblers can be fast email@example.com (1988-01-15)|
|From:||firstname.lastname@example.org (Andrew Klossner)|
|Date:||15 Jan 88 17:10:59 GMT|
|Organization:||Tektronix, Wilsonville, Oregon|
> "This [one-pass assembly with fixup chains] is easy if you
> don't have to worry about instructions that change their size
> depending on the expresison value (eg long, short and medium
> branch instructions). Many assemblers spend time optimizing
> such branches, and this generally requires an extra pass to do
> it properly. The gains of optimizing such branches are really
Branch length optimization is a win, but you don't need multiple passes
to do it. I recently wrote a one-pass assembler with various sorts of
span length optimization. There was nothing particularly clever
involved; I just told myself firmly that I wasn't going to do multiple
passes, and after some thought the necessary algorithms became clear.
It helped, but was not vital, that I had a large virtual memory space
and so didn't need to bother with temporary files.
In general, a good guiding principle is that it's much quicker to
review your generated object code in conjunction with in-memory tables
than it is to make another pass over the source code.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
Return to the
Search the comp.compilers archives again.