>>I am currently working on a project that will be using an DEC Alpha server
>>The application that I am developing in "C", also uses DECMessageQ for passing
>>messages between systems through the network. We have been able to interface
>>standard Vaxes and PCs without too much trouble, except for the Alpha.
>>The message structure that we are using needs to be BYTE aligned, but we are
>>unable to accomplish this. In VMS, there is no problem, and when we perform a
>>SIZEOF() the structure, VMS will respond with a size of 10, where the Unix
>>application says 12. We have tried to compile with the -Zp1 option, but this
>>appears to have no effect.
>Well, the obvious one is don't presume that processor specific alignment
>requirements are portable :-).
>Define an intermediate format, and send that between different
Unix systems run on a large number of processors. If your "message"
structure includes such things as floats, doubles, arrays, etc, you
will find a lot of "interesting" effects, all of which will prevent
proper transfer of information.
I'm familiar with sockets, but not with DECMessageQ. The following
may or may not apply...
Floats, doubles, and especially structures are difficult to pass along
using sockets. Personally, I usually just write-to-ascii and transfer
that. There is *no* problem with passing strings between processes
on the same machine or between the same type of machine.
Different machines, however, may represent floating point in different
ways (sometimes the same machine can have different ways to represent
floats, for example, an SGI's C/C++ compilers' floats are not the same
as those that get loaded into its homogeneous transform hardware).
Many machines these days do use IEEE's standard for floating point, and
so floats between those machines *may* transfer -- test and see.
Even integers have problems: big-endian, little endian (ie. which byte
is high, which low).
Structures are a worse problem. Not only may they include multibyte
integers, floats, and doubles, with all the problems mentioned above,
different compilers may do different things to satisfy memory
constraints (such as, floats must begin on addresses evenly divisible
by 8, etc). They insert "padding" bytes (unused null bytes) in various
places, and not even all compilers for the same platform may do this
the same way.
Your machine may support "XDR: External Data Representation standard"
(1014 Sun Microsystems, Inc., 1987 June; 20p Format: TXT=39316 bytes)
If so, check out "man xdr_simple" for such functions as xdr_bool,
xdr_double, xdr_float, etc. You may use these functions to describe
simple data structures in a machine-independent fashion.
Charles E Campbell, Jr, PhD _ __ __
Goddard Space Flight Center / /_/\_\_/ /