Xref: utzoo comp.arch:11744 comp.sys.ibm.pc.rt:1063
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb
From: ingoldsb@ctycal.UUCP (Terry Ingoldsby)
Newsgroups: comp.arch,comp.sys.ibm.pc.rt
Subject: Re: integer alignment problems on RT
Summary: Surely the cost would be low
Keywords: RT 6150 032 ROMP alignment
Message-ID: <488@ctycal.UUCP>
Date: 11 Oct 89 23:15:20 GMT
References: <162@eliza.edvvie.at> <2396@ibmpa.UUCP>
Organization: The City of Calgary, Ab
Lines: 25

In article <2396@ibmpa.UUCP>, webb@bass.tcspa.ibm.com (Bill Webb) writes:
> Your final points get into the area of "what should happen with non-portable
> code is used". Other similar cases are "what is the value of * (char *) 0?"
> and ''what is the value of * (short *) "ab"?``. If one uses non-portable code,
> then you are at the mercy of the hardware/software designers as to what you
> get.

The point is arguable (why else would be discussing it :^), but I disagree.
This seems to me to be no less of an unusual event than a divide by zero
and no more code dependent.  ie. it is possible to generate faulty code
that at execution time (when it can't be detected by the compiler) causes
an arithmetic exception.  Similarly addresses can be calculated incorrectly.
Certainly perfect code would never need either kind of hardware support,
but in the real world . . .

In any case, it would seem to me that the number of extra gates to implement
this feature would be very small, even for a RISC chip.  There are things
that should be left out of a RISC chip; things that the compiler can do.
Features that should be included are things that the compiler has little
chance of doing.

-- 
  Terry Ingoldsby                       ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb