Xref: utzoo comp.arch:11604 comp.sys.ibm.pc.rt:1007
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bloom-beacon!spdcc!ima!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.arch,comp.sys.ibm.pc.rt
Subject: Re: integer alignment problems on RT
Keywords: RT 6150 032 ROMP alignment
Message-ID: <1989Oct2.194438.5473@esegue.segue.boston.ma.us>
Date: 2 Oct 89 19:44:38 GMT
References: <162@eliza.edvvie.at>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 22

In article <162@eliza.edvvie.at> johnny@edvvie.at (Johann Schweigl) writes:
>The thing that's very suspect to me is, that the CPU simply aligns the adress
>internally and writes the int to the new, aligned adress.

Yes, that is what the ROMP does.  I wrote the original ROMP AIX C compiler
and assembler.  There's no doubt that for debugging it would have been
somewhat easier if the processor faulted on a misaligned address rather than
just ignoring the low bits, but it wasn't all that tough.  I gather that the
ROMP's designers found that they could speed things up by leaving out the
alignment check.  Other than in code written by the "computer == Vax" crowd,
or perhaps the "computer == PC" crowd, misalignment is not a very big problem
in practice.

Most other RISC CPUs fault on misaligned addresses.  Most CISC CPUs accept
misaligned addresses at some loss in performance relative to aligned
addresses.  The ROMP's behavior is a little surprising, but not unreasonable.
As noted elsewhere, one could use the low two address bits as tags of some
sort, though I haven't seen a Lisp system that does so.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869
johnl@esegue.segue.boston.ma.us, {ima|lotus}!esegue!johnl, Levine@YALE.edu
Massachusetts has 64 licensed drivers who are over 100 years old.  -The Globe