From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 15 Sep 92 09:31:06 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <id.C03T.XHC@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Sep8.095000.16053@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> In article <AX0JNS5@taronga.com> peter@taronga.com (Peter da Silva) writes:
>> >In article <1992Sep4.042704.21287@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> >>The non-portability of code to incompatible architectures is well known and
>> >>usually an acceptable tradeoff to writers of assembly code.
>
>> >	People who write applications in assembly code are people who
>> >	are willing to trade off a factor of 10 or more in a few years
>> >	for a factor of two in a portion of the code today.
>
>> No, not a translation at all, just some self-serving words you dredged up
>> to twist my statement.
>
>> The factor of two may be more or even less improvement today.  But the 
>> improvement follows you.  You are attempting an old and incorrect argument
>> that *never* works: that the new models are better because they have
>> new and wonderful features that make you stop using the old ones.
>
>No, because running 8088 code in a 32-bit system is simply slower. Or are you
>saying that people won't buy 80486es because they don't need the new and
>wonderful features? If so, I've got an XT motherboard I'll be happy to sell
>you.

8088/86 code runs almost as fast as 286 code which is the fastest regardless
of model in terms of speed wherever it runs.  If you want a small
speed improvement on a given model, and it supports 286 code, by all means use
it.  There are macros available for where you can't get the few instructions
you might need if 8088/8086, but there's little difference.  If it supports 
386 mode as well, you should avoid that, since 286 code will run faster,
especially so on 486's.  People should buy as fast a machine as they need,
although there are many 286's that are literally faster than 386's.

For the most part, the reason to buy the newer machines is because they run
the existing code faster.  The vast majority of the software runs on the
original IBM-PC suitably configured, although likely way too slowly.

Please refrain from the twisted and evasive exagerations.  You know the
tenets of my argument; disagree with it if you insist, but leave out the glib
off-the-topic remarks.

>
>> The
>> truth is that for any "family" of machines, the "meat and potatoes" of
>> the code is the same for all models.  You can get little tweaks along the
>> way *if* you are willing to create incompatible versions, but the operative
>> word is *little*.
>
>Except for the 8086 family, where the switch from the 80286 to the 80386 was
>a quantum leap improvement. The 80286 emulation mode is not nearly as fast,
>and (except for programs under 64K) the 8088 mode is even slower.

Whose hype have you been reading?  You admit you gave up on *any* use of these
machines years ago before these socalled improvements arrived.  For your
grotesquely uninformed benefit, your statement is ludicrous.  Read some
benchmarks and "white paper" reports from AMD, etc.  None of us swallow
that "Intel inside" bullshit.  Furthermore, there is no such thing as
"emulation mode" to use your incredibly defective terminology.  The only
speed races the 386 wins are the fact that 286's don't have virtual real mode
which you may never need, and that a 387 is a faster coprocessor than a 287
assuming a fast enough clock.  BTW, some 386 systems use 287's.  Since this
is an FPU issue, it isn't relevant anyway.

>
>I'm running software on the 80286 and 80386 today, as we speak, and the
>performance increase I see going from the 80286 model to the 80386 model
>is never less than a factor of 4 for reasonable sized code.

Your code is an aberation.  How much of it is extraneously using 32-bit
arithmetic where 16 is more than enough?  In any case, it is obviously some
totaly *non*-representative unix code which impacts virtually zilch on the
PC world.

>
>Yes, the old code runs faster on the new CPU than the old one. But a simple
>recompile and it runs faster still. Many times faster.

Totally wrong for virtually everyone.

>
>> more than a few people have indicated that
>> 15 years seems to be a good number for one's expectation of the "lifetime"
>> of a family of machines, which is more than enough time to permit the
>> devotion of intimate machine knowledge only obtained in assembler.
>
>Your 15 years is up. Now what?

No, 15 years is the largest "safe" estimate time to predict for certain 
machines.  The PC world seems to defy the conventional wisdom.

>
>> Moreover,
>> you take all your knowledge with you to the new machine.
>
>Just none of the code.

That's a given.

>
>Personally, I'm tired of reinventing the wheel.

You should be, since you're always running on badly lubricated ones.  But 
that's the crux of the argument.

>-- 
>Peter da Silva                                               `-_-'
>Ferranti Intl. Ctls. Corp.                                    'U` 
>Sugar Land, TX  77487-5012
>+1 713 274 5180                                   Har du kramat din varg idag?

cjl