Xref: utzoo comp.arch:11700 comp.sys.ibm.pc.rt:1038
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!calgary!ctycal!ingoldsb
From: ingoldsb@ctycal.UUCP (Terry Ingoldsby)
Newsgroups: comp.arch,comp.sys.ibm.pc.rt
Subject: Re: integer alignment problems on RT
Message-ID: <486@ctycal.UUCP>
Date: 4 Oct 89 23:02:17 GMT
References: <162@eliza.edvvie.at>
Organization: The City of Calgary, Ab
Lines: 38
Keywords: RT 6150 032 ROMP alignment
Summary: Clipper does it too.

In article <162@eliza.edvvie.at>, johnny@edvvie.at (Johann Schweigl) writes:
> 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'. 
...
> 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.
> 
> I tried the same on my '386 AIX machine, and, whistle and bells, this one
> does not take care of anything. If you write an 4 byte int to any address,
> odd and wherever you want, the CPU does it.
> 
> 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
> - 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

Aha!  You too have fallen pray to this nefarious feature!  One of my co-workers
and I spent *hours* looking for an obscure bug in some code that was running
on an Intergraph Clipper workstation.  That processor can only write double precision
values to 8 byte aligned words (did that make sense?).  ie. addresses ending in 0 or
8 hex.  If you try to write it elsewhere it thoughtfully strips the lower address
bits and stores it at the nearest lower oct byte aligned address.  This restriction
may be limited to values stored on the stack, I'm not sure.  In any case, the
CPU gives no error trap, and it is up to the programmer to figure it out.

While this feature is documented, it can be annoying if one is doing sorcery.
In most cases the compiler takes care of everything for you, but it can be
fooled.  Yes, I wish a trap was generated.

-- 
  Terry Ingoldsby                       ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                           or
  The City of Calgary         ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb