Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!jarthur!uci-ics!rfg
From: rfg@ics.uci.edu (Ron Guilmette)
Newsgroups: comp.sys.m88k
Subject: Re: Information wanted on m88000 Risc workstations
Message-ID: <25AAEB98.17261@paris.ics.uci.edu>
Date: 10 Jan 90 08:00:23 GMT
References: <75406@tut.cis.ohio-state.edu> <10825@encore.Encore.COM>
Reply-To: rfg@ics.uci.edu (Ron Guilmette)
Organization: UC Irvine Department of ICS
Lines: 43

In article <10825@encore.Encore.COM> soper@maxzilla.encore.com (Pete Soper) writes:
>From article <75406@tut.cis.ohio-state.edu>, by manson@sphere.eng.ohio-state.edu (Robert Manson):
>> 
>> I would have to agree that lack of a good optimizing compiler for
>> the 88k is a major lack-the big gain in FP code on the 88k is the
>> parallelization that can occur.
>
>  Both GNU C and Green Hills C/C++/F77/Pascal are optimizing compilers that
>have 88k code generators available. Surely both have to do instruction 
>scheduling of some sort to suport the 88k.

Yes.  You could call it "instruction scheduling" I suppose.  A better term
might be "naive instruction scheduling".  Attempts to do "sophisticated"
instruction scheduling for these sorts of machines are still mostly
research projects (with the notable exception of the MultiFlow systems).

>Perhaps this area needs more work?

Gee! No kidding?

>Is the 860 so much faster because of raw performance or does it 
>have the same pipeline issues and a compiler that more effectively supports 
>them?

It has many of the same pipelining opportunities and pitfalls.  As far as
I know it does not have good "sophisticated" compilers yet.

It is not even clear to me that the performance (scaled to clock
frequency) is that much better that the 88k.  I have yet to see any
performance numbers for the i860 except those published by Intel.
Does any other source have published numbers?

>  Sort of on this subject, is GNU C the only C compiler shipped with the
>DG box, or is it an alternative to Green Hills? Assuming GNU C is "it",
>does it play well with Green Hills Fortran, which I'm assuming is still
>the official Fortran product? Has DG extended gdb to cover both languages
>or is another debugger used with their Fortran product? 

Why would you think that GDB would have to be extended?  A breakpoint on
a line is a breakpoint on a line, no?  A "list" command lists some source
lines, yes?  What the difference if it's FORTRAN or C?

// rfg