Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Intel Microprocessors
Message-ID: <320@l5comp.UUCP>
Date: Sun, 9-Aug-87 19:52:51 EDT
Article-I.D.: l5comp.320
Posted: Sun Aug  9 19:52:51 1987
Date-Received: Tue, 11-Aug-87 02:00:41 EDT
References: <1112@lznv.ATT.COM> <399@aucs.UUCP> <3225@cucca.columbia.edu> <789@unccvax.UUCP> <1924@Shasta.STANFORD.EDU>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Organization: L5 Computing, Edmonds, WA
Lines: 76
Summary: It all very simple really

Sheesh, years later and the battle still rages.

There is ONE reason that Intel and the 80X8X chips are still here, a very
sharp marketing person at Intel did the right thing when IBM can by one
day. And the same person at Motorola didn't. Motorola decided to ask too
much, and Intel realized what a boon it would be to say "Yeah, we can meet
that price!"

Now they're up to the 80386 and we hear all this wonderful stuff about big
address spaces and tons of 32 bit registers etc etc etc and that they will
sell 200,000 of them this year. But the dirty truth is that while the 80386
has all this stuff, fully 95% of them will be used to run 808X software.
Which makes the issue of what use this stuff is very moot.

Why? Intel goofed once again in it's architectural design. The chip IS NOT
fully protected while running in protected mode. A user level program can
bring the chip, and all the other users on that chip, down quite easily.
And there's not a DAMN thing the OS writer can do about it.

I'm sure every one here has seen write ups on the herculean efforts that
Microsoft is putting in in order to make the Intel chip secure. And yes, if
a program follows all the rules the chip WILL be secure. But if a program
trips over a bug (gee where did that damn bug come from? Couldn't be
someone got confused over those crazy mnemonics could it?) and slaughters a
few key things the whole thing will still come apart at the seams.

A person also mentioned stacking a 68000 based Mac against an AT and seeing
who could run 4 compilers.

How about we change that challenge? Lets take the FIRST GENERATION 8086 and
stack it against a FIRST GENERATION 68000? Lets take the new PS/2 model 20
and compare it against an Amiga 1000? To be fair we'll run both with the
most recent versions of OS software supplied by the machines maker. We'll
also only use "off-the-shelf" compilers and hardware.

For the model 20 we'll use PC-DOS 3.3 and Turbo C. Ooops, that damn TurboC
comes on 5.25 disks don't it (it does), hmmph, well I'll just get the dealer
to move it over for me. We also get all the RAM the model 20 can handle
directly, 1 meg.

For the Amiga we'll use AmigaDOS 1.2, alas things get unfair at this point.
PC-DOS 3.3 is what the 10th revision of their OS and ADOS 1.2 is the 3rd?
Hmm, maybe we should run PC-DOS 2.0? Naw, can't buy that anymore, IBM
doesn't support it. We'll buy Aztec C for the Amiga's compiler. We'll slap
on 4 meg of ram so we won't get cramped. :) But the price of the 8 meg is
so tempting, what the hell, make it 8 meg to go! Too bad the model 20 can't
do that too, sigh.

We drag 'em back home and set them up. With the Amiga we can sit down and
fire up 4 Manx compilers an editor or two (or three, we bought 8 meg after
all :). With the model 20 we fire up ONE turbo C and then start frantically
digging through the PC DOS manuals looking for the 'RUN' command...

Game over, Amiga wins.

As for those that think 8080 compatibility was a BIG thing, don't forget that
the 8088 is NOT OBJECT CODE COMPATIBLE with the 8080! You had to run your
SOURCE code through a convertor and then assemble it for the 8088. The same
kind of convertors exist to go 8080 -> 68000.

As for the segmentation is neat argument... I think all I need do is point
at the most recent bug in Turbo C's linker that keeps people from using
data hunks larger than 64k. Even without the bug how come the programmer
has to worry over NEAR and FAR? Why is it that IRQ handlers have to do
NO-NO's like writing to their code segments (something you can't do on the
80286/80386 in protected mode BTW) so that the IRQ handler can find out
where the data segment is? And lets not forget how much fun paragraphs are!
:) If segments are so neat how come they get in the way so much? And when
am I going to start seeing some BENIFIT from them in my Intel coding
chores?

Scott Turner
-- 
UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make
UUCP-auto: scotty@l5comp.UUCP    | sure I don't run up a vet bill.
GEnie: JST			 | "The bombs drop in 5 minutes" R. Reagan
		"Pirated software? Just say *NO*!" S. Turner