It was thus said that the Great Soni L. once stated:
On 07/08/15 07:21 PM, Sean Conner wrote:
It was thus said that the Great Soni L. once stated:
Any reason why string.(un)pack can't do bitfields?
Performance reasons?
But that aside, what would the spefication string look like to pull bits
out?
-spc (Also, maybe it didn't cross Roberto's mind to do so?)
Fn? Dn? e.g. D3D3D2 (or replace D with F) would be 8 bits composed of 3,
3, 2 bits, DX[n] would be a padding modifier?
Okay, because that brings up other questions---what about bitfields that
span byte boundaries? For instance, in the MIPS archicture, instructions
are all four bytes long, and most have the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP # Rs # Rt # Rd # Sa # Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
OP = operation code
Rs = source register (one of 32)
Rt = 2nd source register
Rd = destinaion register
Sa = shift amount
Function = more operation code(s)
But it's more complicated than that, because there are two other decodings,
depending upon the OP bits, so you're better off decoding the first six
bits, then decode the remaining 26 bits separately.
Second issue: signed values. On the MC6809, part of the indexing
addressing mode looks like:
+---+---+---+---+---+---+---+---+
| 0 | R | R | F | F | F | F | F |
+---+---+---+---+---+---+---+---+
A literal 0, followed by two bits designating the index register (0 to 3)
then the remaining five bits giving you an offset of -16 to 15 (it's
interpeted as a signed quantity).
Bit fields get real messy real quick.
-spc (Thank god we don't have to deal with middle endian systems anymore!)
