Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool2.mu.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.bugs.sys5
Subject: Portable code generation (was: Reference ports, etc...)
Message-ID: <3403@lupine.NCD.COM>
Date: 20 Jan 91 08:52:11 GMT
References: <5208@auspex.auspex.com> <11368@hobbit.UUCP> <5291@auspex.auspex.com>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 23

In article <5291@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>I believe that's what Sun and AT&T thought, but I can imagine
>>existing COFF-producing retargetable code generators and other such
>>tools which could be ported to SPARC much more easily if the supplier
>>did not have to change object formats at the same time.
>
>That's one nice thing about having your compilers generate assembler
>code rather than object code - they don't have to know quite so much
>about object-file formats, because they leave that knowledge up to the
>assembler....

Yes, but unfortunately they *do* still have to know quite a bit about
the type of *debugging information* required by the target system.

For example, on V.4, your compilers don't have to be terribly ELF-smart
but it does help if they are DWARF-smart.  Making them so can be quite
time consuming.  Take it from me.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.