|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 email@example.com (1988-01-04)|
|Re: Assemblers can be fast firstname.lastname@example.org (1988-01-15)|
|From:||email@example.com (Ian Donaldson)|
|Date:||4 Jan 88 23:54:17 GMT|
|Organization:||RMIT Comm & Elec Eng, Melbourne, Australia.|
in article <813@ima.ISC.COM>, says:
> Real computers aren't limited to 640K :-). And if anybody wrote a 640K
> assembly language program all in one file, and really expected my
> assembler to assemble the darn thing, I'd have to say that they got
> what they deserved :-). There's always a limit, somewhere -- if it ...
Compilers that emit assembly language -often- create megabyte sized files
for the assembler.
> But, seriously... one-pass assembling isn't extremely difficult. What
> you do is, on the first pass, emit object code with "fillers" for
> expressions you couldn't evaluate, and in memory, you keep a symbol
This 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 worthwhile.
Return to the
Search the comp.compilers archives again.