Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!hybrid!scifi!bywater!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.arch
Subject: Re: RISC hard to program? (was: Moto's data predicts...)
Message-ID: <3648@auspex.auspex.com>
Date: 14 Jul 90 17:41:53 GMT
References: <40088@mips.mips.COM> <2162@opus.cs.mcgill.ca>
Organization: Auspex Systems, Santa Clara
Lines: 137

>Preamble: From my own exposure to user complaints about
>unportable software, etc I would allege that that the SPARC
>architecture appears to be inherently less forgiving of the
>programmer than the 68k architecture.

More correctly, the SPARC implementation of C under SunOS, at least, is,
in general, less forgiving of the programmer than the 68K implementation
of C under SunOS.  Much of this is a characteristic of the architecture,
although some could perhaps be worked around in software.

The same is true of many other pairs of UNIX C implementations as well,
for reasons having to do with the architecture, with the compiler, with
the OS, etc..

>I keep receiving reports of software that ran fine on machine 'x' (often
>68k machines, Vaxen etc) but that either wont compile or
>wont run on the Sun 4's. I have had this explained to me
>(by a defender of the SPARC architecture) as being due to
>the fact that the SPARC architecture is less forgiving of
>poor programming (eg byte alignment problem in structures,
>ignoring warning messages, etc). It was stated to me that
>"well-wrtten programs work, if not it's the programmer's
>fault."

I'd agree with said defender.  I'm not sure what the "byte alignment
problem in structures" is; the SPARC C compiler puts structure members
on the boundaries they require, so it's not as if a "poorly-written
structure" can cause the program to blow up by violating an alignment
restriction.

In the Sun C implementation, by default you cannot, say, have a buffer
full of structures that are not necessarily aligned on the proper
boundary for that structure (basically, the most restrictive alignment
boundary for all the members of the structure), and just convert a
pointer to an arbitrary byte in that buffer into a pointer to a
structure and expect it to work.  However, you can specify the
"-misalign" flag to the compiler, and it will generate code that lets
you do this (basically, it tests the alignment of the pointer before
using it; if it's properly aligned, it uses it normally, otherwise it
calls a library routine to access the members of the structure.

However, there's nothing unique to SPARC about this; there's nothing
even unique to RISC about this!  I can think of machines generally
thought of as "CISC" that impose alignment restrictions similar to those
of the SPARC, e.g. all but the most recent of the AT&T WE32K chips. 
Even the PDP-11 and 68K prior to the 68020 required 2-byte alignment for
quantities larger than one byte.

>More specifically, If I accepted the rumours that porting
>to the SPARC was harder as an axiom could I argue that
>this was a "bug" of the architecture, not a feature, in the
>same way that difficulty addressing a 65k array on an 8088
>machine is a residual bug due to limited segment size of
>that chip?

You can argue anything you want.  Whether others will agree with you is
another matter. 

I, for one, would not agree with you if you made that argument.  As
shown by the "-misalign" flag to the compiler, you certainly *can*
access misaligned quantities on a SPARC; it just takes more code, and
extra work by the compiler.

While this does impose a performance penalty, so does accessing
misaligned data on the architectures with which I'm familiar that let
you do so directly.  The performance hit of doing so on SPARC (or other
strict-alignment architectures) is probably greater than that on
68020-and-up (or other loose-alignment architectures); I don't have any
numbers for that, though.

However, if references like that are sufficiently rare in most cases
that whatever performance gain was obtained by leaving hardware support
for that out of SPARC (either by devoting the circuitry to some other
function, or by removing an extra delay from the data path, or by
getting a basically-faster chip out the door sooner, or...) outweighs
the performance loss of doing misaligned accesses in software in most
cases, it may be the right thing to do to leave it out, at least for
those cases.

There may well be problems for which the cost of leaving alignment
restrictions in the instruction set outweighs whatever benefits you got
from leaving it out, but that just argues against using strict-alignment
machines for those particular problems.

Now, the alignment restriction isn't the *only* characteristic of SPARC
and its C implementations that punishes sloppy programming.  Another is
the calling sequence used for passing structures and unions to
subroutines; in most such calling sequences, you can get away with
passing a member of a union to a routine that expects the union, or vice
versa.  That's not the case with the SPARC calling sequence; I think
this is, however, the result of the choice of calling sequence used for
structures and unions 4 bytes or less long, rather than something
imposed by the instruction set architecture.

>Now, a few caveats, disclaimers, etc. Almost all the
>programming problems I have heard about were in C, which
>is an inherently low level language (although at least one
>very large Pascal program, a compiler project, never was
>ported successfully)

What machine was the target for the compiler?  If the target machine was
the same as the machine on which the compiler was being run, "porting"
is more than just recompiling - 68K machine code doesn't generally run
on SPARC machines without some extra work being involved.

>The original motivation for this posting was as a followup
>to a discussion I had that originated from my observation
>that I seem to hear of more porting problems with the Sun
>4's than the Sun 3's. One of my staff disputed my claim,
>claiming that the problem was with poor C programmers, not
>the SPARC (or RISC in general).

The bulk of the problems I've seen in porting code to SPARC have been
due to 1) the aforementioned "passing unions to routines" problem and 2)
code that "knows" how C argument lists are laid out in memory, rather
than using the "varargs" mechanism.  In neither case are those due to
alignment problems.

Neither of these are due to anything peculiar to RISC (CISC compilers
have been known to pass arguments in registers, rather than on the
stack, as well, and use of a register-based calling sequence
contributed, at least in part, to both problems), and neither would have
been problems had the programmer not cheated. 

>Given the (admittedly second-hand) reports of problems, is
>this not a similar hardware problem raising up through the
>language?

The alignment problem can be hidden by the language, at least with more
recent compilers, as I'd noted.

>Note, I am _NOT_ disputing the worth of RISC
>architectures, which have given us dramatic performance
>gains. I'm just asking if we've paid a price in
>"servicability"?

We probably have paid some such price; I suspect it was worth it.