mo@seismo.UUCP (Mike O'Dell) (04/30/85)
Some 386 design folks at Intel took great exception to my note indicting the 8[012]86 design which also mentioned the 386 while pointing out it IS different in important ways. It seems they are a might sensitive about the criticizisms. It seems the 386 is a muliple-personality case - code segments are marked with the kind of instructions they contain and things shift gears as you JSR around, so to speak. The real point is that the 386 in its maximal persona is still a segmented machine, but with 48-bit addresses. The segment number is still 16-bits, but the offset grows 16 more. So, it is possible to run it as a flat-address-space 32-bit machine by using fixed segments, or, if you want to deal with 48-bit pointers and 32-bit integers, a 256 giga-byte segmented machine. Holy Multics, Batman! On the 286, segments aren't paged, but must be wholy in memory - but they can be demand-faulted in. I assume the 386 pages under those gigantic segments. So, judging from the information I have seen in the promotional literature and road-show on the 386, it seems they have designed a real cpu, and not a useful but limited data pump, like its bretheren. Maybe they can catch Motorola. -Mike O'Dell
johnl@ima.UUCP (05/01/85)
I will be much more impressed by how swell the 386 is (and I agree, having
32 bit segment offsets sounds pretty swell) when I can hold one in my hand.
Seems to me that if the 386 can do everything a 286 can do, and also has a
complete 32-plus bit CPU, it is going to need a piece of silicon about three
feet across. Rumor has it that Intel had a lot of trouble getting the 286
to work and still can't make them as fast as they'd like; the 386 can only
be worse.
So are there any credible estimates as to when 386 samples will start
appearing? Any incredible estimates?
John Levine, Javelin Software, Cambridge MA 617-494-1400
{ decvax!cca | think | ihnp4 | cbosgd }!ima!johnl, Levine@YALE.ARPA
PS: I spend my time these days writing software that has to bob and weave
around the 8086's and 286's segmentation and I am increasingly sure that the
8086's addressing is my punishment for unspeakable sin in a previous life. I
really sincerely hope that Intel gets the 386 to work soon, and that IBM
instantly puts it into a desktop computer that is so wildly successful that
nobody ever thinks about running code on a 286 or 8088 again, and that small
and energetic businesses build machines based thereon for under $1000,
including a 100MB disk drive and 16MB or RAM, and give me one for free for
suggesting it. But somehow, I doubt it. phil@amdcad.UUCP (Phil Ngai) (05/03/85)
In article <38800002@ima.UUCP>, johnl@ima.UUCP writes: > Rumor has it that Intel had a lot of trouble getting the 286 > to work and still can't make them as fast as they'd like; the 386 can only > be worse. A little birdy told me Intel now has 80286s that run at 12.5 MHz. Since the 286 has a 2 clock bus cycle one could argue that is as fast as a 25 MHz 68000, in some sense. But I know I would get flamed if I did, so I won't. Another rumor I heard is that the 80186 was developed the old fashioned way (with tape?) while the 80286 was developed with extensive CAD. The use of CAD was so successful that they really went whole-hog with CAD on the 386. Take this with a large grain of salt. Anyway, AMD has 10 MHz 80186s so maybe Intel should let us produce the 386 :-) > really sincerely hope that Intel gets the 386 to work soon, and that IBM > instantly puts it into a desktop computer that is so wildly successful that > nobody ever thinks about running code on a 286 or 8088 again, and that small > and energetic businesses build machines based thereon for under $1000, > including a 100MB disk drive and 16MB or RAM, and give me one for free for > suggesting it. But somehow, I doubt it. I hear that the 386 will come in a 132 pin PGA, which can't be cheap. 32 address lines, 32 data lines, and a few other pins. (68 power and ground pins :-) -- I speak for myself and no one else. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
jss@sjuvax.UUCP (J. Shapiro) (05/06/85)
> A little birdy told me Intel now has 80286s that run at 12.5 MHz.
Now about that bug list.....zrm@prism.UUCP (05/12/85)
I get the impression that somebody at Intel really believes that lots of segments are a feature rather than a bug. But I won't be convinced until I can use those segments to advantage -- as is done in Multics. This means that segments have to be of varying sizes, and have a paging system underneath the segments, and have a mechanism for generating linkage faults (detecting unresolved external references at run-time in a recoverable manner). The 286 can detect refernces to a segment that has been swapped out and can recover from those faults, but all of those refernces were resolved at link-time. This leaves us about halfway to Multics (the good parts of Multics, that is) in a micro. Will the 386 go the rest of the way? Is there some clever hack to simulate linkage sections with the 286 addressing modes and segements? And last, but not least, are there any companies doing systems software that would take advantage of such capabilities? Cheers, -Zig
jbn@wdl1.UUCP (05/15/85)
We already have eight code models for the present Intel line. How many more will the 386 introduce? 1) 8086/8088/Unprotected IAPX 286 small code/small data 2) 8086/8088/Unprotected IAPX 286 large code/small data 3) 8086/8088/Unprotected IAPX 286 small code/large data 4) 8086/8088/Unprotected IAPX 286 large code/large data 5) Protected IAPX 286 small code/small data 6) Protected IAPX 286 large code/small data 7) Protected IAPX 286 small code/large data 8) Protected IAPX 286 large code/large data How much more of this will the compiler vendors stand for? By the way, is there a good compiler for C on the PC/AT for UNIX that supports mode 8 fully? JN
caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/17/85)
You forgot 4.5 and 8.5 : HUGE model which can access certain objects larger than 64k. The Lattice C large model is actually huge (unless you use an option). The PC-AT large model (which has yet to work properly for any non trivial program I've tried) is not. I have seen a huge model Microsoft compiler when is even more buggy than the large model. It did however successfully compile and run the sieve program with results about the same as Lattice huge model. Some numbers: Sorted by Execution real time Compile - Link Execute Real User Real User Bytes System 1.8 .31 .37 0.2 200 Ahmdal 470-V8 + UTS (160 users) % 25 1.3 0.8 .45 224 Gould SEL 32/87 (loaded) % 27 6.6 1.1 1.0 140 Charles Rivers + Unos % 22 1.8 2.0 1.2 144 Parallel 68k + Zenix # 9 2.4 2.3 2.3 140 SUN 68010 4.2 BSD 6/84 8.1 1.8 2.6 2.2 104 4.2 BSD VAX 11/780 18.2 4.4 2.7 2.5 72 H-P 32 bit mini 14.6 - 3.3 - 148 Sun Microsystems 68k 22 1.8 3.7 1.3 144 Parallel 68k + Zenix %# 26 8.7 5 4.9 148 Cosmos 10 mHz 31 5.5 5.0 4.5 148 Momentum Hawk 32 38 6.8 5.0 3.9 148 CYB Multibox (Sun Board) 17.5 5.0 5.8 5.7 267 9mHz PC-AT Zenix + huge model 5/85 41 7.3 6.0 5.2 148 Lisa + Unisoft 15 3.8 9 6 88 VAX 11/730 + 4.1 BSD 45 8.2 9.0 8.2 128 NS16032 6mHz + "4.1 BSD" && 50 - 30 - 252 IBMPC DOS 2.1 Lattice 2.00 8/84 + Some of these times are based on old systems with numerous wait states. Note that these results don't quite match those shown in Intel's ads. That's because 32 bit programs are being compared with 16 bit programs. There are 16 bit 68000 compilers that beat these figures, just as 8086 compilers do better when they don't try to emulate a real processor. -:) -- Chuck Forsberg WA7KGX ..!tektronix!reed!omen!caf Omen Technology Inc 17505-V NW Sauvie IS RD Portland OR 97231 Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect)
markg@tekig4.UUCP (Mark Galassi) (05/22/85)
In article <418@wdl1.UUCP> jbn@wdl1.UUCP writes: > > We already have eight code models for the present Intel line. >How many more will the 386 introduce? > > 1) 8086/8088/Unprotected IAPX 286 small code/small data > 2) 8086/8088/Unprotected IAPX 286 large code/small data > 3) 8086/8088/Unprotected IAPX 286 small code/large data > 4) 8086/8088/Unprotected IAPX 286 large code/large data > 5) Protected IAPX 286 small code/small data > 6) Protected IAPX 286 large code/small data > 7) Protected IAPX 286 small code/large data > 8) Protected IAPX 286 large code/large data > >How much more of this will the compiler vendors stand for? By the way, is >there a good compiler for C on the PC/AT for UNIX that supports mode 8 fully? > > JN I agree with you that the 80286's compatibility with old processors is horrible for who doesn't care about the old ones. I have worked a lot with an Intel 286/310 computer running XENIX, and the C compiler allows: 2 small models: one has 64K text and data, the other has 64K text and 64K data. 1 medium model: n*64K text (arbitrary n) and 64K data 1 large model: n*64K text, m*64K data. an option to generate 80286 code (I guess that for some obscure reason they normally generate 8086 code). (notice that no single array or structure must exceed 64K) I have not yet used the large model (which is the mode 8 JN was looking for), but in Intel's release 3 of XENIX, they say it is bug-free, so Microsoft presumably also has a working version for the the IBM AT with XENIX. You need to use libraries compiled with the large model if you use the large model for your code. Will we still have to put up with 64K segments on the 80386?
feustel@ihlpl.UUCP (Feustel) (11/06/85)
While I dislike hype as much as anyone, 386 info is hard to come by right now (I just got my 130 page data sheet(read "book")). Among the flames appearing on the net concerning INTEL and the 80x86 architecture are some good observations and ideas. I am very familiar with INTEL 8086/286 architecture. I like the architecture a lot. I like the 386 architecture a whole lot more. I also think that the complexity of the 386 may be a strong argument for risc machines (which I do not personally find appealing). For the last 2 months I have been using an AT&T UNIX PC which runs on a Motorola 68010. It works very well. Even though I prefer INTEL's system architecture from an esthetic point of view, I appreciate the functionality of the programs running on the 68010. SUGGESTION: Let's see the results of benchmarks written in C running under UNIX system V version 2 for each of the 32 bit micros, with the benchmark source programs included.