Also keep in mind that the bit order of bitpacked records/arrays is different for big and little endian systems so if you want to be portable, only use the record/array types and not the underlying values directly.
AFAIK endianness determines the order of bytes, not bits, so using such a record is safe.
So I'm an idiot. Thanks for the replies…In general this is true, but bitpacked records/arrays also use a different bit order on big/little endian systems. The reason is that otherwise accessing bitpacked data changes the bit number depending on the size of the access (1/2/4/8 byte).Also keep in mind that the bit order of bitpacked records/arrays is different for big and little endian systems so if you want to be portable, only use the record/array types and not the underlying values directly.
AFAIK endianness determines the order of bytes, not bits, so using such a record is safe.
(*
Subsetrefs are used for (bit)packed arrays and (bit)packed records stored
in memory. They are like a regular reference, but contain an extra bit
offset (either constant -startbit- or variable -bitindexreg-, always OS_INT)
and a bit length (always constant).
Bit packed values are stored differently in memory depending on whether we
are on a big or a little endian system (compatible with at least GPC). The
size of the basic working unit is always the smallest power-of-2 byte size
which can contain the bit value (so 1..8 bits -> 1 byte, 9..16 bits -> 2
bytes, 17..32 bits -> 4 bytes etc).
On a big endian, 5-bit: values are stored like this:
11111222 22333334 44445555 56666677 77788888
The leftmost bit of each 5-bit value corresponds to the most significant
bit.
On little endian, it goes like this:
22211111 43333322 55554444 77666665 88888777
In this case, per byte the left-most bit is more significant than those on
the right, but the bits in the next byte are all more significant than
those in the previous byte (e.g., the 222 in the first byte are the low
three bits of that value, while the 22 in the second byte are the upper
two bits.
Big endian, 9 bit values:
11111111 12222222 22333333 33344444 ...
Little endian, 9 bit values:
11111111 22222221 33333322 44444333 ...
This is memory representation and the 16 bit values are byteswapped.
Similarly as in the previous case, the 2222222 string contains the lower
bits of value 2 and the 22 string contains the upper bits. Once loaded into
registers (two 16 bit registers in the current implementation, although a
single 32 bit register would be possible too, in particular if 32 bit
alignment can be guaranteed), this becomes:
22222221 11111111 44444333 33333322 ...
(l)ow u l l u l u
The startbit/bitindex in a subsetreference always refers to
a) on big endian: the most significant bit of the value
(bits counted from left to right, both memory an registers)
b) on little endian: the least significant bit when the value
is loaded in a register (bit counted from right to left)
Although a) results in more complex code for big endian systems, it's
needed for compatibility both with GPC and with e.g. bitpacked arrays in
Apple's universal interfaces which depend on these layout differences).
Note: when changing the loadsize calculated in get_subsetref_load_info,
make sure the appropriate alignment is guaranteed, at least in case of
{$defined cpurequiresproperalignment}.
*)
Until you add the ninth boolean to the record.
In general this is true, but bitpacked records/arrays also use a different bit order on big/little endian systems.
On little endian, the first bit of the bitpacked record is at 1 shl 0.
On big endian, the first bit of the bitpacked record is at 1 shl 7.
The downside of having it the same everywhere is that the bit numbering changes depending on the access size. You then always have to access everything byte by byte on either big or little endian (depending on which bit order you pick) while with the current approach (which is defined by all ABIs I know of) allows operations to be performed using a single 16/32/64 bit access when applicable.On little endian, the first bit of the bitpacked record is at 1 shl 0.
On big endian, the first bit of the bitpacked record is at 1 shl 7.
Yes. Another step back.
On UCSD-machines it was always the same.
No matter if you worked on an Apple II or a PC.
I am talking about 1980.
Winni
[
The downside of having it the same everywhere is that the bit numbering changes depending on the access size. You then always have to access everything byte by byte on either big or little endian (depending on which bit order you pick) while with the current approach (which is defined by all ABIs I know of) allows operations to be performed using a single 16/32/64 bit access when applicable.
On little endian, the first bit of the bitpacked record is at 1 shl 0.
On big endian, the first bit of the bitpacked record is at 1 shl 7.
From what you write, it appears that if I send someone a binary file containing a gameplay recording (a recording made on my computer), to someone who has a different endianness, the program will not be able to correctly read the data from this file. I understand well?
Is there such a need if the software is to run exclusively on Windows?
Theoretically, only me will use this program, but I would prefer it not to crash in the future when I change my computer to a newer/different one.
Well, since it is only you, you could always recompile it. :)
I don't believe that any Windows editions -- not even the ones for MIPS and DEC Alpha -- were ever Big Endian.
It can be further extended as you like.See my last answers... not necessary. Comes as standard from 3.2.0.
Regards,
It can be further extended as you like.See my last answers... not necessary. Comes as standard.
Regards,
I don't believe that any Windows editions -- not even the ones for MIPS and DEC Alpha -- were ever Big Endian.
Hi!
DEC Alpha was Big Endian. Nice machine.
I don't believe that any Windows editions -- not even the ones for MIPS and DEC Alpha -- were ever Big Endian.
Hi!
DEC Alpha was Big Endian. Nice machine.
Winni
No, DEC Alpha could run as both big and little endian and Windows always used little endian on processors that support both (MIPS, DEC Alpha, PowerPC, ARM, Aarch64).