Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: Common Compilers for benchmarks (was: Re: benchmarking)
Keywords: gcc silicon compilers RTL MIPS
Message-ID: <626@quintus.UUCP>
Date: 4 Nov 88 09:37:24 GMT
References: <7352@wright.mips.COM> <26627@ucbvax.BERKELEY.EDU> <609@quintus.UUCP> <1791@pembina.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 40

In article <1791@pembina.UUCP> steve@obed.uucp (stephen Samuel) writes:
>In article <609@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes:
>> In article <26627@ucbvax.BERKELEY.EDU> shs@ji.Berkeley.EDU (Steve Schoettler) writes:
>> It looks to me as though many of the newer machines are designed with
>> C and Fortran *only* in mind.  That's just a comment from someone who
>> reads the manuals:  could anyone who really knows say to what extent
>> ADA and COBOL were studied _when the arhictectures were being designed_?
>
>I don't know about ADA, but my feeling is that the people who really
>worry about COBOL are a bit more worried about moving their code over
>in one piece
>Most of these people tend to stay on their nice big mainframes with
>hords[sic] of I/O bandwidth and a compiler they know and love.

Well, that's not strictly true.  There are quite a few companies that
make a living translating one dialect of COBOL into another.  (Amongst
other things, the COBOL standard keeps changing.)  Moving from an IBM
mainframe to a RISC machine such as the MC88000 shouldn't be any more
of a headache than moving from one mainframe to another, assuming the
COBOL compiler writer has done a decent job.  I have one hand, while
I am typing this sentence, on IBM's "System Applications Architecture
Common Programming Interface COBOL Reference, document SC26-4354-0",
which gives a synoptic view of COBOL under MVS, VM, and ***OS/2***.
And one keeps seeing requests in comp.sources.wanted "how can I get a
COBOL compiler for UNIX machine foobaz, or a COBOL to C translator,
or ...".

Don't misread my earlier posting as saying that RISCs are not suited
to COBOL.  For example, converting an 18-digit DISPLAY number to
64-bit COMPUTATIONAL form can be done _rather_ fast by a decent RISC
with no multiplies at all, so a COBOL compiler should be able to hack
text->binary by generating a little special-purpose subroutine for
each different PICTURE.  (Though I have yet to see a RISC manual which
bothers to explain how.)  What do you do going the other way?

It's not the text->binary conversion, or the requirement for 18 digits
at least (64 bits is enough), or PICTUREs, or even the more exotic
features of the PERFORM statement which make me think that RISC
designers have ignored COBOL, but ON SIZE ERROR.  [It is not good
enough to generate traps; UNIX takes them away from you.]