🚀 go-pugleaf

In article <4375@mit-eddie.MIT.EDU> rh@eddie.MIT.EDU (Randy Haskins writes:
> 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. 

Good point.  On the other hand, any procedure which is called only
once (such as those used to provide structure) will run faster and
be smaller if expanded inline.



> 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

Yes, clever code, but be careful not to mistake saving space in the
small for saving space in the large.  If the routine were duplicated,
it would cost only a few extra instructions, in other words not much.
Programs get much bigger usually by more global design choices, and
these little optimizations don't contribute much one way or the
other.  As with coding speed, it's the *big* decisions that matter,
and this isn't one of them.

cheers,

txr