0

Before I created the following question I've read a some similar questions on SO, but I didn't find the answer of my question.

Lets assume that I have the following bits stream 010001 01000 1010100 01100

010001 -> represents the instruction add arg1, arg2, arg3

arg1: 01000 -> starts with 0 so, the arg1 will represents the register number 1000 is little endian so the register number index is 1

arg2: 1010100 -> so it will be a memory argument 1-01-0100 01 is a two byte access,

arg3: 01100 -> third argument starts with 0 again, so it’s a register argument: 0-1100 this encodes register3.

As you can see either the instruction opcode or arguments are not aligned to byte boundary.

Eg. as you can see above - the opcode takes 6 bits, and the rest 2 bits from byte are the part of the first argument.

But another opcode can takes 3 or 5 etc bits from byte, so the opcode length is not fixed.

Does the same situation exists e.g on the x86?

I can deal with it by using masks or bits shifting but I wondering is there any usefull pattern which can help to do this better?

Seki
  • 11,135
  • 7
  • 46
  • 70
bielu000
  • 1,826
  • 3
  • 21
  • 45
  • write (or find) a bitstream class that allows you to read a specified number of bits so that you can separate bistream handling from the rest of your application logic – Alan Birtles Oct 18 '19 at 06:58
  • Is there any useful pattern which can help you do **what** better? – user253751 Oct 18 '19 at 08:48

1 Answers1

0

No, this isn't much like x86 instruction encoding. x86 uses quite a bit more complex encoding scheme, that's a serious pain to decode, especially if you want to do it quickly.

This looks a lot closer to, for one example, some of the 8-bit Motorola processors (6800, 6809, 6811, etc.) Having a fixed field for the op-code, and each operand really makes life pretty simple. You pretty much just generate bit masks to "peel off" each part of the instruction, feed them to the logic that deals with that part of the instruction, and off you go.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • I updated my question -> the opcode length is not fixed, e.g another opcode may consists of the following bits: 001, or the next one 10001 – bielu000 Oct 18 '19 at 07:23
  • @bielu000: If you want meaningful help, you need to give us enough information to help you. Moving from fixed length op-code to variable length op-code is a *huge* jump. But you still haven't told us what logic determines op-code length--looking at a stream of bits, how do I find the end of the op-code? Without that kind of information, you're pretty much asking us for magic. – Jerry Coffin Oct 18 '19 at 14:47