randy@chinet.UUCP (Randy Suess) (01/01/70)
>In article <1583@chinet.UUCP> I write: >> From what I understand, Bell's UNIX is re-packaged Microport >> UNIX. > Well, seems I understand wrong. I got this via email today. ----- From: Richard Morris <itivax!umix!utah-gr!science.utah.edu!GU.MORRIS> I have recently spoken to the folks at Bell Technologies concerning their UNIX System V/386. It was created by AT&T, Intel, and Interactive Systems, and is not derived from Microport who has yet to release their UNIX for the 386. Bell Technologies System V/386 has recently undergone AT&T certification. Hope this is of interest to you. If you need additional information about the Bell Technologies products, you can contact Dimitri Rotow at Bell Tech. (415) 659-9097. They are very nice folks to work with. Could you please post this information on the Usenet. I am currently on a DEC-20 with a BBOARD system, and I haven't yet figured out how to post only reply to posted items. Thank you. Richard Morris ------- -- that's the biz, sweetheart..... Randy Suess ..!ihnp4!chinet!randy
mikep@ism780c.UUCP (Michael A. Petonic) (01/01/70)
In article <375@kksys.UUCP> gk@kksys.UUCP (Greg Kemnitz) writes: >In article <1583@chinet.UUCP> randy@chinet.UUCP (Randy Suess) writes: >> >> From what I understand, Bell's UNIX is re-packaged Microport >> UNIX. > >True, Bell -has- been selling Microport UNIX -- the 286 version! > >The 386 version I was referring to is different, tho... and they have >told me that it is -not- from Microport. As a matter of fact, they >were selling against Microport 386 UNIX when they called me about it. O.K., I'm not the authority on what goes on everywhere, but they are selling INTERACTIVE Systems 386 UNIX. I couldn't watch this discussion progress to impossible bounds. More than standard disclaimer: Since no-one else in my company spoke up, I did. I do not represent my company in anyway and what I say could be wrong. No further rebroadcast without expressed written consent... Oh, that's the wrong one. --- Michael Petonic {seismo|sdcrdcf}!ism780c!mikep MTS INTERACTIVE Systems Corp. Santa Monica, CA.
gk@kksys.UUCP (09/11/87)
In article <306@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >I also found out that microport is _still_ not shipping unix >for the 386. *sigh* ... But I have heard that the Bell Technologies $99.00 ($399(?) with manuals) 386 UNIX V port -is- shipping. Supposed to be a *full* system including development and text processing. Their number is 800-ibm-UNIX and/or 800-FOR-UNIX. -- Greg Kemnitz | amdahl \ K and K Systems | ihnp4 !meccts!kksys!gk P.O. Box 41804 | rutgers/ Plymouth, MN 55441-0804 | AT&T and clones: (612)475-1527
sl@van-bc.UUCP (09/15/87)
In article <306@kksys.UUCP> gk@kksys.UUCP (Greg Kemnitz) writes: >... But I have heard that the Bell Technologies $99.00 ($399(?) with >manuals) 386 UNIX V port -is- shipping. Supposed to be a *full* >system including development and text processing. > >Their number is 800-ibm-UNIX and/or 800-FOR-UNIX. > $99 gets you two user runtime, no manuals. I don't know what is included in terms of actual software. $399 gets you unlimited user development system. Text processing (nroff/ditroff) not included. All manuals included: the Administrators Reference manual and Admistrators Guide, four Prentice Hall Paper back editions of User's/Programmer's Reference manuals and Guides AT&T 386 Release Notes ** Mild Flame ** Why couldn't Prentice Hall include a permuted index for their reference manuals. They are presented in the classic Unix style with a totally inadequate index which is basically the table of contents reformatted. It makes these books very hard to use. Prentice Hall should include a permuted index! ** Flame off ** So far I've found a few holes and annoyances. No man pages (formatted or unformatted) although the man command is there. The tar command is found in /etc/tar. No csh. The serial driver for the AT style serial ports (asy) seems to be totally insane although that might just be me, or the machine I'm running it on (a Bell Tech 386, aka Intel Mother board). I havn't been able to get it to work consistently with anything other than a terminal. Dhrystone with registers was 2184. Compiling 2.11 news from scratch was 11 minutes real time, with about 7 and 1 minutes of user and system time respectively. An immediate make clean, make redid it in about 9 minutes of real time, user and system where almost identical. One nice thing is the apparent absence of the pointer type problems which plagued Unix systems on previous Intel 80286 chips. News/rn came right up. No special problems. The Basic Networking Utilities (HDB UUCP) seem to work well, except for the usual problems of dealing with Hayes type modems. This is exaberated by the problems experienced with the serial drivers. Perhaps when the dust settles with them using smart modems will be no problem. Overall I'm quite happy with it. Bell Tech seems to be quite interested in getting problem reports and fixing things. Although it can sometimes take a few days for their tech support people to get back to you. -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
leech@unc.cs.unc.edu (Jonathan Leech) (09/18/87)
Summary: Expires: Sender: Distribution: Keywords: In article <1337@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >In article <306@kksys.UUCP> gk@kksys.UUCP (Greg Kemnitz) writes: >>... But I have heard that the Bell Technologies $99.00 ($399(?) with >>manuals) 386 UNIX V port -is- shipping. Supposed to be a *full* >>system including development and text processing. > >Dhrystone with registers was 2184. Is this a misprint, or has Bell set a new record for worst 80386 Dhrystone performance? This is a really pitiful number. If the compiler quality in general is this bad, it seems like (much) better price/performance could be obtained by buying an AT clone and getting a 80286 Unix with decent compilers for it. -- Jon Leech (leech@cs.unc.edu) __@/
randy@chinet.UUCP (Randy Suess) (09/18/87)
In article <1337@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >In article <306@kksys.UUCP> gk@kksys.UUCP (Greg Kemnitz) writes: >>... But I have heard that the Bell Technologies $99.00 ($399(?) with >>manuals) 386 UNIX V port -is- shipping. Supposed to be a *full* >>system including development and text processing. From what I understand, Bell's UNIX is re-packaged Microport UNIX. -- that's the biz, sweetheart..... Randy Suess ..!ihnp4!chinet!randy
lmg@sfmin.UUCP (L.M.Geary) (09/18/87)
[ Various Bell Technologies UNIX System info deleted. ]
> Dhrystone with registers was 2184.
^^^^
I checked out a pre-release version of the raw Intel 386 port on
a Compaq 386 (2Mb RAM) and got similar Dhrystone numbers. However, I got
around 3350 Dhrystones using Microport V/AT 1.3.6 (the 286 binaries).
Turbo C gave around 3500 Dhrystones.
What's going on here? Earlier posted Dhrystone results showed 386 boxes
running the 386 Intel port at > 5000 Dhrystones. Now I'm seeing a 40%
performance DECREASE over the 286 versions of the system! And it isn't
just benchmarks; the system feels slower, too. Something is wrong.
Larry Geary
ihnp4!attunix!lmgIsaac_K_Rabinovitch@cup.portal.com (09/19/87)
sl@van-bc.UUCP (Stuart Lynne) writes:
X** Mild Flame **
XWhy couldn't Prentice Hall include a permuted index for their reference
Xmanuals. They are presented in the classic Unix style with a totally
Xinadequate index which is basically the table of contents reformatted. It
Xmakes these books very hard to use.
I glanced at the P-H version, and I noticed that the semaphores man page
talks about "doing semaphores automatically". In the ATT 5.2 version this
was "automatic semaphores" and in the 5.0 version, it was "atomic semaphores".
People who actually know how semaphores will tell you which is correct.
"Cap'n, she won' go Warp 8! We're critical mass on the manual r)
Newsgroupjohnl@ima.ISC.COM (John R. Levine) (09/19/87)
In article <1583@chinet.UUCP> randy@chinet.UUCP (Randy Suess) writes: >In article <306@kksys.UUCP> gk@kksys.UUCP (Greg Kemnitz) writes: >>... But I have heard that the Bell Technologies $99.00 ($399(?) with >>manuals) 386 UNIX V port -is- shipping. Supposed to be a *full* >>system including development and text processing. > From what I understand, Bell's UNIX is re-packaged Microport > UNIX. No, Bell Technologies is shipping the AT&T/Intel/Interactive version that Interactive Systems did. (This is what friends at ISC tell me.) I'd be interested in hearing comparisons of Microport vs. ISC Unix. They're both based on recent versions of Sys V, so you'd expect them to be similar. Are they binary compatible, or is that too much to expect? -- John R. Levine, Cambridge MA, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something The Iran-Contra affair: None of this would have happened if Ronald Reagan were still alive.
mike@cimcor.UUCP (Michael Grenier) (09/19/87)
Randy Suess writes: > From what I understand, Bell's UNIX is re-packaged Microport > UNIX. > I know that isn't true because when talking to the technicians at Bell about running their intelligent controller card under 386 Microport, they hadn't gotten Microport's code yet (This was after they were shipping their version of 386 UNIX). Microport is shipping their software with the Greenhill C compiler, Bell isn't. Microport is shipping the Beta release of their 386 DosMerge, Bell isn't. In fact, Susan Ong of Bell said that the reason they don't have DosMerge yet is because they are waiting for Locus to do the port to Interactive System's 386 Unix and then use that. -Mike ihnp4!meccts!cimcor!mike - A happy Microport system.
gk@kksys.UUCP (Greg Kemnitz) (09/21/87)
In article <1583@chinet.UUCP> randy@chinet.UUCP (Randy Suess) writes: >In article <1337@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >>In article <306@kksys.UUCP> gk@kksys.UUCP (Greg Kemnitz) writes: >>>... But I have heard that the Bell Technologies $99.00 ($399(?) with >>>manuals) 386 UNIX V port -is- shipping. Supposed to be a *full* >>>system including development and text processing. > > From what I understand, Bell's UNIX is re-packaged Microport > UNIX. >Randy Suess >..!ihnp4!chinet!randy True, Bell -has- been selling Microport UNIX -- the 286 version! The 386 version I was referring to is different, tho... and they have told me that it is -not- from Microport. As a matter of fact, they were selling against Microport 386 UNIX when they called me about it. -- Greg Kemnitz | amdahl \ K and K Systems | ihnp4 !meccts!kksys!gk P.O. Box 41804 | rutgers/ Plymouth, MN 55441-0804 | AT&T and clones: (612)475-1527
jay@splut.UUCP (Jay Maynard) (09/22/87)
In article <1318@unc.cs.unc.edu>, leech@unc.cs.unc.edu (Jonathan Leech) writes: > In article <1337@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: > > [discussion about Bell Technologies' 386 Unix] > >Dhrystone with registers was 2184. > > Is this a misprint, or has Bell set a new record for worst 80386 > Dhrystone performance? This is a really pitiful number. If the > compiler quality in general is this bad, it seems like (much) better > price/performance could be obtained by buying an AT clone and getting > a 80286 Unix with decent compilers for it. By general consensus, it seems Microport's compiler isn't all that swift (seems to be a bit buggy), but I haven't seen performance numbers on it, and I thought Dhrystone was fairly compiler-independent. (showing my ignorance again... :-) Has anyone run it under Microport? How fast was it? I'd like to run it myself, but have never seen it. Where can I obtain a copy? Is it PD, or is there money involved? Does it float around the net at times? If it's PD, would some kind soul mail me a copy? (Please E-mail first, if you do...my /usr filesystem runs mosty full.) Thanks for anyone's help... -- Jay Maynard, K5ZC (@WB5BBW)...>splut!< | uucp: hoptoad!academ!uhnix1!splut!jay Never ascribe to malice that which can | or sun!housun!nuchat!--^ be adequately explained by stupidity. | GEnie: JAYMAYNARD CI$: 71036,1603 The opinions herein are shared by neither of my cats, much less anyone else.
dave@sdeggo.UUCP (09/25/87)
In article <380@micropen>, dave@micropen (David F. Carlson) writes: > Are there any beta sites that can confirm or deny these rather reasonable > claims? Has anyone *ever* had a demonstrable, verifiable compiler bug > with the Microport PCC-based compiler? > -- > David F. Carlson, Micropen, Inc. > ...!{seismo}!rochester!ur-valhalla!micropen!dave > > "The faster I go, the behinder I get." --Lewis Carroll There are two compiler bugs which I know of. One was apparently introduced when the compiler was ported to the 80286, since a statement of the form: struct dummy { char z[1000]; }; struct dummy * x[100][100]; will generate a "array too large" error, however, if you substitute char * for struct dummy * it will pass it (and it will work too). That's a nice little math mistake, since it appears that they're taking the size of the structure instead of the size of the pointer to the structure. The following program causes the compiler to screw up the assembly language it outputs: #include <stdio.h> main() { double test; test=0.0000001; printf("test is %f\n",test); } Here is the output: .file "test.c" .data .text .def main; .val main; .scl 2; .type 044; .endef .globl main main: enter $.F1,$0 .data .even .29: .double :e-08 ^^ the assembler doesn't like this line, which should be 1e-06. It only dies on this particular number (well, I haven't done an exhaustive search, but other numbers in this range do not replicate the problem) and only if the variable is a double. .text lea -8(%bp),%di mov $.29,%si mov $4,%cx rep smov (%si),(%di) .text lea -8(%bp),%si sub $8,%sp mov %sp,%di mov $4,%cx rep smov (%si),(%di) push $.31 call printf add $10,%sp .28: leave ret .def main; .val .; .scl -1; .endef .set .T1,1 .set .S1,0 .set .F1,8 .data .31: .string "test is %f\n" ----- There have also been quite a few problems with int <-> floating point casts, though this may just be caused by 16 bit ints. It tends to come up with some very bizarre numbers at times. The structure size bug is definitely the most annoying to me, since it breaks a large amount of exsisting code and requires doing a lot of casts on char * arrays to make things work. The .0000001 bug is more annoying than anything else, but it took quite a while to pin down, since the first time it popped up for me was in the middle of compiling empire, and no one at Microport could explain the assembler format so I could determine what line number it had occured at. Messy! -- David L. Smith {sdcsvax!amos,ihnp4!jack!man, hp-sdd!crash, pyramid}!sdeggo!dave sdeggo!dave@amos.ucsd.edu "How can you tell when our network president is lying? His lips move."
scott@helium.UUCP (Scott Hazen Mueller) (09/25/87)
In article <380@micropen> dave@micropen (David F. Carlson) writes: >Are there any beta sites that can confirm or deny these rather reasonable >claims? Has anyone *ever* had a demonstrable, verifiable compiler bug >with the Microport PCC-based compiler? >David F. Carlson, Micropen, Inc. Helium is a beta site for V/386. I found a *something* in the compiler. I wouldn't call it exactly a bug... Here's what I sent in: --- included text --- There seems to be a bug in the compiler or assembler. The following source code: typedef struct object { char posx, posy; char velx, vely; struct object *next, *prev, *contend; long energy; long mass; char type; char image; char strategy; char flags; } OBJECT; void their_smarts() { register OBJECT *obj; setimage(obj, (obj->velx *= -1) < 0 ? '>' : '<'); } compiles to the following assembler code: .file "yukfoo.c" .version "02.01" .data .text .align 4 .def their_smarts; .val their_smarts; .scl 2; .type 040; .endef .globl their_smarts their_smarts: pushl %ebp movl %esp,%ebp pushl %eax pushl %edi leal 2(%edi),%eax movl %eax,-4(%ebp) movl %eax,%edx imulb $255,(%edx),%dl movb %dl,(%eax) testb %dl,%dl jge .L16 movl $62,%eax .L17: pushl %eax pushl %edi call setimage addl $8,%esp /ASMQ movl -8(%ebp),%edi /ASMEND0 leave ret .L16: movl $60,%eax jmp .L17 .align 4 .def their_smarts; .val .; .scl -1; .endef .data .text and then the compilation terminates with the error Assembler: yukfoo.c aline 16 : syntax error The compiler is invoked with "cc -c -O yukfoo.c" on the included source. The assembly source was produced with "cc -c -O -S yukfoo.c". --- end included text --- (Note: the source code was from Larry Wall's "warp" game...) Reply received: --- more included text --- I've reported the problem to our 386 group and they have reproduced the problem. We're checking to see if it's still a problem in the 2.0 release of V/386 rel 3. Date: Wed, 29 Jul 87 10:40:18 PDT Subject: C bug & Build disk C bug: It turns out that the *= operator is not supported. This is what's been causing you all the grief. The work-around should be pretty simple. --- end inclusion --- The fix worked; however, I wouldn't call non-support of a standard operator just a bug. "It aint' C" :-) \scott -- Scott Hazen Mueller City of Turlock 901 S. Walnut Rd. Turlock CA 95380 (209) 668-5590 lll-crg!csustan!helium!scott uunet!zorch!helium!scott
mjy@sdti.UUCP (Michael J. Young) (09/25/87)
In article <98@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >In article <380@micropen>, dave@micropen (David F. Carlson) writes: >> Are there any beta sites that can confirm or deny these rather reasonable >> claims? Has anyone *ever* had a demonstrable, verifiable compiler bug >> with the Microport PCC-based compiler? I don't know anything about the 386 compiler, but the following code breaks the 286 compiler: int *alloc(); int kl() { int s; char *am; (am == 0) ? (am = (char *) alloc((long) s)): 0; } Compiling the above function in large memory model causes an internal compiler error : register allocation error. The generated code (up until the compiler aborts) is: .file "t1.c" .data .text .def kl; .val kl; .scl 2; .type 044; .endef .globl kl kl: enter $.F1,$0 test -4(%bp) jne .10000 test -6(%bp) jne .10000 .10001: mov -2(%bp),%ax cwd push %dx push %ax lcall alloc add $4,%sp mov %ax,-6(%bp) mov %dx,-4(%bp) jmp .10002 .10000: xor %ax,%ax xor %dx,%dx .10002: mov %ax,%bx ; oops! mov %bx,%ax I'd be interested to hear if this problem is also present in the 386 compiler. The conditional construct that causes wedges the compiler is frequently generated by C++. In fact, the code fragment I included here was given to us by Bjarne Stroustrup as proof that C++ could not easily be ported to a 286 machine that used the intel pcc-based compiler. (I have heard that other non-pcc-based compilers, such as Metaware's High-C, do not have this problem). Anyone with a beta copy of System V/386 care to try it and see if it works? -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel : +1 617 443 5779
jaym@nuchat.UUCP (Jay Maynard) (09/29/87)
In article <380@micropen>, dave@micropen (David F. Carlson) writes: >In article <158@splut.UUCP>, jay@splut.UUCP (Jay Maynard) writes: >>By general consensus, it seems Microport's compiler isn't all that swift >>(seems to be a bit buggy), but I haven't seen performance numbers on it, and >>I thought Dhrystone was fairly compiler-independent. (showing my ignorance >>again... :-) Has anyone run it under Microport? How fast was it? >> >>Never ascribe to malice that which can >>be adequately explained by stupidity. <-- favorite quote... > >I *will* ascribe this to stupidity. > >The 80286 compiler for Microport is PCC-based. Thus, except for the code >generator and the optimizer phase, it is as bug free as any compiler with >ten years of track history can be. I got the idea that the Microport compiler was somewhat buggy from the long list of compiler bugs in the official Microport bug list. Next time one goes floating through comp.unix.xenix (or the Microport group, if it ever gets created), check it out. >Has anyone *ever* had a demonstrable, verifiable compiler bug >with the Microport PCC-based compiler? From the looks of it, and the messages floating through this group in the past week, it appears that lots of folks have. I have even run across a couple myself (most notably while trying to compile sc [spreadsheet calculator] off of the net; it complained until I chopped the sheet size by 3/4 because of the well-known array of pointers size bug). Most of them are nits, but, still, some of them are real nuisances. I was going from a wide variety of reported cc problems, and, whether or not it's PCC-based, it's still buggy. -- Jay Maynard, K5ZC (@WB5BBW)...>splut!< | temporarily at uunet!nuchat!jaym Never ascribe to malice that which can | while splut is down (@#*(&$% ST4051!!) adequately be explained by stupidity. | GEnie: JAYMAYNARD CI$: 71036,1603 The opinions herein are shared by neither of my cats, much less anyone else.
jmsully@suprt.UUCP (10/02/87)
In article <1595@chinet.UUCP>, randy@chinet.UUCP (Randy Suess) writes: > >In article <1583@chinet.UUCP> I write: > >> From what I understand, Bell's UNIX is re-packaged Microport > >> UNIX. > > > > Well, seems I understand wrong. I got this via email today. > ----- > > From: Richard Morris <itivax!umix!utah-gr!science.utah.edu!GU.MORRIS> > I have recently spoken to the folks at Bell Technologies concerning their > UNIX System V/386. It was created by AT&T, Intel, and Interactive > Systems, and is not derived from Microport who has yet to release their > UNIX for the 386. Bell Technologies System V/386 has recently undergone > AT&T certification. Microport is shipping System V/386. It is derived from the same Interactive- Intel source code as the Bell-Tech version and, since the code on which these two ports are based is the same, has also passed AT&T certification. -- John M. Sully UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!techs Microport Systems ARPA: uport!techs@ucscc.UCSC.EDU Technical Support
mdg@suprt.UUCP (10/03/87)
In article <108@suprt.UUCP>, jmsully@suprt.UUCP (John M. Sully) writes: > In article <1595@chinet.UUCP>, randy@chinet.UUCP (Randy Suess) writes: > > >In article <1583@chinet.UUCP> I write: *** verbiage deleted *** > > UNIX for the 386. Bell Technologies System V/386 has recently undergone > > AT&T certification. > > Microport is shipping System V/386. It is derived from the same Interactive- > Intel source code as the Bell-Tech version and, since the code on which these > two ports are based is the same, has also passed AT&T certification. > Not only is Microport shipping 386 UNIX, Microport was the first company to ship 386 UNIX, to my knowledge. Was anyone shipping 386 UNIX before June 25th of this year? -- Marc de Groot @ Microport Systems, Inc. UUCP: {hplabs, sun, ucbvax}!amdcad!uport!mdg FONE: 408 438 8649 Ext. 31 DISCLAIMER: "..full of sound and fury, not necessarily agreeing with anyone.."