🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2430

Re: integer alignment problems on RT

#2430
From: Bill Webb
Date: Tue, 03 Oct 1989 23:47
53 lines
2973 bytes
> 
> 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.
Technical Details
Message-ID: <2396@ibmpa.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!ibmpa!bass.tcspa.ibm.com!webb
References: <162@eliza.edvvie.at>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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