Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!quiche!opus!peterd
From: peterd@opus.cs.mcgill.ca (Peter Deutsch)
Newsgroups: comp.arch
Subject: Re: RISC hard to program?
Summary: Some clarifications (and thanks to all those who replied)
Message-ID: <2163@opus.cs.mcgill.ca>
Date: 17 Jul 90 04:21:37 GMT
References: <40088@mips.mips.COM> <2162@opus.cs.mcgill.ca> <3648@auspex.auspex.com>
Organization: SOCS, McGill University, Montreal, Canada
Lines: 254


[ LONG - a candidate for skipping for the faint of heart... ]

I recently posted a fairly tedious and involved question
concerning the difficulties of programming on the SPARC as
compared to the 68k architectures. I have had a number of
users complain that SPARC seems inherently less forgiving
of the programmer, and questioned whether this might not
reflect problems with the architecture. I would like to
thank all those who took the time to answer, either through
email (about 15 to date!) or by posting.

I also would like to clarify somewhat my original posting,
plus comment on some of the many email I recieved.

The general consensus among the SPARC programmers who
wrote seems to be "Yes, the architecture is more
demanding, but this was a design trade-off which yielded a
faster machine. It is documented, thus it is a feature. If
your program fails, it is invariably due to programmers
violating the rules, and is thus poor programming practice
and the fault of the programmer." (my apologies for this
gross simplification, I know the issue is more complex
than that).

The general consensus also seems to be that the
architecture may be somewhat unforgiving, but yields good
results if the rules are followed, ie it is not inherently
"buggy". One writer (I can't recall if it was in email or
a posting) alleged that SPARC is an excellent development
platform, as if your program behaves on SPARC, it should
port to almost any less rigid architecture with a minimum
of effort.

Most who wrote or posted seemed to have missed one part of
my question, where I compared the documented alignment
restrictions of SPARC with the segment pointer problems of
early C compilers on 8088 machines. Here again, a
documented hardware feature has "risen into" the language,
in this case leading to language extensions - "near" and
"far" pointers) as a "workaround". In both cases, smarter
compilers can hide much of this, but probably not all if
you program in C.

It's been a while since I programmed PCs and I'm told the
newer compilers are smart enough to work around a lot of
this, but I was also told at the time we had to worry
about it that this was a "feature" of the architecture (in
the sense that segments were a feature) and they were to
be endured as part of the price of having such a cheap,
readily accessible machine.

A couple of people took my posting as a shot at Sun, or
SPARC, which it really wasn't. I do feel that such things
as structure alignment restrictions, union passing
problems, the need for "near" or "far" pointers, etc all
reflect hardware issues rising into the software layer
and, although probably inevitable in a language such as C,
are a strike against machine architectures where they
occur.

Of course, the benefits of such compromises may outweigh
the costs (as seems to be the case in SPARC) but they
certainly don't qualify for my rigid definition of a
feature (ie if I was offered the identical machine, but
without the "feature" would I be more inclined or less
inclined to buy the machine?). I suspect that most users,
given the choice, would prefer that they not have to worry
about how to access structures, preferring to leave that
to the compiler.

For what it's worth, the SPARC alignment "feature" _does_
qualify for my less rigid definition of a feature (ie if
it's documented it's a feature, if it's not, it's a bug. ;-)

So, without wanting to prolong a discussion by prompting a
flamewar, I would thank all those who wrote in favour of
the SPARC and say that, for my vote, the known, documented
restrictions on alignment are _NOT_ a feature, but a bug.
They are to be endured as the price to pay for a faster
machine, but I wouldn't argue (as some have done) that
they constitute a feature. Your mileage may vary...


While here, I would also like to answer a couple of points
raised in one posting, so here goes:

In article <3648@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
.  .  .
> 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.

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. Acceptable? Maybe. A
feature? Hardly. A bug? I'd say "perhaps", one we've been
conditioned to accept as a feature because the designers
documented it. And the argument that other designers
pulled the same stunt is hardly a rousing defense.

> >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. 

Well, I've cast my vote on this one, that's enough for
me...

> 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.

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.
I for one am waiting with considerable interest to see if
the 68040 arrives too late to resist this trend to
minimalist computing... :-)

> 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.

Agreed, and I agree that a lot of workstations with these
restrictions are being sold. I just can't escape the
feeling that I'm being fed a drop of snake oil here ("Sure
it's tough on you, but the machine is that much faster so
it's a feature!") To be fair, that does not appear to be
this poster's attitude, but I do sense this attitude in the
general thread I started [WARNING - GROSS GENERALIZATION! SORRY! ]

.  .  .

> >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.

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). I
can't only state with confidence that they had a lot of
problems with a program that worked (apparently correctly)
on Sun 3's.

Sorry this is so hazy, but I wasn't directly involved in
any of this, I tried to make that clear in the original
posting.  Much of my concerns arose from "hearsay"
comments, from a variety of users. I am really not
qualified to teach, I'm actually soliciting testimony from
those who are.

.  .  .
> 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. 

I left these in as they appear to be valid comments from
someone "who knows". I figured that if you made it this
far, you were entitled to a knowledable comment or two!

> >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.

Fair enough. But can I assume that on everyone's wish list
for Xmas would be a SPARC architecture but without the
alignment hit? Does it matter? Some people who wrote
talked of 20k lines of code that compiled without error,
then a few hundred lines that caused grief for weeks.
There _IS_ a price being paid for this...


			- peterd