From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 4 Sep 92 17:49:36 GMT
Article-I.D.: mulga.9224903.16502
Organization: Computer Science, University of Melbourne, Australia

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:

>In article <9224507.14644@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>
>>>In article <1992Aug28.222616.2251@merlin.dev.cdx.mot.com> lezz@merlin.dev.cdx.mot.com (Lezz Giles) writes:
>>>>
>>>>Once again, I don't want to say that assembler is a Bad Thing.  Also
>>>>notice that I'm not saying anything about ease of programming, speed,
>>>>or anything else.  I'm just saying that if you program in assembler for
>>>>an 80386 then your program will run well on an 80386, sub-optimally on
>>>>an 80486 and not at all on an 80286 (and forget about a 68030).  If you
>>>
>>>This is patently wrong.
>>
>>No, it's quite correct.
>
>Again, the statement stands.  There isn't enough functionality improvement
>among the models to care about; you seem to have grabbed onto a notion and
>won't let go of it.  There are a handful of situations, like N-bit rotates
>which are helpful, but I could put a conditional on them if I really cared.
>I would generally rather go with compatibility.  Nitpicking percentage
>differences in efficiency will occur except in contrived conditions.

OK, you are not disagreeing that the code will be sub-optimal, you are just
arguing about whether the difference is worth caring about.
So why then did you say that the original statement was "patently wrong"?

You even say later:
>The so-called sub-optimality is a nit below optimality.

As far as I can see, you have admitted that it was true, but are arguing
that the efficiency differences are not relevant. Hardly sounds like
"patently wrong" to me.

>>>I write for the 8086/8088 model as do most people.
>>>It runs on 8088, 8086, 80186, 80188, 80286, 80386SX, 80386DX, 80486SX,
>>>80486DX, 80486DX2, and about 20 non-Intel clones from AMD, NEC, ULSI, TI,
>>>and a few other cpu clone maker's cpu's.
>>
>>Yes, but your code will be sub-optimal for all but the 8086/8088.
>>And as Lezz Giles pointed out, you can forget about the 68030.
>>(and of course, your code won't work for a Z/80 ;-)
>
>Gee whiz, mea culpa! my 80x86 code can't run on z 68030 or Z-80.  Well, your
>C-generated MAC II binary won't run on my '486 :-).

So just recompile it!
Better yet, distribute your code in source form.
Another alternative is to use interpreted languages (like perl),
or to compile to a byte-code which is then interpreted.
(An application that I have worked on used the latter method to
achieve seamless, virtually effortless portability to over 700 different
systems.)

>>>I can choose to exclude the 8088
>>>and 8086 with a simple assembler directive, which merely enables extensions
>>>available in the '286 and up, or I can us the larger models and write for
>>>protect-mode on either 286 and up or 386 and up as I choose.  There is
>>>hardly any difference between 386 and 486 save speed and a few instructions
>>>(very few) that were added to the '486.  There is virtually no software
>>>significence to the 486 over the 386, and for all indications, as posted on
>>>this newsgroup, the '586 won't change this either.
>>
>>It's not just a matter of "a simple assembler directive" - to take full
>>advantage of a better chip may require rewriting much of your code.
>>Assembly language programmers must choose between 8086, 80286, 80386,
>>and i486 at the time of writing, whereas HLL programmers choose at
>>compilation time. This can be a significant advantage.
>>For HLLs, it *is* just a matter of a simple compiler option.
>
>Pure crap. That's not what the assembler directives do.

Huh? I didn't say anything about what the assembler directives do,
it was what they *don't* do that I was pointing out.
I don't even understand what it is that you're disagreeing with here.

>... All this proves is that upward compatibility works.  The
>features gained don't dictate rewrites, rather just additional opportunity
>for alternate implementations that won't apply in this class of problem.
>... As long as my programs are shorter than that [16M], there isn't an
>avenue of improvement available.)

There *is* a possibly small but definitely non-zero performance increase
to be had from using the instructions that are not available for the 8086.
If you are writing in assembler, taking advantage of this would mean going
through your entire source code and modifying many parts of your program -
a tedious and hence error-prone task. On the other hand, if you are using
a HLL, taking advantage of the additional instructions, larger or more
numerous registers, etc. etc., offered by a new processor is just a matter
of a simple compiler option.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!