Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro
Subject: Re: ANOTHER 32-BIT MACHINE???
Message-ID: <5371@utzoo.UUCP>
Date: Fri, 29-Mar-85 12:55:06 EST
Article-I.D.: utzoo.5371
Posted: Fri Mar 29 12:55:06 1985
Date-Received: Fri, 29-Mar-85 12:55:06 EST
References: <9254@brl-tgr.ARPA>, <1549@watcgl.UUCP> <5355@utzoo.UUCP>
Organization: U of Toronto Zoology
Lines: 68

My statement was indeed that binary compatibility with an 8086 is
fundamentally incompatible with a full 32-bit architecture.  The 8086
is not a 32-bit architecture, and does not extend gracefully into one.
An 8086-compatible machine and a full 32-bit architecture are two
different cpus; whether they happen to be on the same silicon, with a
mode bit switching between them, is quite irrelevant to how useful
the combination is.  Use of 8086 compatibility and use of full 32-bit
architecture cannot occur simultaneously, even though Intel is trying
to fake you out into believing they can.

>  seriously doubt that because the vax occasionally executes binary
>  code (which is my understanding of compatibility mode {please correct
>  me if I'm wrong} - i.e. "totally binary compatible") from a 16 bit
>  architecture that very many people would claim it is not a true 32
>  bit architecture.

My point was, when running in pdp11 compatibility mode (which, by the
way, is NOT "totally binary compatible", because they left some things
out), the VAX is *not* a 32-bit architecture.  Just because a pdp11
program happens to be running on a VAX does not mean the pdp11 program
suddenly has 32-bit addressing; no way.  That pdp11 program sees a
16-bit architecture just like the pdp11.  Except possibly for speed,
it sees no difference between the VAX and, say, an 11/34.

> Does 32 bit mean you're not allowed to execute 16
>  bit instructions or something? I mean it seems reasonable to me that
>  a 32 bit machine would also have a complete set of 16 bit instructions
>  as well!

"Full 32-bit architecture", in my book, means addressing as well as
32-bit arithmetic.  This means that the entire instruction set has to
be duplicated, since the current 8086 addressing semantics are very
much tied to 16 bits.  I think it unlikely to the point of ridicule
that Intel is going to do that.
 
> Why if the 8086 is so poor are their so many of them? - because
> intel delivers a LOT faster than the other companies.

Have you tried getting delivery on, say, an 80286?  In volume?  Intel
delivered the 8086 very quickly because it was such a mediocre chip.
They made a conscious decision (well, they may not have considered it
in quite these terms...) to go for quantity rather than quality.  They
are now paying the penalty, as large software gets harder and harder
to cram into an 80*86 architecture.

>  Sure the architecture doesn't show much imagination, I don't
>  like it myself, but how many people program in assembler - I 
>  would expect that the architecture (with the possible exception
>  of 64k segments for data) would have zero noticable impact on most
>  people - they are either programming in HLLs or running application
>  packages.

The impact it has is that software package X either is totally unavailable
or is very late, because the producers had trouble making it fit the 8086.
"Possible exception" my foot -- the 64k data segments are the major botch
of the machine, and by far the hardest thing to fix.  If you think it's
easy to hide this under an HLL, without major performance impact, you
should try implementing an 8086 compiler some time.
 
> I can get msdos (not a great system but it works), an assembler,
> linker, pascal compiler, fortran compiler, modula compiler and
> a screen editor for under $1000 - what will software support
> for other machines cost? 

Tinplate is cheaper than steel, too.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry