>
> I'll bet there are more as well. There are also architectures
> that arrange the bit order inside the bytes differently for what
> it is worth.
I know Intel NAMES them back-to-front. I started out in a simple world:
Memory locations numbered (as one might view them) left to right.
Bytes|characters in words numbered left to right, just as I write
Bits in characters|bytes numbered left to right, just as I write.
With a bit of effort I can almost cope with the screwy way Intel numbers bytes
in 16-bit words; I've avoided 32-bit ones so far.
However, the Intel way of numbering bits in words gives me hell; I've resorted
to redrawing diagrams and all sorts, and still been unsure that I had it right.
>
> These odd architectures may be rare, but they exist. There is no
> guarantee an int is 32 bits either. There are arch's where it is
> 48, and likely other oddballs too like 36 or 12 or something..
If someone wrote C for Univac it'd be 36. 64 is becoming common (I think-),
and I imagine that Cybers would use 96.
(MS|PC|DR)dos - 16.
The whole idea of naming a numeric datatype "int" was a pretty poor idea.
"long int" etc are little better. I prefer PL/1's fixed bin(31) - one defines
the sice of the fixed-point number (31 bits plus sign) and representation
(binary). It also allows decimal rather than binary, and float rather than
fixed.
If you ask for a fixed-point binary variable, you can be sure you have one if
the program compiles.
I C you can't be sure of anything; even a char might not be eight bits if the
underlying hardware doesn't support it. I don't know whether there IS any such
contemporary hardware, but it used to exist.
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
