Hi,
On Sat, 7 Jul 2001, Brian S. Julin wrote:
> > 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).
>
> Hmm, so what happens when you try to read a two-byte chunk?
It will probably be translated into an appropriate chunk of code that
reads a 4-byte "dword" (DEC's terminology), and, dependant on bit #1,
either shifts right by 16 or zeroes out bytes 2 and 3 in the register. I
haven't tried it (and don't have the time for that ATM), but I guess it
should take some 6 to 8 instructions total. If compiled with -mcpu=ev5
(that's another guess; I don't know exactly when BWX was added) or better,
the matching single BWX instruction will be used.
In either case, dereferencing an _unaligned_ 16 bit pointer will be
trouble (invalid result or severe performance loss).
> Yes, very much, thank you. Say, one more question: are there still compilers
> about for < 64 bit machines which don't emulate 64-bit integers/64-bit math,
> or can I assume autoconf will always be able to find me an int64_t and I'll
> always be able to do all the >> + / ops I want to on it?
I rarely use anything but gcc on 32 bit machines, but, seeing that 'long
long' is a non-ANSI extension, I don't recommend relying on it (or
something equivalent) being present. If you have a test script for
checking that, I could run it with Sun's native cc next week (on 32 bit
SPARC).
llap,
Christoph
