From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 1 Sep 1992 23:04:35 GMT

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.

>
>>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 :-).

The so-called sub-optimality is a nit below optimality.

>
>>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.  Other than enabling
the few instructions available in the 286 over the 86, the only other thing
you can wake up has to do with optional memory management for writing larger
programs.  If I can't run it in a smaller machine, I never would have in
the first place.  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.
Moreover, when you use these modes with the extra features enabled, some of
your code slows down!  (BTW, cycle for cycle, for all the modes a 286 has
in common with a 386, the 386 is slower!  The additional modes are a
non-issue regarding compatibility or performance improvement because all
they afford are the potential for writing code over 16 Megabytes long or
for emulating multiple DOS sessions.  As long as my programs are shorter
than that, there isn't an avenue of improvement available.)

cjl
Xref: sparky alt.folklore.computers:13509 comp.unix.misc:3473