Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!rh
From: rh@mit-eddie.MIT.EDU (Randy Haskins)
Newsgroups: comp.lang.misc
Subject: Re: Assembly language and Speed...
Message-ID: <4375@mit-eddie.MIT.EDU>
Date: Wed, 24-Dec-86 22:06:13 EST
Article-I.D.: mit-eddi.4375
Posted: Wed Dec 24 22:06:13 1986
Date-Received: Thu, 25-Dec-86 00:36:18 EST
References: <1233@navajo.STANFORD.EDU> <464@unc.unc.UUCP>
Reply-To: rh@eddie.MIT.EDU (Randy Haskins
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 26
Keywords: Space
Summary: There are other issues...

There are problems with INLINE, however.  I have forsaken the
world of big things and started writing code for PC's, and for
the first time in my life, have to give serious thought to trading
speed for space in some cases.  Inline coding may be faster, but
it takes up more space.  The coder has to decide the relative
importance for each case. 

Just to add to the argument, here is an example of what a human can do
that I'd seriously doubt that a compiler would do.  I first saw something
like this in some local hacks to the Monitor for a Tops-20 at MIT.  At
first, I was offended, but then I saw the sheer elegance of it.

PRSPC:	Skipa	T2,[32.]	; move a space into 2, skip next instruction
PRTAB:   Movei  T2,9.		; put a tab in 2
        Movei   T1,.PRIOU	; primary output
	Bout%			; byte output
	 Ercal  .+1		; ignore error
	Popj    P		; return

Not only does it avoid having to make an extraneous jump or call (in order
to use common code), it saves space.  Would a compiler "know" to do something
like this?  I doubt it.

Random
-- 
Randwulf  (Randy Haskins);  Path= genrad!mit-eddie!rh