Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!sphere.eng.ohio-state.edu!manson
From: manson@sphere.eng.ohio-state.edu (Robert Manson)
Newsgroups: comp.sys.m88k
Subject: Re: Information wanted on m88000 Risc workstations
Keywords: 80386 m88000 Everex Opus UNIX DOS
Message-ID: <75406@tut.cis.ohio-state.edu>
Date: 8 Jan 90 21:22:49 GMT
References: <641@s5.Morgan.COM> <25A64468.11498@paris.ics.uci.edu> <648@s5.Morgan.COM> <1879@xyzzy.UUCP>
Sender: news@tut.cis.ohio-state.edu
Reply-To: <manson@cis.ohio-state.edu>
Organization: y
Lines: 37

In article <1879@xyzzy.UUCP> wood@gen-rtx.dg.com (Tom Wood) writes:
>
>I'd like to entertain a discussion on the FP performance of the 88k.
>I have yet to see a compiler that takes advantage of the pipeline
>on this machine to any extent.
[...]
>So how would you feel if someone were able to
>boost Mflops by a factor of say 3 (or better) by improving the compiler 
>technology?

Seems to me that everybody'd be better off with a smarter assembler.
After all, the changes that we're talking about should be possible
by assembly-code analysis, although I doubt that the level of
optimization achieved would be as good as a smart compiler. I'm
currently working on such an assembler, but I would hope that
such a beastie would be available commercially. The advantage of doing
it in the assembler is that then every compiler gets a performance
boost, and it also benefits any crazed humans that still like/need to
program in assembly.

>	DO 10 J = 1,N
>    10	    A(I,J) = A(I,J) + B(I,K)*C(K,J)
>

Depending on the loop construction, I could see this happening in such
a smart assembler, although it would be easier in the compiler.

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.

>			Tom Wood	(919) 248-6067
>			Data General, Research Triangle Park, NC
>			{the known world}!rti!xyzzy!wood

						Bob
manson@cis.ohio-state.edu