Direct generation of object code (was: UNIX assemblers and SCO)

[Eric Schnoebelen]

In article <10770013 at hpcupt1.HP.COM> vandys at hpcupt1.HP.COM (Andrew Valencia(Seattle)) writes:
-/ hpcupt1:comp.unix.microport / mike at cimcor.mn.org (Michael Grenier) /  5:28 am  Feb 15, 1989 /
->I'm currently considering supporting the UNIX 386 market with a
->pascal compiler I have running under Microport V/AT. It will
->generate assembly language output from the compiler which will
->call up the assembler to generate the binary much in the same
->way as pcc does.
-
-	Just a small side note.  You will find that generating object or
-even executable code DIRECTLY from the compiler spiffs up overall performance
-quite a bit.  Since they're going for object compatibility across all the
-unices available for the '386 architecture, it seems like a better place
-to hook in.
-
-				Just a though...
-				Andy
-				...!hplabs!hpisoa1!vandys

	Further thoughts on directly generating object code.

        What happens when AT&T, in their infinite wisdom, changes object
code formats from COFF to something else?  ( which I understand is to
happen with System V release 4 or 5. ) It's now time to rewrite the
object code generator for the compiler.  Generating as(1) source keeps
all of that sort of stuff out of the compiler writers hair ( and they
have enough stuff in their hair as it is...  ) Let as worry about the
object file format, and have all the compilers generate as(1) source,
and start up as(1).

        Just think, if the MS-DOS world had standardized on one
assembler, with an enter and leave pseudo instructions, it wouldn't be
so hard today to link together products from different compiler
vendors...

	Food for thought,
		Eric.
-- 
Eric Schnoebelen
egsner!eric at texbell.uucp			...!texbell!egsner!eric
egs at u-word.dallas.tx.us				...!killer!u-word!egs
"All this science, I can't understand; It's just my job 5 days a week"