|[2 earlier articles]|
|Re: Compilers in six hours firstname.lastname@example.org (1994-05-17)|
|Re: Compilers in six hours email@example.com (1994-05-18)|
|Compilers in six hours firstname.lastname@example.org (1994-05-18)|
|Compilers in six hours email@example.com (1994-05-19)|
|Re: Compilers in six hours firstname.lastname@example.org (1994-05-19)|
|Re: Compilers in six hours chase@Think.COM (1994-05-19)|
|Re: Compilers in six hours email@example.com (1994-05-20)|
|Re: Compilers in six hours firstname.lastname@example.org (Stefan Monnier) (1994-05-22)|
|Re: Compilers in six hours email@example.com (1994-05-24)|
|Re: Compilers in six hours firstname.lastname@example.org (1994-05-24)|
|Re: Compilers in six hours email@example.com (1994-05-25)|
|Re: Compilers in six hours firstname.lastname@example.org (1994-05-26)|
|From:||email@example.com (Henry G. Baker)|
|Date:||Fri, 20 May 1994 13:19:36 GMT|
firstname.lastname@example.org (Steve Simmons) writes:
>> 6. Actually doing a good job of machine-language generation nowadays is
>> probably nasty enough to justify a course in itself.
Generating machine-language that works is not difficult, and in many ways
easier than generating C (e.g., in C you have to worry about overrunning
the C compiler's statement length and parser stack limitations, and about
guaranteeing the proper ordering of side-effects). This is especially
true if you have a decent assembly macro system to build your own little
'mini-machine', which has no overlapped operations, no branch delay slots,
etc. The hard part, of course, is to generate machine language that
actually runs faster than the compiled (and optimized) C.
I would imagine that for many students, the problem is that you have to
know the machine language pretty well before you can generate code in it,
and many of the students may not be that experienced in assembler.
Return to the
Search the comp.compilers archives again.