Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!oliveb!sun!joe!petolino
From: petolino%joe@Sun.COM (Joe Petolino)
Newsgroups: comp.arch
Subject: Re: Bad RISC (was: RISC is a nasty no-no!)
Message-ID: <43829@sun.uucp>
Date: 2 Mar 88 17:35:40 GMT
References: <216@wsccs.UUCP>
Sender: news@sun.uucp
Reply-To: petolino@sun.UUCP (Joe Petolino)
Organization: Sun Microsystems, Mountain View
Lines: 27
Keywords: SUN RISC

>>We have been able to port to all machines we attempted, except ...  SUN's new
>>... RISC machine ...
>
>I have since been asked to post a more complete description of the problem.
>	Ok, here goes.   . . .
>
>	1) The processor thinks in words (bus-words) always;  this means if
>	   you want to do something, even if it is manipulation of character
>	   data, it is stored in words.  The problem comes in that the C
>	   compiler on the machine did not make that distinction, and broke
>	   on parameter passes to functions, where a single character element
>	   is sign-extended to int to be passed.  This means that the top bits
>	   were not cleared.  As this was the portable C compiler, I blame it
>	   on the architecture not taking normal (read existing) operations
>	   into account.  If the chip supported byte references, this would not
>	   have happened.

The Sun4 processor chip in fact does fully support byte references to memory,
both signed and unsigned, with all the same addressing modes (and the same
execution speed) as word references.  I believe that C compilers always use
the signed variants.  The above problem description is not very complete, but
it sounds like someone is trying to pass a char into an int parameter and
expects to see the high-order bits cleared.  That doesn't even work on a VAX -
K&R specifically says that sign-extension is machine-dependent.  Who knows
what the problem is?  It's certainly not caused by a lack of byte reference
instructions in the architecture.

-Joe