Hi,
> I've noticed many times that char* and int*/void* are not compatible
> on the Alpha. Is this simply an issue of alignment, or are the contents
> actually different (eg. one is bit-shifted for some god-awful reason.)
Hmm, what do you mean by 'compatible' in this respect? You can typecast
between them safely, provided that you don't dereference unaligned int
(32 bit, 4 byte alignment) and long (64 bit, 8 byte alignment) pointers.
You should also try to avoid short, which is not supported natively (OK,
it _is_, by processors who support the BWX instruction set extension, but
careful compilers will not use this even though it is present in
practically all systems today).
Pointer typecasting is generally OK, except on some older architectures
(the LISP machine comes to mind). I'm not aware of any 'modern' designs
where this is an issue.
> Basically, I need to know if you have two 64-bit values stored
> consecutively (e.g. u_int64_t v[2]), is there a portable way to
> get a pointer to, say, the second 8-bit byte in v[1]? (That is,
> the actual second byte in v[1] regardless of machine endianness)
That's an endianness issue, then. Alpha, like IA32 and unlike PPC and
SPARC, is little endian (The actual CPU spec mentions that Endianness can
be determined by the implementor, but I haven't seen any BE Alphas yet).
Anyway, if you have these kinds of values and really desparately need the
second byte (and _not_ a u_int64_t* to the second byte, which you should
try to avoid), you can just typecast to char* and increment by one.
If you're on a BE system, the success of this depends on what you meant
with the second byte- if you wanted a reference to the bits
containing the value you'd have gotten by doing
(foo >> 8) & 255
(i.e. the second least significant byte), this would be the 7th byte on BE
architectures- I don't know if there's a way to do this without
distinguishing between endiannesses using a preprocessor directive
(note that autoconf has a script for checking endianness).
> Also, it was IIRC mentioned before that memcpy always "does the right thing"
> by copying (e.g. for 32-bit architectures) 1, then 2, then many chunks of 4,
> then 2, then 1 in worst case alignment circumstances -- is that true?
I haven't had any problems with memcpy() in that respect. Also, it's
usually a compiler built-in, so it should be reasonably fast.
Hope this helps,
llap,
Christoph
