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