Xref: utzoo comp.sys.ibm.pc.misc:4341 comp.sys.intel:1511
Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!rspangle
From: rspangle@jarthur.Claremont.EDU (Froot Loop)
Newsgroups: comp.sys.ibm.pc.misc,comp.sys.intel
Subject: Re: When will the 8088 die?
Message-ID: <9917@jarthur.Claremont.EDU>
Date: 3 Dec 90 05:24:17 GMT
References: <90335.202651F0O@psuvm.psu.edu> <1990Dec3.024326.22956@alchemy.chem.utoronto.ca>
Followup-To: comp.sys.ibm.pc.misc
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 50

In article <1990Dec3.024326.22956@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:
>In article <90335.202651F0O@psuvm.psu.edu> F0O@psuvm.psu.edu writes:
>>    I also hope that when Intel designs the 686 chip, it will be backward
>>compatible to the 286, not the 8088(the 586 will be backward compatible to
>>the 8088).  I'm not sure how easy this would be to do, since the 286
>>instruction set is a superset of the 8088, but I do think the 286 should be
>>the base for the 686 and up.
>     This comment really piqued my curiosity... Since the 286
>instruction set is a superset of the 8088's, how do you propose that
>Intel make a chip whose instruction set is a superset of the former's
>without including the instructions of the latter's?  Furthermore, what
>possible purpose could it serve to deliberately screw up backward
>compatibility in such a way?

     I think it would make much more sense to make the 686 backwards 
compatible only as far back as the 386.  The 286 does not allow full
multitasking, etc.

     Which leaves us with the question: Why make it 8088 incompatible?
Well, I can come up with several reasons:

1)	Chip simplicity: Simplicity is proportional to speed.  

2)	Modernization: Admittedly, any new chip which doesn't support 
	programs written for the 8086 or 80286 will break a LOT of programs.
	But that will smooth out the overall software market for the PC's.
	Programs that are valuable enough that people still want to use them
	will be recompiled using 32-bit compilers, which will make them 
	faster.  Since initially the video and disk interfaces will be the
	same, it shouldn't be too much of a change.  Eventually, since all 
	programs will need to be 32-bit aware, cards will be able to start 
	putting video memory at the 2GB boundary or something, and then you 
	don't have to deal with paging.  This will also stomp out the 
	*^(*&^(^*^ 1024KB limit, and consequently MS-DOS/IBM-DOS.  So we 
	can get on to programs without memory problems (I have 6MB - whadda 
	you mean "Insufficient Memory"?) and perhaps a better file system 
	(OS/2 2.0?  (If and when)) Basically, you'd force all programs to 
	run in 386 protected mode.

	In the long run, I think it would probably reduce hassles, because
	multitasking environments would no longer have to worry about 
	programs which expect only 20-bit addresses as opposed to programs
	which expect 32-bit addresses, etc.  The 8086 et al would go the way
	of the Apple II, Commodore 64, and Atari 800.

-- 
 --------------------------------------------------------------------------
|   Randy Spangler                   |   Get your mind out of the gutter   |
|   rspangle@jarthur.claremont.edu   |   you're blocking my periscope      |
 --------------------------------------------------------------------------