Xref: utzoo comp.arch:11671 comp.sys.ibm.pc.rt:1029
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!bloom-beacon!eru!luth!sunic!mcsun!tuvie!edvvie!eliza!johnny
From: johnny@edvvie.at (Johann Schweigl)
Newsgroups: comp.arch,comp.sys.ibm.pc.rt
Subject: Re: integer alignment problems on RT
Message-ID: <168@eliza.edvvie.at>
Date: 6 Oct 89 04:18:10 GMT
References: <2396@ibmpa.UUCP>
Organization: Edv GesmbH, Austria/Europa
Lines: 54

From article <2396@ibmpa.UUCP>, by webb@bass.tcspa.ibm.com (Bill Webb):
> (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!).

Your'e right. The Assembler Language Reference for st R1,D2(R2) says 
	"The effective address formed from D2 + 0/(R2) will have it's low-order
        two bits forced to zero."
> 
>  If lint(1) is run against such programs, it complains about a "possible
>  alignment problem"

   Maybe lint catches incosistent pointer usage, I'll try. In case of the
   example I posted to  the net it just says:

align.c
==============
(30)  warning: main() returns random value to invocation environment


==============
function argument ( number ) used inconsistently
    putchar( arg 1 )   	llib-lc(525) :: align.c(44)
    putchar( arg 1 )   	llib-lc(525) :: align.c(48)
    isprint( arg 1 )   	llib-lc(256) :: align.c(48)
    putchar( arg 1 )   	llib-lc(525) :: align.c(52)
    putchar( arg 1 )   	llib-lc(525) :: align.c(56)
function returns value which is always ignored
    printf	    putchar	

Remember that each member of the union _ptr is used according to the rules
for it's type.

> 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. ...

Portability has more faces than are generally are talked about. 
One more for me, that I didn't think of earlyer.
It's ok that the CPU is designed for maximum performance, I just think that 
a trap  on illegal aligned accesses would preserve performance AND make porting
a bit easier.

Bye, johnny
-- 
This does not reflect the   | Johann  Schweigl | DOS machines? 
opinions of my employer.    | johnny@edvvie.at | I don't hate DOS machines. 
I am busy enough by talking |                  | I just feel better when I
about my own ...            |   EDVG  Vienna   | don't see one ...