dave@micropen (David F. Carlson) (04/07/88)
Recently there have been some postings crying about problems in the Microport
compilers. First, let's be fair and note that Microport's compilers are
all AT&T PCC based. Thus, most problems are not theirs at all. The nasty
segmented architecture in the 286 version has some multi-segment problems
that makes multi-segment arrays of pointers (and huge arrays) difficult.
These may be called bugs but 99.99% of all c code I've compiled on the 286
version of these compilers have not required this missing functionality.
If anyone here remembers PDP-11 UNIX compilers, then be grateful that PCC has
~10 years of solid debugged operation.
As for intimations that the 386 compilers are bad, I have found no bugs in
my 6 months of managing professional software developers using it. Please
bring these apparently copious bugs to our attention rather than just
slandering and flaming. Also, to the best of my knowledge, unlike the
286 compiler, Microport received the 386 compiler lock-stock-and-barrel
from AT&T by way of ISC. No value-added whatsoever. As far as comparable
worth, I own a Microsoft 4.0 compiler ($400) that is so buggy that I had
to find another way to get my job done. I would take even the 286 Microport
compiler over *any* Microsoft compiler product any day of the week.
As for the compiler that is used to compile the OS, etc., rest assured that
the Green Hills C is not being used. Nor is it being shipped with the software
development package, as indicated in current advertising. I have had some
experience with the GHC/386 and it is not a UNIX compiler: it has its own
non-UNIX compatible libraries and some of those system calls are similar
enough to Clib functions that mixed mode operation will undoubtably cause
problems. The GHC has some really nice optimization for stack linkage and
register allocation but UNIX people want a compiler that can deal with UNIX
libraries rather than non-shared, non-standard, third party libaries.
Suffice to say, it may be a long time before a third party C compiler is
available on the 386 so don't sweat it.
Although many new users seem to think flaming Microport is great sport, let's
try to improve things rather than just slash at them. Back up reports of
bugs with facts and observations not idle gossip about buggy this or that.
--
David F. Carlson, Micropen, Inc.
...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave
"The faster I go, the behinder I get." --Lewis Carrollrwwetmore@watmath.waterloo.edu (Ross Wetmore) (04/09/88)
In article <452@micropen> dave@micropen (David F. Carlson) writes: > >Recently there have been some postings crying about problems in the Microport >compilers. First, let's be fair and note that Microport's compilers are >all AT&T PCC based. Thus, most problems are not theirs at all. While it is true that those primarily responsible for the Portable Compiler package are AT&T and Intel who jointly, I believe, did the initial port to the 286 architecture, it is still true that MicroPort has been distributing the product in that state for over two years. It is their reputation and their sales that are going to be hurt if they do not fix problems no matter who caused them originally. > The nasty >segmented architecture in the 286 version has some multi-segment problems >that makes multi-segment arrays of pointers (and huge arrays) difficult. There are problems in small model and large model ... they do not even pretend to do huge model. If you don't use the optimizer you are reasonably safe for most 'C' code. 'f77' which uses most of the same code as cback but has not been trimmed to avoid the buggy sections is unusable at least as of Jan '88. As an aside, it is not the segmented architecture that causes problems, but the restrictions in the 286 on the size of segments because it is a 16 bit machine. If you look at Intel's implementation very carefully, there are an incredible number of nifty things that can be done with amazing efficiency using segments. It will be interesting to see where some of this leads with the 386. >Please bring these apparently copious bugs to our attention rather than just >slandering and flaming. [...] As far as comparable >worth, I own a Microsoft 4.0 compiler ($400) that is so buggy that I had >to find another way to get my job done. I would take even the 286 Microport >compiler over *any* Microsoft compiler product any day of the week. This is not a flame of MicroPort whom I consider the most responsive and responsible of all the suppliers, and the best bet for those looking for an affordable complete Unix workstation environment. However, 2 years is a long time to be blocked waiting for fixes to something that was sold under the implication that it worked and would do a particular job. Sometimes public rather than quiet private pressure seems to have more effect. So perhaps it is time for all to suggest to MicroPort that a clean working port of the 'C' and 'f77' portable compilers as distributed in their software development package, is a worthwhile project to pursue. Some of the efficiency improvements might even spill over into other OS problem areas where the MicroPort kernel seems a little sluggish in timely processing of such things as interrupts. >Although many new users seem to think flaming Microport is great sport, let's >try to improve things rather than just slash at them. Back up reports of >bugs with facts and observations not idle gossip about buggy this or that. Hard facts are sometimes difficult to produce without violating non-disclosure agreements. Besides, releasing code details to any source other than MicroPort is not going to help unless they are willing to implement them. Reporting problems to MicroPort and posting explicit examples to the net are not worthless exercises, though. So rather than flames, lets have a barrage of well-documented bug reports that hopefully cannot be ignored. >David F. Carlson, Micropen, Inc. >...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave Ross W. Wetmore | rwwetmore@water.NetNorth University of Waterloo | rwwetmore@math.waterloo.edu Waterloo, Ontario N2L 3G1 | {clyde, ihnp4, ubc-vision, utcsri} (519) 885-1211 ext 3491 | !watmath!rwwetmore
blair@obdient.UUCP (Doug Blair) (04/09/88)
In article <452@micropen>, dave@micropen (David F. Carlson) writes: > > Although many new users seem to think flaming Microport is great sport, let's > try to improve things rather than just slash at them. Back up reports of > bugs with facts and observations not idle gossip about buggy this or that. > Agreed, heartily! Let's face it: most of us bought the SysV/386 from Microport because: 1) It was REAL UNIX, not Xenix 2) It was cheaper than SCO 3) It was available sooner And for a couple of us: 4) Those adoreable SysV/386 headbands We all know UNIX is a constantly evolving system; we all know the 80386 is the current state of the art processor (Please, no flames on this! Those in comp.unix.microport have already made that choice :-)); and we all know microport was able to deliver the product (well, enough to get us running last summer) in timely fashion. In order to secure a place in the market they had to push things a bit - it was probably a choice between shipping something that had a few workarounds or open (but documented and admitted) problems in it and letting SCO run them out of existance. Now it begins to look like SCO/Microsoft is going to have to change their product to conform more to System V standards. Uport won't, so which company made the smarter move? We're talking about an *enormous* batch of software - I've got > 20 high density floppies from uport and it's just flat unreasonable to expect that every single byte on them is perfect in a product that's been out < 6 months. Gawd, there are enough other newsgroups around full of bug reports on the other ports of unix (whups... "UNIX") to remind us that there is *no* bug free unix anywhere - even in flavors that have been on the market for a decade. If you've got a problem with uport, fine. I *expect* to have problems, just the same as I *expect* to have problems with a new car, new spouse or new mailman. I also *expect* that the people who made the car or trained the mailman (Well, OK. The Spouse may require extensive debugging) will take care of it. It is reasonable to expect that microport will do the same. Common sense and common courtesy dictate that they get a fair chance. Doug Blair ___ _ _ _ _ / \ | | | | |_| _| |_ Doug Blair_______312-653-5527 | | || |_ ___ _| | _ ___ __ |_ _| Obedient Software Corporation | | || ==\ / ==\ /== | | | / ==\ | \ | | 1007 Naperville Road_________ \___/ |___/ \___/ \___| |_| \___/ |_|_| |_| Wheaton, Illinois 60187______
steve@nuchat.UUCP (Steve Nuchia) (04/09/88)
From article <452@micropen>, by dave@micropen.UUCP: > Recently there have been some postings crying about problems in the Microport > compilers. First, let's be fair and note that Microport's compilers are > all AT&T PCC based. Thus, most problems are not theirs at all. The nasty Beg your pardon! They sell it. They sold it to me, I paid them money for it. Its their problem. Selling defective merchandise is unfortunate. Selling _known_ defective merchandise is fraud. Go figure. > Although many new users seem to think flaming Microport is great sport, let's > try to improve things rather than just slash at them. Back up reports of > bugs with facts and observations not idle gossip about buggy this or that. I would be more than happy to fix their crocked drivers for them. I have signed an agreement that nominally should have made it possible for me to do so. No code has appeared on my doorstep, despite numerous assurances that it was being looked into. Of course no one ever called or wrote to tell me it wasn't happeing either. I fix broken code for my clients all the time. Having a broken machine at home just because I'm not licensed to have source for it is braindamaged. Maybe what I need to do is offer to let them pay me to fix their stupid broken drivers? If this wasn't a public access machine I probably would have just stolen a driver from somewhere, but I feel like the best way to deal with AT+T is to not piss them off. They aren't as skillful as IBM, but they are at least as treacherous. Maybe I'd better stop now, before I have a stroke or kill somebody or my machine crashes and I have to type this in again... -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947
steve@nuchat.UUCP (Steve Nuchia) (04/13/88)
From article <18094@watmath.waterloo.edu>, by rwwetmore@watmath.UUCP: > This is not a flame of MicroPort whom I consider the most responsive and > responsible of all the suppliers, and the best bet for those looking for an This statement caught me by surprise. Exactly what do you mean by "responsive"? That they answer their phone? Have they actually fixed anything that you've reported to them? Their position seems to be that if it is hurting everyone it needs fixing, otherwise it must be pilot error. Of course they'll make encouraging noises, but I'm bright enough to not sell my clients encouraging noises. > implement them. Reporting problems to MicroPort and posting explicit > examples to the net are not worthless exercises, though. So rather than On what do you base this assertion? > flames, lets have a barrage of well-documented bug reports that hopefully > cannot be ignored. In the early days of comp.unix.microport there was a bug list. As far as I can tell microport fixed some of the cosmetic "problems" from that list. Hurrah for them. They then flasely claimed to have fixed others, and charged for the placebo "upgrade", which was dangerous to install. To be (somewhat) fair, they did (eventually, like after a year of asking for it) make a working /bin/mail and yacc (large arrays) available for the price of a download. Of course with a broken serial driver I have to download it at a snail's pace, on my nickle. You want to talk about _responsive_ --- EVERY TIME I FLAME MICROPORT I GET A CALL FROM SCO. I have received a grand total of 2 unsolicited phone calls and maybe 10 pieces of Email total from microport. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947
steve@nuchat.UUCP (Steve Nuchia) (04/13/88)
From article <489@obdient.UUCP>, by blair@obdient.UUCP (Doug Blair): > If you've got a problem with uport, fine. I *expect* to have > problems, [...] > It is reasonable to expect that microport will [take care of them] > Common sense and common courtesy dictate that they get > a fair chance. I am suffering daily from problems reported over a year ago. who is being fair to whom? I received pretty much every odd numbered beta release of 2.1 (assuming I remember the sequence right) in the early part of 1987. Back then they seemed to be pretty responsive, although some of the particular problems I was having they weren't acknowleging as problems. Typical sequence is I call and say "when I do X, it does Y, fix it." To which the drone on the phone says "no one else is having that problem. Its probably your hardware." Then a few months later, after I've had a chance to verify that other people have called in the same problem AND GOTTEN THE SAME @!#$%^&*( RESPONSE I call them back and confront them (politely) with the fact that they've been lying to us, and ask again if they can fix it. Around this point in the sequence the problem starts showing up on the official bug list. Some time goes by, and then it dissapears from the bug list. Maybe they fixed it, maybe they are just hoping we've forgotten about it. I really got tired of being lied to about whether or not a problem had been reported by others. I am even more tired of placebo fixes. I will be evaluating SCO Xenix, and will report my findings. (Given my feelings about lining Bill Gates' pockets, this is a big step). -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947