Xref: utzoo comp.arch:11612 comp.sys.ibm.pc.rt:1009
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!gem.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch,comp.sys.ibm.pc.rt
Subject: Re: integer alignment problems on RT
Keywords: RT 6150 032 ROMP alignment
Message-ID: <754@crdos1.crd.ge.COM>
Date: 3 Oct 89 14:29:17 GMT
References: <162@eliza.edvvie.at>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Followup-To: comp.arch
Organization: GE Corp R&D Center
Lines: 28

In article <162@eliza.edvvie.at>, johnny@edvvie.at (Johann Schweigl) writes:

|  This leads me to the final questions: 
|  - is it acceptable that the CPU changes the adress you delivered without any
|    warning and does something you wouldn't expect

  That's up to you to decide. If I were writing portable code to do this
(and I have) I would use a simple output routine for machines which
force allignment.

|  - how do other CPU's behave (eg. 88000, 68000, SPARC, MIPS)

  The GE600/6000 (now Honeywell DPS) series did this for double access.
The LSB was dropped in the address evaluation. What you are seeing is
the dropping of the two LSBs.

|  - would you prefer getting an 'alignment violation trap' or something 
|    like this

  It would prevent obscure programming errors. It would probably break a
lot of "working programs" if added as an FCO.

|  - does any CPU implement such a trap
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon