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