Compiler woes

[Ross Wetmore]

In article <452 at micropen> dave at 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 at water.NetNorth
University of Waterloo          | rwwetmore at math.waterloo.edu
Waterloo, Ontario N2L 3G1       | {clyde, ihnp4, ubc-vision, utcsri}
(519) 885-1211 ext 3491         |   !watmath!rwwetmore