how to chop up a sequence of bits into byte

[daniellam]

suppose we have six binary numbers like,
a) 0011
b) 011
c) 10
d) 01
e) 1010
f) 0111
and we want to combine them and chop up from the rest for every 8 bits, or a byte, just like this

a) to f) => 0011011100110100111 => 00110111 - 00110100 - 111xxxxx

then we also want to display each byte as an ascii character
and then we want to recover the sequence from the bytes, like

00110111 - 00110100 - 111xxxxx => all x's are thrown out => 00110111001101001

question:
a) what should i do to take all four bits from a), all three bits from b) and only the frist bit from c) to form a byte?
b) for the third byte '111xxxxx', what is a good suggestion for 'x' to be? and also want to let the compiler know that the five x's are just for completing a byte, but not adding a new binary number?

my own thought:
a) i think, first, we need to know how many bits in a), then shift a) to left by [8 - #of bits in a)],
second, find out how many bits in b),
->if less than [8 - #of bits in a)], we shift b) to left by [8 - #of bits in a) - #of bits in b)] then we add all the bit of b) to a)
and check for remaining bits available, in this case is 1 bit left, so we take the first bit of c), which is '1' to fill out the last bit in a), thus completing the first byte. Then do the same check and shift for the next bit in c) , and for d) and e).

b) since in some conditions, there could be at most 7 x's, or at least 1 x, to determine the number of x to be added, we will need to know how many bits are left when completing the LAST byte from the sequence of bit, in this case, the last three bits, '111' from f) will belong to the final byte, and we will have 8 - 3 =5 x's. In order for the compiler to know that the x's is not one of the original binary numbers from the sequence. first, have to tell the compiler how many binary numbers we have at the beginning, and after the last binary number, there will only be some junk to complete a byte. A good way to find out the total bits we have from all the binary numbers given, in this case, 4+3+2+2+4+4=19, 8 - (19 mod 8) will be the number of x's, so if we know the number of x's ahead, we could create a temporary binary number at the end of the original bit sequence, since we now know how many original binary numbers, and how many x's needed to complete the last byte, when the program read the last byte, we extract non-x bits, for example, if we let x be 1, then '111xxxxx' => '11111111', we read from the rightest bits, up the 5 positions, whatever remains are part of the last binary number, which is f) in this case, or exactly the last binary number itself, in some other cases.

NOW, i need help for all possible command directives needed, and if you have simpler way of solving the problem, please let me know.
Of course, if you have some codes that do the exact or similar thing, i would like you to share,
THANK YOU SO MUCH~~~

[sinsi]

You seem to have different lengths for a) to f), how will you know where one stops and another starts?

[MichaelW]

daniel,

Repeating the same post in more than one forum will not help you to get an answer, any more than all the RED text will help.

Depending on how you expect to specify these binary numbers (a-f) in your source file, your proposed solution may be much more complex than necessary. If, for example, you specified the binary numbers as a single dword:

bnum dd 0011011100110100111b

Extracting the bytes would just be a matter of addressing each of the bytes. Allowing for dwords being stored in memory with the bytes reversed, that is with the low-order byte at the lowest address and the high-order byte at the highest address, you could copy the low-order byte to AL with:

mov al, BYTE PTR bnum

Or the high-order byte (of the specified 3-byte value, not of the dword) to AL with:

mov al, BYTE PTR num+2

[daniellam]

I apology for repeated posting!!

but what if i have really long sequence of bits, like over a thousand bit, can't just keep specifying as a larger typedata, right?
maybe we could split 1000 into 500 and 500, then 500 to 250 and 250.....and so long........but this's too complex......assuming the sequence is really long....

[askm]

Please
Dan youre not the one who rich text enabled

this forum. What would one have you do...

apologize in another forum too ?

Whatever your quest is, seek till you find...

those ways to chop up sequential bits into bytes.

YOU keep this forum focused, no time for ADD

(Assembler Deficit Disorder).

[MichaelW]

daniel,

Will you be specifying the binary numbers in your source file or will they come from some other place? If you will be specifying the binary numbers in your source file, then you can use however many bytes you need, but your individual initializers cannot exceed 64 bits for a QWORD, 32 bits for a DWORD, etc. For example:

Code Select Expand


bnum dq 1101000101111111111011100011111111011111100000011111110011110101b
     dq 1101110111100011010111101111011110001011111111101101111001011101b
     dq 1110111111111000000000100000000000111001011111100000000001111111b
...


[FORTRANS]

but what if i have really long sequence of bits, like over a thousand bit, can't just keep specifying as a larger typedata, right?
maybe we could split 1000 into 500 and 500, then 500 to 250 and 250.....and so long........but this's too complex......assuming the sequence is really long....

Hi,

   As a concrete example:  Take the CGA graphics mode 6, there are 640 by
200 pixels in 16000 bytes.  You can address each one of the 16000 bytes by
placing its location in a base or index register and reading it.

Code Select Expand


        MOV     AX,0B800H  ; Point ES segment to CGA screen.
        MOV     ES,AX
        MOV     BX,0    ; Read first eight pixels on the screen into AX.
        MOV     AX,ES:[BX]
        MOV     CX,ES:[BX+80]  ; Read first eight pixels on the second line into CX.
        ADD      BX,1599 ; Read the last screen byte into DX
        MOV     DX,ES:[BX]


   If you are defining your data, and expecting to use it as bytes, it is probably
best to start out defining it as bytes until you get used to the little endian
storage of the X86 processors.

   From the first description of your problem, you may want to look at what others
have written describing converting a serial data stream to data in a register or
memory.

HTH,

Steve N.

[askm]

chop chop

According to this 'Assembly Language For
Intel-Based Computers' book,

"The BT, BTC, BTR, and BTS instructions can

be collectively called bit testing instructions.

This has implications for multithreaded programs..."

And also theres the shift and rotate instructions.

Clearly we need chop instructions.

Perhaps chopl, chopr... er macros ?