Path: utzoo!attcan!uunet!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.unix.microport
Subject: Re: Microport Announces....
Summary: A few things John forgot to mention
Message-ID: <444@l5comp.UUCP>
Date: 9 Oct 88 09:25:21 GMT
References: <12950@mcdchg.UUCP>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Organization: L5 Computing, Edmonds, WA
Lines: 51

In article <12950@mcdchg.UUCP> plocher@uport.UUCP (John Plocher) writes:
>( Marketing Hype follows;

Carefully edited marketing hype, John edited out the part about Microport
not living up to the outstanding upgrade contracts.

This site at least paid $$$ for automatic upgrades on up to 2 major releases
in a one year period and 10 free bug fixes, all postage paid.

Instead we now find that Microport demands:

1. PROOF OF OWNERSHIP!!! We must return diskettes to Microport to prove we own
it, I thought we did that when we bought the damn update contract???

2. We have to pay them $15 postage. We already paid $$$ for postage, now they
want to stiff us for another $15???

3. The "automatic" upgrade just isn't too damn automatic anymore...

Item 2 is so petty I just can't understand what Microport is up to. We've
already paid Microport MORE than enough to cover the physical costs of the
upgrade.

Also, there is no mention that I can find about those poor souls who just
recently (within last 60 days lets say) purchased System V/386 2.2. Do they
get free upgrades? Do they get reduced price upgrades? Or do they get to
pay full price for an upgrade?

For a company that has otherwise treated at least this customer quite well,
I can't understand this shift (or should I say shaft? :) in position.

Also, as regards the Greenhill's compiler, we haven't seen any major speed
changes using this compiler. The compress program for example was actually
slower compiled with gcc than with the standard cc under certain conditions.
(and we were never able to get gcc to make a compress much faster than one
from cc -O)

Also, those expecting to use the Greenhill's compiler on GNU software may be
in for an unpleasant shock. The gcc compiler does NOT reload registers at
the end of a routine based on an offset off the frame pointer, it just
pops 'em off the stack. Which isn't a problem unless you are using alloca()...
(something GNU software does ALOT of it seems) [NOTE: GNU and Greenhill's
both call their C compilers gcc, when I say gcc in this article I mean the
Greenhill's product] So far Microport hasn't supplied any work around for
this little detail (surely this is a command line switch???)

The Greenhill's compiler is roughly about twice as fast as the standard
cc though. But so far this is the only speed advantage we've seen.

Scott Turner
scotty@l5comp -or- uunet!l5comp!scotty