int always 32 bits on all platforms?

[Nick Sabalausky]

"AJ" <aj at nospam.net> wrote in message news:hbor97$155c$1 at digitalmars.com...
>
> "Nick Sabalausky" <a at a.a> wrote in message 
> news:hbonj3$u34$1 at digitalmars.com...
>> "AJ" <aj at nospam.net> wrote in message 
>> news:hboa9p$5md$1 at digitalmars.com...
>>>
>>> How do you make ABC below work on a platform that requires 32-bit 
>>> integers to be aligned on 32-bit boundaries while keeping the layount 
>>> and size of ABC the same as on a platform that has no such alignment 
>>> requirement?
>>>
>>> struct ABC
>>> {
>>>    byte a;
>>>    int b; // may be improperly aligned on some platforms
>>>    int64 c; // same issue
>>> };
>>>
>>>
>>
>> It can be done by using bitmasks and bit shifting on every access.
>>
>
> I had a feeling I was delving into "dangerous territory" (read, way too 
> low level for me, but I wonder what the possibilities are). I have a 
> feeling that I may be wanting hardware standardization because it can't be 
> "solved" at the language level (?).
>
> I don't understand how using bitmasks and bit shifting on every access 
> would work

Normally, the compiler would turn this:

myabc1.b = myabc2.b + 1;

Into something like this:

- move value at memory address xxxxx (myabc2.b) into cpu register
- add 1
- move value in cpu register into memory address xxxxx (myabc1.b)

If the compiler knows that myabc1.b and myabc2.b are not aligned in a way 
that the cpu can directly access, then what it would turn it into is 
something like:

- move the values at the two memory addresses that myabc2.b straddles into 
cpu registers
- use bit manipulation tricks to throw away myabc2.a and myabc2.c and 
compine the two parts of myabc2.b
- add 1
- use bit manipulation tricks to split the value in the cpu register back 
into two parts, and mix in myabc1.a and myabc1.c
- move the restulting values into the memory addresses that myabc1.b 
straddles

> the plausibility of it

It should always possible. Although references to the struct's members would 
probably be very tricky and require a lot of extra fancy work.

> and the cost (in execution time) of doing so.

Depends completely on the cpu, of course. In general though, it's quite a 
bit slower (a single fetch or store turns into at least two fetches/stores 
plus some bitmasking and shifting, maybe uses up extra registers, and would 
make less of the code fit in cache). But that's the price you pay for using 
packed structs like that on such a CPU. Or you could just use align(4) to 
guarantee 32-bit alignment on all fields for all cpus.