Re: string.(un)pack

[Sean Conner <sean@...>]

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!)