Xref: utzoo comp.arch:11624 comp.sys.ibm.pc.rt:1016 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!ibmpa!bass.tcspa.ibm.com!webb From: webb@bass.tcspa.ibm.com (Bill Webb) Newsgroups: comp.arch,comp.sys.ibm.pc.rt Subject: Re: integer alignment problems on RT Keywords: RT 6150 032 ROMP alignment Message-ID: <2396@ibmpa.UUCP> Date: 3 Oct 89 23:47:17 GMT References: <162@eliza.edvvie.at> Sender: news@ibmpa.UUCP Organization: IBM AWD Paloalto Lines: 53 > > Environment: IBM PC/RT, ROMP RISC CPU, AIX 2.2.1, standard AIX C compiler > > After two night's hunting for a bug the big enlightment came over me; > with it came the remembrance of the old law 'thou shalt write four byte > integers to word boundaries'. >... (I know you were using AIX, but I'm not enough of an AIX/RT user to know if there is an equivalent document for AIX - one problem with a shelf full of manuals is finding things!). ... 5. ALL MEMORY REFERENCES ARE ALIGNED Word and half-word data are stored most significant byte first and aligned on natrual boundaries. Off-boundary store references are not supported. The two low or one address bits are silently ignored, creating unexpected results. If lint(1) is run against such programs, it complains about a "possible alignment problem" ... > - is it acceptable that the CPU changes the adress you delivered without any > warning and does something you wouldn't expect > - how do other CPU's behave (eg. 88000, 68000, SPARC, MIPS) > - would you prefer getting an 'alignment violation trap' or something like this > - does any CPU implement such a trap > ------------------------------------------------------------------ > EDV Ges.m.b.H Vienna Johann Schweigl > Hofmuehlgasse 3 - 5 USENET: johnny@edvvie.at > A-1060 Vienna, Austria Tel: (0043) (222) 59907 257 (8-19 CET) 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. I won't argue with the assertion that it is usually desirable to get a trap rather than silently ignoring the low-order bits. However, it is generally the case that RISC processors put more demands on the programmer and compiler since less features are implemented in silicon. Newer processors generally either implement off-boundary fetches or provide the traps that you suggest, but have more room on the chips in which to do so. If the RT was being designed today I'm sure that it would have implemented an Interrupt on Unaligned Access bit in the ICS register. Bill Webb (IBM AWD Palo Alto, (415) 855-4457). ...!uunet!ibmsupt!webb All opinions expressed above are my own, and quite often not those of my employer.