davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (07/20/87)
80386 user mailing list Volume 1 #5 July 14 1987 In this issue: Xenix 386 386 compatibility 386 benchmarks (lots of comments) Who's new Questions: Phar Lap 386 software? Smalltalk? X windows? (+ commant) V/386? Editor: Bill Davidsen ---------------------------------------------------------------- 80386 mailing list contributions should be made to 386users@udel.edu /or/ ...!uunet!seismo!udel.edu!386users Requests to join the list: 386users-request /or/ ...!uunet!seismo!udel.edu!386users-request ---------------------------------------------------------------- From davidsen Thu Jul 2 09:14:08 1987 To: spdcc!dyer Subject: Xenix 386 Cc: davidsen Date: Thu Jul 2 09:14:07 1987 What is the availability of Xenix 386? I am debating the purchase, as opposed to keeping on for a while with 286. Is it shipping, or just beta? Is it solid enough for production work? I do some heavy software development at home and would like better performance for testing (the results will run on Suns or Vaxen). I don;t have the time to devote to recovering from serious problems, if there are any. Will Xenix/386 produce code for Xenix/286 and DOS? I cross compile to DOS for a reasonable ammount of software. thanks, bill PS: I'm picking up your posting for 386users mailing list, but if it's not a hassle (I don't know your poster) you might send them direct to 386users@udel.edu. -b- ---------------------------------------------------------------- From spdcc!dyer Fri Jul 3 04:32:39 1987 To: 386users@UDEL.EDU Subject: XENIX 386 Date: Thu, 02 Jul 87 13:27:51 -0400 Sender: Steve Dyer <steinmetz!uunet!seismo!spdcc.com!dyer> >From: crdos1!davidsen >Date: Thu Jul 2 09:14:07 1987 >What is the availability of Xenix 386? I am debating the purchase, >as opposed to keeping on for a while with 286. Is it shipping, or just >beta? Is it solid enough for production work? >I do some heavy software development at home and would like better >performance for testing (the results will run on Suns or Vaxen). I >don;t have the time to devote to recovering from serious problems, if >there are any. >Will Xenix/386 produce code for Xenix/286 and DOS? I cross compile to >DOS for a reasonable ammount of software. I've been running the 5/29/87 XENIX 386 beta test (with a set of fixes dated 6/16/87) for only three days now, so it's a bit early for me to feel comfortable giving anything like an authoritative answer here. For the most part, the software I received is a clone of XENIX 286 release 2.2.1, with the exception that the kernel supports and the C compiler produces 386 32-bit object programs, as well as all earlier 8086 and 286 objects. I immediately rebuilt news 2.11 and MH 6.5 under the 32-bit compiler and they worked right off (with MH finally free of the problems it used to have in running out of memory in small model.) It looks like all the standard 286 compiler passes and libraries are in /lib (but no -LARGE passes--no need for them anymore!) with the 386 passes and small-model libraries in /lib/386. There don't seem to be any medium or large memory models available for 386 programs under this release of XENIX386, but, honestly, who would need them? Remember that "small model" on a 386 means a 32-bit linear address space. Because this is just a version of XENIX 2.2.1, there is also a DOS development environment. I've never used it, either here or under XENIX 286, so I can't comment on whether it suddenly broke or not. All my earlier objects from XENIX 286 run just fine, with one exception which I haven't had the chance to better characterize yet--the Progress DBMS causes the kernel to crash with an "illegal device interrupt" panic when I invoke it on my development database. Now, there's certainly something wrong here, but whether it is dependent on my Inboard, the mix of 32-bit and 16-bit memory, or something crazy they're doing at DLC, the authors of Progress, I don't know. And I suspect it'll take some coordination to get it straightened out. I'm trying to characterize the conditions necessary to make this happen, at which point a bug report will go to DLC and SCO. I should emphasize, however, that all my own 286 C programs run just fine. One thing you should be aware of is that 3rd party device drivers for XENIX 286 won't link into the 386 kernel. If you have anything like this (I have a Computone 4-port serial board) you'll be off the air for a while. On the other hand, XENIX 286 2.2 and XENIX 386 provide support for a wide number of tape drives and serial cards, so you might not have a problem here if you have the right hardware. Computone promises a new driver in a few weeks. It wouldn't surprise me if there might be bugs yet to be discovered in the virtual memory support (trying to run many large programs, shared memory, etc.) but my impression of the 386 release, using it initially as a faster XENIX 286 system without the damn segmentation getting in my way, is that it's been no more disruptive than upgrading to XENIX 2.2.1 from 2.1.3 was. The beta release plus bug-fix patch I received was VERY robust, and as well put-together as 2.2.1. I don't know when XENIX 386 starts shipping yet, although I know the beta test period has ended. I would guess that it is very soon. Hope this helps, Steve ---------------------------------------------------------------- From gnu@hoptoad.uucp Thu Jul 2 04:34:36 1987 Subject: The 80386 is not upward compatible with the 8086! Date: 2 Jul 87 04:34:36 GMT To: 386users@UDEL.EDU Organization: Nebula Consultants in San Francisco I was surprised to find this in comp.os.minix: jaime@killer (James da Silva @ The Unix Connection BBS, Dallas, Texas) wrote: > After more than a couple nights of poking around and endless > iterations of re-compiling the kernel, I have gotten Minix to > boot on a 16Mhz Intel-Motherboard 80386 AT. > > The basic incompatibility arises in the vid_copy function, used > to copy text into screen memory. AST uses the 'lock' prefix to > indicate to the PC-Simulator that video memory has changed. The > specific instruction used is 'lock nop'. > > The designers of the 80386 decided to restrict the use of the > lock prefix to certain instructions that read a value from > memory, modify it in some way, then store it back in the same > memory location. In particular, the lock prefix is permitted only > with the following instructions and addressing modes: > > BT, BTS, BTR, BTC mem, reg/immediate > ADD, OR, ADC, SBB, AND, SUB, XOR mem, reg/immediate > XCHG reg, mem > XCHG mem, reg > NOT, NEG, INC, DEC mem > > The 'lock nop' instruction was causing an undefined opcode trap > to occur. Not Pretty. And not easy to find. With the lock nop > instruction commented out, Minix came up without a hitch. It looks like the 386 is compatible with the 8086 in the same sense that the 68010 is compatible with the 68000 -- very close, but a few instructions now cause traps. What surprises me the most is that the address of the undefined opcode after an undefined opcode trap was "not easy to find". On the 68000 series the address of the bad opcode is stacked, and on the 68000, the opcode itself is also stacked. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Alt.all: the alternative radio of the Usenet. Contributions welcome - post 'em ---------------------------------------------------------------- From tomk@intsc.UUCP Thu Jul 2 15:53:30 1987 Sender: tomk@intsc.UUCP (Tom Kohrs) To: 386users@UDEL.EDU Subject: Re: The 80386 is not upward compatible with the 8086! Date: 2 Jul 87 15:53:30 GMT Organization: Intel Sales, Silicon Valley, Ca. in article <2353@hoptoad.uucp> gnu@ingres.berkeley.edu writes: > I was surprised to find this in comp.os.minix: > > jaime@killer (James da Silva @ The Unix Connection BBS, Dallas, Texas) wrote: > > After more than a couple nights of poking around and endless > > iterations of re-compiling the kernel, I have gotten Minix to > > boot on a 16Mhz Intel-Motherboard 80386 AT. ... > > The designers of the 80386 decided to restrict the use of the > > lock prefix to certain instructions that read a value from > > memory, modify it in some way, then store it back in the same > > memory location. In particular, the lock prefix is permitted only > > with the following instructions and addressing modes: > > > > BT, BTS, BTR, BTC mem, reg/immediate > > ADD, OR, ADC, SBB, AND, SUB, XOR mem, reg/immediate > > XCHG reg, mem > > XCHG mem, reg > > NOT, NEG, INC, DEC mem > > > What surprises me the most is that the address of the undefined opcode > after an undefined opcode trap was "not easy to find". On the 68000 series > the address of the bad opcode is stacked, and on the 68000, the opcode > itself is also stacked. The reason for the change in the use of the lock instruction prefix had something to do with the pipelining of the 386 that the 8086 did not have. The lock prefix was restricted to make the micro code reasonable with the 6 stage pipeline. As far as the bad opcode trap, it is actually a fault. Subtle difference, in a fault the address of the first byte of the instruction string is pointed to by the return address on the stack. Traps point to the following instruction. The recommended work around for the lock problem is a lookup table in the invalid opcode fault handler that either increments the return address to step over the lock prefix or emulates the instruction with one of the valid lock instuctions. ------ "Ever notice how your mental image of someone you've known only by phone turns out to be wrong? And on a computer net you don't even have a voice..." tomk@intsc.UUCP Tom Kohrs Regional Architecture Specialist Intel - Santa Clara ---------------------------------------------------------------- From braun@m10ux.UUCP Wed Jul 1 18:25:33 1987 To: 386users@UDEL.EDU Subject: Re: XENIX 386 benchmark results Summary: What size are ints? Date: 1 Jul 87 18:25:33 GMT Organization: AT&T Bell Labs, Murray Hill After seeing the various benchmarks for 80286, 80386, and 68020's, I have been wondering: What sizes are the integers used by each machine? I assume that a 80[012]86 is using 16 bit integers. I would also suspect taht a 68020 is benchmarked with 32 bit ints, since that's what you get from Sun and the other 68020 workstation makers. What about the 80386? Are most of these benchmarks done running the same binary on a '386 as used on the '286? If so, what happens to the '386's speed when it runs with 32 bit integers? By the way, what support does the '386 have for 32 bit arithmetic and 32 bit addressing? Is it a new bunch of instructions, or a different mode for the cpu? -- Doug Braun AT+T Bell Labs, Murray Hill, NJ m10ux!braun 201 582-7039 ---------------------------------------------------------------- From jfh@killer.UUCP Fri Jul 3 17:44:33 1987 Subject: Re: XENIX 386 benchmark results Summary: Nice times, I don't know about the "in Sun territory" though ... To: 386users@UDEL.EDU Date: 3 Jul 87 17:44:33 GMT Organization: The Unix(tm) Connection, Dallas, Texas In article <127@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > ... > At least from the Dhrystone benchmarks reported below, we're well > into Sun 3 territory, if not beyond! Quite amazing... > > IBM PC/AT 8mhz IBM PC/AT with Intel Inboard 386/AT > at 16mhz, cache enabled > XENIX 286 XENIX 286 XENIX 286 XENIX 386 > 16-bit mem 16-bit mem 32-bit mem 32-bit mem > > Drystone 1.1 no reg reg no reg reg no reg reg no reg reg > 1084 1094 1957 1963 2906 2893 4603 4922 [ some munging to get rid of unneeded 1.0 kruft ] I really don't know about the claim that the 386 is now in Sun territory. I just benchmarked a Plexus P/95 (Yes, I know the list price is up arround $100K) and it came out somewheres near 5200 Dhrystones at 20Mhz. The 25Mhz box we bought should be over 6000. Hopefully Guy can get his Sun's to do alittle better than they have been doing. We should be getting our box in sometime this week. I finally got a system built the way *I* wanted rather than what the boss wanted to spend on one. Dual disks, plenty RAM, spare serial ports, the works. I just hope they can still afford to give me a raise next year :-) :-) :-). And just for kicks, I bounced this into comp.arch where it might be interesting for all of those RISC'y people to see ... And by the way - Xenix is not just an operating system for PC's. Tandy runs it on 68000's, I don't know about anyone else though ... - John. ---------------------------------------------------------------- From mash@mips.UUCP Sun Jul 5 06:43:05 1987 Subject: Re: XENIX 386 benchmark results To: 386users@UDEL.EDU Date: 5 Jul 87 06:43:05 GMT Organization: MIPS Computer Systems, Sunnyvale, CA In article <1090@killer.UUCP> jfh@killer.UUCP (John Haugh) writes: ....on 386s getting into SUn-3 territory... >I really don't know about the claim that the 386 is now in Sun territory. >I just benchmarked a Plexus P/95 (Yes, I know the list price is up arround >$100K) and it came out somewheres near 5200 Dhrystones at 20Mhz. The >25Mhz box we bought should be over 6000.... >And just for kicks, I bounced this into comp.arch where it might be >interesting for all of those RISC'y people to see ... Hmmm. You might want to read Rick's current Dhrystone lists. I realize my login machine does only a "wimpy" 10-12K Dhrystones, but I've got terminal sessions going on this instant on RISC micros that do 18-22K Dhrystones, and they are NOT wimpy [about 5 minutes CPU time and <13 minutes real time for full 4.3+NFS kernel build from scratch. This is slower than the Amdahl "3 minutes".] SunRise / SPARC /Sun-4 should be announced this week, and they ought to be over 20K Dhrystones, too. Rick's end-of-July issue should be interesting: at least 2 different RISC microprocessors will be on the list FASTER than IBM 3081s, CRAY X-MPs [to be fair, not built for Dhrystone:-)]. They will be slower than IBM 3090s and Amdahl 5860s...this year... -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 ---------------------------------------------------------------- From dyer@spdcc.COM Fri Jul 3 01:45:36 Sender: dyer@spdcc.COM (Steve Dyer) Subject: Re: XENIX 386 benchmark results To: 386users@UDEL.EDU Date: 3 Jul 87 01:45:36 GMT Organization: S.P. Dyer Computer Consulting, Cambridge MA In article <225@m10ux.UUCP>, braun@m10ux.UUCP writes: > After seeing the various benchmarks for 80286, 80386, and 68020's, > I have been wondering: What sizes are the integers used by each machine? > I assume that a 80[012]86 is using 16 bit integers. I would also suspect > taht a 68020 is benchmarked with 32 bit ints, since that's what you get > from Sun and the other 68020 workstation makers. What about the 80386? > Are most of these benchmarks done running the same binary on a '386 as > used on the '286? If so, what happens to the '386's speed when it runs > with 32 bit integers? At least for "dhrystone", all integers are declared as "int", meaning that the compiler chooses the natural size for its target architecture. For XENIX 286 cc, int == 16 bits and for XENIX 386 cc, int == 32 bits. Maybe my report wasn't clear enough (I thought it was), but I reported results for both 286 objects and 386 objects running on the Intel 386 as well as baseline results for the 286 objects running on an 8mhz 286. > By the way, what support does the '386 have for 32 bit arithmetic > and 32 bit addressing? Is it a new bunch of instructions, or > a different mode for the cpu? This is interesting. First, both the 286 and 386 execute the same instructions (the 386 has some extensions and new addressing modes, but this is generally a true statement) but on the 386, the operand size can vary. The 386's registers are analogous to the 8086, but the "general registers" (if they can be called that) are potentially 32 bits wide. In real mode (and virtual-86 mode) the operand and address sizes are 16 bits by default, just like an 8086 or 286. In protected mode, the address and operand sizes are determined by the D-bit in the segment descriptor for the code currently executing. If D==0, then 16-bit addressing and operands are the default; if D==1, then all addresses and operands are taken to be 32 bits wide. There are two opcode prefixes which invert the current sizes of addresses and operands for that instruction. These prefixes are most useful in a real mode DOS environment to force 32-bit operations. They're generally unnecessary in a protected mode environment, since the OS sets your code segment selector appropriately. I could imagine some hacks to get 16-bit behavior in a 32-bit environment, but they'd be certainly unusual. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer ---------------------------------------------------------------- From john@bby-bc.UUCP Fri Jul 3 18:00:18 1987 Sender: john@bby-bc.UUCP (john) Subject: Re: XENIX 386 benchmark results To: 386users@UDEL.EDU Date: 3 Jul 87 18:00:18 GMT Organization: Burnaby, British Columbia, Canada > then 16-bit addressing and operands are the default; if D==1, then all > addresses and operands are taken to be 32 bits wide. There are two opcode > prefixes which invert the current sizes of addresses and operands for that > instruction. These prefixes are most useful in a real mode DOS environment > to force 32-bit operations. They're generally unnecessary in a protected mode > environment, since the OS sets your code segment selector appropriately. > I could imagine some hacks to get 16-bit behavior in a 32-bit environment, > but they'd be certainly unusual. So if you want to do 16 and 32 bit arithmetic in the same procedure all the instructions with operands of one of the sizes has to be prefixed? Do any of the existing compilers do this? Are there instuctions for 16->32 and vice versa conversions along the lines of CBW? Assuming 32 bit wide memory is there any unusual speed penalties for particular instuctions with 16/32 bit operands, e.g. are shifts faster with one particualr size? ---------------------------------------------------------------- From kds@mipos3.UUCP Wed Jul 8 13:34:29 1987 Sender: kds@mipos3.UUCP (Ken Shoemaker ~) Subject: Re: XENIX 386 benchmark results Date: 8 Jul 87 20:34:29 GMT Organization: Intel, Santa Clara, CA In article <130@bby-bc.UUCP> john@bby-bc.UUCP (john) writes: >So if you want to do 16 and 32 bit arithmetic in the same procedure all the >instructions with operands of one of the sizes has to be prefixed? yes... > >Are there instuctions for 16->32 and vice versa conversions along the >lines of CBW? yes, both sign extend and zero extend are provided >Assuming 32 bit wide memory is there any unusual speed penalties for >particular instuctions with 16/32 bit operands, e.g. are shifts faster >with one particualr size? nope, the rate of instruction execution shouldn't change. Of course, it takes a clock to crack a prefix, so if you have lots of them, performance could suffer. My guess as to why 32-bit code seems to run so much faster than 16-bit code on the 386 has to do with the differences in the programming model between 16-bit and 32-bit code: 32-bit code is always "small" mode (i.e., no segment register reloads), can do 32-bit arithmetic operations in a single instruction, and register usage is more general in 32-bit code. -- The above views are personal. ...and they whisper and they chatter, but it really doesn't matter. Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California uucp: ...{hplabs|decwrl|amdcad|qantel|pur-ee|scgvaxd|oliveb}!intelca!mipos3!kds csnet/arpanet: kds@mipos3.intel.com ---------------------------------------------------------------- From john@bby-bc.UUCP Sat Jul 4 03:23:05 1987 Sender: john@bby-bc.UUCP (john) Subject: 80827 affects speed of 80286? (July Byte) To: 386users@UDEL.EDU Date: 4 Jul 87 03:23:05 GMT Organization: Burnaby, British Columbia, Canada In the July issue of Byte they benchmark the 68020 and 80386 using (among others) the dhrystone benchmark. They also give figures for the 80286 as a comparison. The figure for an 80286 with an 80287 is 13% faster than a 80286 alone but as I recall the Dhrystone benchmark doesn't do any floating point so this would indicate that the 80287 somehow speeds up the 80286 non float instructions somehow - is that really the case or are the results bogus? The actual numbers given are: IBM PC-AT (8mhz) 1567.9 IBM PC-AT (8mhz)+80287 1748.9 Also elsewhere in the issue (the BIX stuff) someone claims the following results for the 386 (Dhrystones again): protected mode nonprotected Compaq 386 16mhz 5850 2380 386 Hummingboard 16mhz 6730 2777 386 Hummingboard 20mhz 8650 3571 Intel 386/20 6700 ---- The nonprotected mode was using Microsoft C in large model. The protected mode used Metaware 386 High C in small (4 gigabyte segs) model. 8650 is pretty impressive. Anyone have a capsule description as to why protected mode is so much faster? john ---------------------------------------------------------------- From ralf@b.gp.cs.cmu.edu Mon Jun 29 00:34:31 1987 Sender: ralf@b.gp.cs.cmu.edu (Ralf Brown) Subject: Re: 32-bit memory benchmark results for Inboard 386/AT card Summary: Saving registers is time-consuming To: 386users@UDEL.EDU Date: 29 Jun 87 00:34:31 GMT Organization: Carnegie-Mellon University, CS/RI In article <1176@bobkat.UUCP> m5@bobkat.UUCP (Mike McNally (Man from Mars)) writes: >In article <122@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: > > IBM PC/AT 8mhz IBM PC/AT with Intel Inboard 386/AT > > 16-bit mem 32-bit mem > >Drystone 1.0 no reg reg no reg reg no reg reg > > 1278 1292 2293 2304 3429 3405 > >Drystone 1.1 1084 1094 1957 1963 2906 2893 > >Why is the with-register-variables time for the 32-bit version *slower* >than the without-register-variables time? Isn't that sort-of strange? >-- >Mike McNally, mercifully employed at Digital Lynx --- No, its not strange when you consider that Dhrystone is not register- intensive. Saving the registers used for register variables on entry to a procedure and restoring them at exit takes time (PUSH/POP). If the register variable is not referenced often enough that the reduced access time to the variable makes up for the overhead of pushing and popping the register. The time savings for access to a register variable may be as little as three or four clock cycles (depending on wait states), while pushing and popping take 8 to 10 clocks (again, dep on wait states). Thus, if the register variable is accessed less than four times, you have a net increase in execution time. BTW, Turbo C with all optimizations on shows the same effect on an AT when running Dhrystone. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ARPA: RALF@B.GP.CS.CMU.EDU USnail: Ralf Brown AT&T: (412) 268-3053 (school) Computer Science Department Carnegie-Mellon University DISCLAIMER? Who ever said I claimed anything? Pittsburgh, PA 15213 "I do not fear computers. I fear the lack of them..." -- Isaac Asimov --------------------------------------------------------------- My employers do not endorse my | "I may be slow, but I'm not stupid. opinions, and, at least in my | I can count up to five *real* good." preference of Unix, heartily | The Great Skeeve disagree. | (Robert Asprin) ---------------------------------------------------------------- From jordan@titn.TITN Tue Jul 7 05:06:44 1987 Sender: jordan@titn.TITN (Jordan Bortz) Subject: Applications in X, especially for 386 Date: 7 Jul 87 05:06:44 GMT Organization: TITN Inc. Hayward, CA I'm working with a systems integrator to distribute '386 systems running UNIX, and are wondering what software is available (or about to become available) under X in the following categories: o CAD/CAM o Desktop Publishing o Office Automation o Engineering Applications o Database/Spreadsheet/etc. o User Friendly Shells o System Administration Tools Since most of the applications designers/implementors are probably net subscribers, I figured this would be the place to get first-hand information. Am also looking for ethernet software under the 386. Also wondering what flavors of UNIX you are running out there, with what level of success, and whose X ports, also with recommendations, flames, etc. To what extent are you working with MicroSoft windows, and what marketing plans do you have for your software under OS/2 & Windows. What impact do you think Windows/OS/2 will have upon the 386/UNIX marketplace? Thanks a lot in advance! Jordan -- ============================================================================= Jordan Bortz Higher Level Software 1085 Warfield Ave Piedmont, CA 94611 (415) 268-8948 UUCP: (decvax|ucbvax|ihnp4)!decwrl!sun!dlb!plx!titn!jordan ============================================================================= ---------------------------------------------------------------- From davidsen@crdos1.uucp Mon Jul 6 10:59:26 1987 To: tomk@intsc.uucp Subject: 80386 mailing list Cc: 386users Date: Mon Jul 6 10:59:26 1987 Tom, I would like to add your name to the 80386 mailing list. Moreover, I would like to invite Intel to make submissions to the mailing list. There have been a number of issues raised about the 80386, and this would be a reasonable "real time" forum in which questions could be answered. The news letter is posted to readers on all nets, and is also posted to USEnet as a single article and appears on at least 3 bulletin boards. Issues raised include: 1. Do I have the multiply bug, and will Intel fix it? 2. How much faster is the 80387 compared to the 80287 *at the same clock speed*. Intel is also welcome to post things which relate to this product. If there is someone in Intel I should contact, please let me know. bill davidsen (wedu@ge-crd.ARPA) {uunet | philabs | seismo!rochester}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me ---------------------------------------------------------------- From tomk@intsc.uucp Thu Jul 9 03:45:50 1987 To: 386users@UDEL.EDU Subject: Re: 80386 Mailing list. Cc: intsc@intelca!rod Date: Wed Jul 8 13:01:34 1987 Bill, I would love to be included on your mailing list. Usually I have the time to respond quickly, but the demands of the job sometimes make that difficult. If I can't I may forward the request on to others in the factory for help. So, count me in. As to the issues that you raised specifically: 1. Is there a problem with the 386 doing multiplies? The official company position is that there was a problem with a test coverage on the early production runs of the 80386. The hole was in the worst case 32 bit multiply. The problem arose because there is a possible race condition in the carry cicuit of the mutiplier, when the carry propagation ripple loses then the result comes out wrong. All parts shipped by Intel after April 13th have been screened for this condition. In June the masks were tweaked to improve our yields of parts that pass the test. As far as parts that had already been shipped to our customers, Intel has extended the warranty on all 386's shipped prior to April for two years. What this means is that the OEM's that Intel shipped parts to can return any untested parts to Intel and we will test them, return the good ones, and replace the bad ones. For the user who has a 386 computer and wants to get the CPU replaced with a tested part he must contact the manufacturer and find out what their policy is. Some manufacturers have stated that since their products are intended to run DOS only there is no need to upgrade the CPU to one that is verified for 32 bit multiplies. So check with your dealer or manufacturer. 2. How much faster is the 80387 compared to the 80287 *at the same clock speed*. If you compare clock counts and play some weighting games, (say that adds and multiplies are more common than sin/cos) the 387 is about 3x the 287 at the same clock rate. Some of this is due to speed up in the execution of instructions, the rest is from the wider data bus. The real difference is very dependant on the instruction mix. Sin and Cos sign speed up significantly because the 387 calculates them directly verses some games that had to be played with the 287 (of course if you are using 88/87 code it doesn't matter). For those who have a 286 machine and need more floating point performance Intel will be coming out with a part called the 80C287 shortly. This is basically a 387 core in a 287 package. The pinout has changed slightly (more power and ground pins) but should be retrofitable with a scrambler board. Also the 80C287 will be available in speeds up 16MHz. Look for data sheets and more product info this fall. ------ "Ever notice how your mental image of someone you've known only by phone turns out to be wrong? And on a computer net you don't even have a voice..." tomk@intsc.UUCP Tom Kohrs Regional Architecture Specialist Intel - Santa Clara ---------------------------------------------------------------- From bboards@udel.edu Mon Jul 6 02:04:08 1987 To: 386users@UDEL.EDU Subject: Contribution for the list Date: Sun, 05 Jul 87 10:27:22 -0400 >>>> Forwarded Message Sender: SCHNUR@a.isi.edu From: SCHNUR@a.isi.edu To: 386users-request@louie.udel.edu cc: schnur@ada20.isi.edu Date: 4 Jul 1987 17:53-EDT Subject: add to list Jim, Please add my name to your list. We have one compaq386 and are getting 3 more for scientific purposes. We are thinking of converting several of our compaqw 286 (old 8mhz) to 386 with the intel 386 inboard. Are there any problems for the unwary in doing this?~r? Joel Schnur (schnur@e.isi) Head, Biomolecular Engineering, Code 6190, Naval REsearch Laboratory >>>> End of Forwarded Message ---------------------------------------------------------------- From jgrace@cc5.bbn.com Fri Jul 3 10:54:54 1987 To: 386users-request@UDEL.EDU Subject: subscribe me to 386users Date: Fri, 03 Jul 87 10:54:54 -0400 Sender: Joe Grace <jgrace@CC5.BBN.COM> Bill, could you sign me up for your 386 mailing list. I currently use an (6 Mhz) IBM PC/AT. Thanks, Joe Grace (jgrace@bbn.com) ---------------------------------------------------------------- From bboards@udel.edu Wed Jul 8 17:11:46 1987 To: 386users@UDEL.EDU Subject: 386users contribution Date: Wed, 08 Jul 87 08:48:36 -0400 >>>> Forwarded Message From: RKIRCHNE%carleton.edu@relay.cs.net To: 386users-request@louie.udel.edu Date: Tue, 7 Jul 87 06:14 CDT Subject: Getting on the 386user's mailing list We have ordered a 386 from FiveStar with fingers crossed that it will run stuff for the 386. Most of my applications are DOS based -- Scheme, Personal Consultant Plus, Turbo, etc. We have ordered Desqview 2.0, but I'm interested in a unix which also allows me to use my regular dos programs. We are also getting a couple of Suns and PC-NFS for a couple of PCs. Thus am interested in NFS support. Please put me on your mailing list. The few messages that were included on PC Info mailing are very interesting to me. Thanks. Roger Kirchner rkirchne@carleton.edu on CS Net. Hope this gets to you. >>>> End of Forwarded Message ---------------------------------------------------------------- From Cleve.AWEST@MIT-Multics.ARPA Tue Jul 14 02:04:38 1987 Date: 13 Jul 87 20:54 EST Subject: 386 mailing list - add me To: 386users-request@UDEL.EDU I have been told you were involved in a 386 mailing list. If such a list exist could you tell me what to do to have nmy name added to it. Thank you very much. Pascal Cleve -at Mit-Multics ---------------------------------------------------------------- From brian@cognos.uucp Tue Jun 30 21:39:59 1987 Sender: brianc@cognos.uucp (Brian Campbell) To: 386users@UDEL.EDU Subject: Phar Lap software for 386 Date: 30 Jun 87 21:39:59 GMT Organization: Cognos Incorporated, Ottawa, Canada Is anyone familiar with a company named "Phar Lap Software?" There is a reference to this company in the July '87 Byte in an article entitled "High Tech Horsepower." Two of this companies products are mentioned: a 386 Linker, and a utility named "RUN386" which allows applications to run in protected mode while fully exploiting the 80386's 32-bit capabilities. Does anyone have any more information on this firm, such as an address or phone number? Any help would be appreciated. Thanks. -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: 3755 Riverside Drive, Ottawa, Ontario, K1G 3N3 (613) 738-1440 fido: sysop@163/8 ---------------------------------------------------------------- From telesoft!dar Thu Jul 2 18:59:07 1987 Date: Wed, 1 Jul 87 06:29:59 PST To: 386users@UDEL.EDU Subject: Re: 386 Smalltalks The most recent (new) version of Softsmarts Smalltalk - a Xerox Version 2 image for AT compatibles under MSDOS - runs on the Compaq 386. I don't know of any implementation under {U,Xe}nix. Softsmarts (415)327-8100. -David sdcsvax!telesoft!dar ---------------------------------------------------------------- From jordan@titn.TITN Mon Jul 6 04:02:57 1987 Sender: jordan@titn.TITN (Jordan Bortz) To: 386users@UDEL.EDU Subject: X for 386 UNIX Date: 6 Jul 87 04:02:57 GMT Organization: TITN Inc. Hayward, CA Does anyone know where I can get XWindows for AT&T's 386/IX (aka Bell UNIX, aka Interactive Systems/IX) Does anyone have a Hercules driver for the aforementioned beast, and does anyone have a MONITERM driver, too???? Thanks a lot in advance Jordan -- ============================================================================= Jordan Bortz Higher Level Software 1085 Warfield Ave Piedmont, CA 94611 (415) 268-8948 UUCP: (decvax|ucbvax|ihnp4)!decwrl!sun!dlb!plx!titn!jordan ============================================================================= ---------------------------------------------------------------- From len@elxsi.UUCP Tue Jul 7 19:45:25 1987 Sender: len@elxsi.UUCP (Len Mills) Subject: X-windows for 386 information request Date: 7 Jul 87 19:45:25 GMT Organization: ELXSI Super Computers, San Jose I seem to remember reading about a project to implement the Xwindows (sp?) environment on 386-based systems. If there exists such an effort, or if there exists such a product, please be so kind as to mail information to me. The interest here is in using 386-based systems as graphics stations attached to *nix systems (sys v and/or 4.[23]) and to also have the ability to use them as standalone systems. Commercial replies welcome. Please mail me-toos. I will respond with a summary to individuals or the list if responses warrant. Thank you. Phone: (408)425-1310 Smail: 2334 Lundy Place, San Jose, CA 95131 -- Len.. {ucbvax!sun,lll-lcc!lll-tis,altos86,bridge2}!elxsi!len ---------------------------------------------------------------- From sl@van-bc.UUCP Thu Jul 2 04:50:52 1987 Sender: sl@van-bc.UUCP (Stuart Lynne) To: 386users@UDEL.EDU Subject: Sys V / 386 Keywords: Unix 80386 BellTech Date: 2 Jul 87 04:50:52 GMT Organization: Public Access Network, Vancouver, BC. I'm contemplating the use of Bell Technologies System V, Release 3, port to the Intel 386 on a Compaq 386 Model 130. With 4 or 5 MB total memory, a six port intelligent communications card (again Bell Tech's ICC card). Has anyone out there used this configuration? Or something similiar? What kinds of experiences have people had with Bell Technologies? They seem to be fairly organized on the phone. And definitely have the right attitude about the cost :-). Would three programmers be to much for this system? We'll be working on a common project so it's unlikely that to many massive multiple make's will be going on at once. Subjectively speaking, will each programmer have the equivalent of say Xenix on an 8Mhz PC/AT? (Fast enough, but you really wish you could have got the 12Mhz model.) Bell Technologies claims that their system is a generic System V, with no proprietary enhancements. What have they left out so they could charge about a third of their major competitors? I saw some benchmarks with Xenix 386 on an Intel Inboard 386/AT at 16Mhz with the cache enabled. Dhrystone 4603/4922. Is this realistic, and will there be comparable results from a Compaq 386 at 16Mhz? Any comments or suggestions will be appreciated. Please respond by mail. I will post a summary if enough material to do so. Thanks. -- Stuart Lynne ihnp4!alberta!ubc-vision!van-bc!sl Vancouver,BC,604-937-7532 ---------------------------------------------------------------- From aeusesef@csun.UUCP Sender: aeusesef@csun.UUCP (Sean Eric Fagan) To: 386users@UDEL.EDU Subject: 80386 Multiplication Bug Date: 2 Jul 87 20:20:26 GMT Organization: California State University, Northridge [] After hearing (here and elsewhere) about the 80386 multiplication bug, I was hoping someone could tell me more about it. For example, I know it shows up in 32-bit multiplies, but how? What happens? Can I get some examples of data with the corresponding wrong answers? Thank you for your support. ----- Sean Eric Fagan Office of Computing/Communications Resources (213) 852 5742 Suite 2600 1GTLSEF@CALSTATE.BITNET 5670 Wilshire Boulevard Los Angeles, CA 90036 {litvax, rdlvax, psivax, hplabs, ihnp4}!csun!{aeusesef,titan!eectrsef} -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" - /l