Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.arch
Subject: Re: RISC hard to program?
Message-ID: <3684@auspex.auspex.com>
Date: 18 Jul 90 22:54:18 GMT
References: <2162@opus.cs.mcgill.ca> <3648@auspex.auspex.com> <2163@opus.cs.mcgill.ca>
Organization: Auspex Systems, Santa Clara
Lines: 71

>Here was a particularly clear (to me!) exposition of the
>issue involved (thanks!). To summarize (hopefully without
>changing the poster's meaning :-), I can't easily
>manipulate down to the byte level on a SPARC architecture,
>without telling the compiler I want to do this, and
>without taking a performance hit.

No, you can't easily access *data not aligned on its natural boundary*
without telling the compiler you want to do that.  You can load a single
byte from memory from any (byte) boundary you want.

As for the performance hit, well, even though e.g. the 68020 lets you
load up unaligned 2-byte and 4-byte quantities "in hardware", you still
take a performance hit for it (as I noted in the posting to which you're
responding).

>I know I'm bucking an entire industry trend here, as RISC
>seems to have been a huge commercial success, but this
>argument strikes me as suspiciously like that of a car
>salesman who argues that if I'm willing to buy a car
>without brakes or seatbelts, I can get one that is that
>much faster or cheaper. Sure, but I _am_ getting less car.

Nope.  It's more like "If you're willing to buy a car without an
automatic transmission, you can get one that's faster or cheaper";
that's not an *exact* analogy - can anybody suggest a more exact one? 
How *do* you do shifts at compile-time rather than run-time? :-)

>Actually, the program was a multi-thousand line Pascal
>program (!!) written on a Sun 3 to implement a compiler
>for Sisal, a specialized language for either dataflow or
>parallel processing (I can't remember which and the prof
>concerned is involved in research in both areas). A
>successful compile would give us an executable that would
>take Sisal programs and output something closer to a SPARC
>executable. The program, to my knowledge, was never
>successfully compiled but it may _all_ be due to a buggy
>Pascal compiler (no, no version numbers available).

From "never successfully compiled" can I infer, then, that the program
was never successfully *executed*, either, but that the a version of the
code generator (whatever it was that generated "something closer to a
SPARC executable") had been written to generate SPARC code?

If so, it sounds as if either:

	1) the problem was, indeed, an problem with the Pascal compiler;

or

	2) they never got the code generator to compile.

In both cases, the most likely problem would seem to be generating code
for SPARC - either in the Pascal compiler (Sun's compilers, at least,
have a mostly common front end for all architectures, so it's the back
end where I'd expect big differences betwen Sun-3 and SPARC).  SPARC is
different enough from the 68K (as are a number of other architecturs,
some of which even allow unaligned accesses) that there's no reason to
assume *a priori* that the big problem there had anything to do with
alignment.

>Fair enough. But can I assume that on everyone's wish list
>for Xmas would be a SPARC architecture but without the
>alignment hit?

If I could get it with the same performance (i.e., no performance loss
for properly-aligned references), without sacrificing any capabilities,
and at a minimal extra cost, I'd take it; however, the lack of hardware
support for unaligned references has, as I noted, not really gotten in
my way, so I can think of lots of things I'd put before that on my Xmas
list.