enped@conexch.UUCP (Eric Pederson) (10/01/87)
I guess the question on my mind now is this: since the 386 has such a large address space, and since it *can* support segments over 64K, will we benefit with Unix 386? What I'm really asking is this: will we get to do away with the memory model foolishness that we have had to deal with in 286 *NIXes for so long? ------------- Eric Pederson HBUHSD 714 964 3339 lino
jack@turnkey.CTS.COM (jack) (10/06/87)
In article <143@conexch.UUCP>, enped@conexch.UUCP (Eric Pederson) writes: > I guess the question on my mind now is this: since the 386 has such a large > address space, and since it *can* support segments over 64K, will we benefit > with Unix 386? What I'm really asking is this: will we get to do away with > the memory model foolishness that we have had to deal with in 286 *NIXes > for so long? Yes, Eric, in SCO Xenix 386 you still have segments (presumably for downward compatability) but they are now 4 Gigabyes. Also, there is only one memory model, large (all segment registers, and hence pointers are now 32 bits wide). So there will be no more need to fool with makefiles to determine which memory library to call for. I assume this will also be the case with packages such as 386/ix from Interactive or Microport's release (whenever it becomes available). -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...!uunet!ccicpg!turnkey!jack Internet: jack@turnkey.CTS.COM
dyer@spdcc.COM (Steve Dyer) (10/08/87)
This may be picking nits, but: In article <140@turnkey.UUCP>, jack@turnkey.CTS.COM (jack) writes: > Also, there is only one memory > model, large (all segment registers, and hence pointers are now 32 bits wide). XENIX 386 has only one memory model, SMALL (actually, split I/D). There are no explicit loads/reloads of segment registers within user code generated by the C compiler. All pointers are 32-bits wide, which reflects the native size of the 386 general (cough) registers. "Large" model on the 386 would require 48-bit pointers, with 32-bit offsets and 16-bit selectors. Needless to say, there are many benefits to be had when it comes to porting code from machines like the VAX and 68K family by having pointers and ints the same size. But, yes, it's true. No more segmentation headaches. It's like dying and going to heaven. Linear addresses everywhere. Programs which didn't have a chance of working now "just compile and run". Of course, XENIX 386 provides the ability to generate and run 286 binaries, so if you ever want to remember your "roots", it's just a compiler flag away. Not me, buddy... -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer
mike@cimcor.UUCP (Michael Grenier) (10/09/87)
> a chance of working now "just compile and run". Of course, XENIX 386 provides > the ability to generate and run 286 binaries, so if you ever want to remember > your "roots", it's just a compiler flag away. Not me, buddy... > -- Ah, true, but XENIX 386 only support XENIX 286 binaries in their non COFF format. They do NOT run under UNIX 386. However, AT&T 286 UNIX and Microport 286 UNIX binaries *WILL* run on 386 UNIX wihout modification. What happens when Microsoft drops XENIX in favor of UNIX per their new agrement with AT&T? As the pres. of Microport pointed out - No emulations are perfect! -Mike {rutgers, amdahl, ihnp4} !meccts!cimcor!mike
dyer@spdcc.COM (Steve Dyer) (10/12/87)
In article <387@cimcor.UUCP>, mike@cimcor.UUCP (Michael Grenier) writes: > Ah, true, but XENIX 386 only support XENIX 286 binaries in their non COFF > format. They do NOT run under UNIX 386. However, AT&T 286 UNIX and > Microport 286 UNIX binaries *WILL* run on 386 UNIX wihout modification. I'm still trying to figure out why this response was posted, since I was specifically talking about XENIX, and not anything else, and 286 execution was just a parenthetical remark to its handling of 386 memory models. Anyway, XENIX 386 supports XENIX 286 binaries. I'm sure the final AT&T/ISC/Microsoft XENIX will still support XENIX 286 binaries. Whether it will eventually support other 286 object formats remains to be seen, although I see no reason why they couldn't do it. Anyway, no one is arguing that if you already have a big software investment in AT&T 6300+/Microport 286 binaries, you should go with XENIX 386 in its current state. > What happens when Microsoft drops XENIX in favor of UNIX per their new > agrement with AT&T? As the pres. of Microport pointed out - No emulations > are perfect! I can't speak for Microsoft or SCO, but their track record is one of complete upward compatibility (to a fault :-), one might add, as you look at their implementations of semaphores, locking and shared memory which try to accomodate both Xenix III and System V semantics...) Microsoft isn't dropping XENIX as much as making sure that there will no longer be a host of competing object formats, which, if anything, only fragments the 386 UNIX market and weakens its growth opportunities. To the extent that XENIX 386 and 386 UNIX are both SVID-compliant, and I believe they are, there's shouldn't be any problem handling both COFF and XENIX format 386 objects, and I would imagine that the final XENIX development set will allow you to produce COFF object files; otherwise it wouldn't make sent to use XENIX as a development tool for the entire 386 marketplace. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer
jpp@slxsys.UUCP (John Pettitt) (10/13/87)
In article <140@turnkey.UUCP> jack@turnkey.CTS.COM (jack) writes: > . . . . . . Also, there is only one memory >model, large (all segment registers, and hence pointers are now 32 bits wide). >So there will be no more need to fool with makefiles to determine >which memory library to call for. I assume this will also be the case with >packages such as 386/ix from Interactive or Microport's release (whenever it >becomes available). > There are several memory models in 386 Xenix - small model (4GBytes), large model (in the doc but not compiler passes ?) and 286 (-M2, runs the 286 compiler passes). ISC 386 (and therefore microport ?) seems to default to the Intel 386 small model (4 Gbytes). The Xenix 386 small model code for most of the benchmarks I have run is about 30 to 40 % faster than the 286 version on the same hardware (Dell/PC Limited 386 in our case). There is little or no advantage to the ISC/ATT compiler over the M'soft/SCO version, but I have been told that the greenhills C is very much faster. Xenix 286 bin files run about 10% slower under 386 Xenix than 286 Xenix on the same system. We have had ISC 386 and Xenix 386 running here for some time now and both systems perform well with few bugs. The performance of both is spoilt by the silly system defaults chosen. We run 8+ user boxes with lots of ram and the real throughput can be boosted by a significant factor by adding I/O buffers and other tuning. The settings supplied with Xenix 386 are far too low for an 8+ user box - they are in tune with a 1.5MB 2 terminal system. FLAME PROOF SUIT ON The new Compaq 386/20 with Xenix 386 or ISC V.3/386 appears to be as fast (or faster ?) than many so called mini computer systems in most real user applications. (I have run 16 Uniplex II users on one - If you have used Uniplex you will know what I mean :-) FLAME PROOF SUIT OFF Before the flame starts we run Xenix 286 & 386, Microport 286 and ISC V.3/386 systems in house and the *company policy* is to be os independant! -- John Pettitt G6KCQ, CIX jpettitt, Voice +44 1 398 9422 UUCP: ...uunet!mcvax!ukc!pyrltd!slxsys!jpp (jpp@slxsys.co.uk) Disclaimer: I don't even own a cat to share my views !