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