Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!linus!bs
From: bs@linus.UUCP (Robert D. Silverman)
Newsgroups: comp.arch
Subject: Re: RISC is a nasty no-no!
Message-ID: <25699@linus.UUCP>
Date: 29 Feb 88 13:51:18 GMT
References: <179@wsccs.UUCP: <696@nuchat.UUCP> <284@scdpyr.UUCP>
Reply-To: bs@gauss.UUCP (Robert D. Silverman)
Organization: The MITRE Corporation, Bedford MA
Lines: 31

In article <284@scdpyr.UUCP: cruff@scdpyr.UUCP (Craig Ruff) writes:
:In article <696@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
:>From article <179@wsccs.UUCP>, by terry@wsccs.UUCP (terry):
:>[ lots of self-congratulation about how portable his code is, followed
:>  by complaints that it isn't portable to the SPARC ]
:>
:>> THE REASON:  Type-casting.  You can't.
:>
:>FLAME ON!    ( I love this! )
:>
:>WRONG.  It is demonstrably NON-portable code - it failed to port
:>to a working compiler on a reasonable machine.  If the bloody
:>unix kernel runs (and it does) your silly application should, too.
 
There's something about RISC architectures in general that I find 
confusing. Since they (read SPARC or equivalent) have no integer multiply
instructions, any code which has a fair number of these is going to
be slow. This would include any program which had access to 2-D arrays
since one must do multiplications (unless the array sizes are a convenient
power of 2) to get the array indices right. Any code that accesses a[i][j]
should run like a pig on such machines. I've seen some benchmarks that
suggest SUN-4's are in fact slower than SUN-3's on programs that do a 
large amount of integer multiplies/divides. What good is a computer that
can't multiply?

Anyone remember the CADET? It was, I believe, the IBM 1630 and stood for
'Can't Add, Doesn't Even Try'. It did its addition by table lookup.

For people who want to use computers to COMPUTE, it appears that SPARC
is a step in the wrong direction.

Bob Silverman