<<Please forgive the sketchy details. A co-worker reports runtime errors
on some C code ported to HP/MPE-iX from another platform. He says the
error message or code is same as he gets from a standalone test program
where he attempts to cast pointers to successive bytes as if they were
pointers to longs and then access those longs. I have no docs yet.
 
Does HP3000 (MPE-iX) require boundary alignment for longs or doubles or
other data types? Is there a C compiler directive to either flag such
code when recognizable or even to accommodate such code via extra moves
to/from aligned locations?>>
 
Yes; quantities must be aligned on "natural" boundaries. I.e., 'int's
must be 4-byte aligned, and 'double's on 8-byte boundaries. If you have
code that does something like this:
 struct {
    char value1[3];
    char value2[3];
    int ival;
    } mystruct;
 
the compiler will, by default, insert padding so that the 'ival' member
is properly aligned. However, if you cast a non-4-byte-aligned 'char'
pointer to an 'int' pointer and attempt to dereference it, you'll get an
exception.
 
The HP_ALIGN #pragma has an undocumented parameter of "NOPADDING" that
tells the compiler to allocate data types and structures exactly as
declared, without inserting padding for alignment purposes. However,
there's no way any compiler can know that a cast from a *char to a *int
will or won't be properly aligned, since the actual address to which the
pointer points is determined at run-time.
 
There is a partial reprieve if you have a lot of MPE/V code that, for
example, accesses TurobIMAGE data containing a lot of 16-bit integral
types: the "+u" compiler option, in conjunction with the MPE_16 parameter
to the HP_ALIGN #pragma, will make this 16-bit-based code compile and run
on 32-bit machines without blowing up. However, there's a performance hit
associated with "+u", so only use it where you need it.
 
Check out pages 9-8 through 9-15 of the C/iX manual for more detailed
information.
 
<<The runtime error is occurring in an externally loaded module for which
he doesn't yet have debugging working. We'll fix this error as soon as we
identify the line of code that failed but I'm concerned we may have need
for a global solution rather than "fix it line by line as it fails"
approach.>>
 
Basic rules are things like
 Always put the most-restricted types first in structure definitions. For
the example above, the 'ival' element should be the first element of the
structure. 'short's would come after 'int's and before 'char's. Etc.
 When you have to access values that may not be properly aligned, copy
them byte-by-byte into a properly-aligned variable, and use the copy. For
example,
   int myint;
   memcpy(myint, somepointerthatmightpointanywhere, sizeof(int));
   /* use 'myint' instead of dereferencing the pointer */
 
Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]