Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdahl!amdcad!news
From: news@amdcad.AMD.COM (Network News)
Newsgroups: comp.lang.c
Subject: Re: Portability across architectures..
Message-ID: <22937@amdcad.AMD.COM>
Date: 15 Sep 88 16:05:46 GMT
References: <103@simsdevl.UUCP> <7038@bloom-beacon.MIT.EDU> <3942@bsu-cs.UUCP> <1988Sep14.230820.28652@utzoo.uucp>
Reply-To: tim@crackle.amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc., Sunnyvale CA
Lines: 25
Summary:
Expires:
Sender:
Followup-To:

In article <1988Sep14.230820.28652@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
| In article <3942@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
| >1.   ASCII text is likely to be very bulky.
| 
| The question is whether reducing the bulk somewhat (often not as much as
| you'd think) is worth the complications that result.  This is one of those
| cases where the right thing to do is to implement it the obvious way, then
| measure it to find out whether you NEED anything better.  Often you don't.

This was the conclusion of David Hansen of the University of Arizona,
when he proposed a linker that worked with ASCII object files rather
than some arcane binary standard.  It allowed the object modules to be
viewed and edited with standard tools, and was quite compact, because
many data constants could be written in one or two ASCII bytes, which
would have taken up a full word of memory when stored as binary.

In addition, macros allowed small text strings to represent the ascii
encodings for instructions, so they also took up little space.  This
also allowed the entire assembly phase to be bypassed, since the linker
could understand a language that looked reasonably like standard
assembly.

	-- Tim Olson
	Advanced Micro Devices
	(tim@crackle.amd.com)