OSDev.org

Hi.

I would like to be able to easily find out what exactly is hidden behind the current value of the registers.
For example, just copy the current EFLAGS from qemu (using info registers) and immediately decrypt it, or do the same with CRx registers.
Now I have to translate the value from 16 to 2 number system and manually examine the bits by checking the documentation.
Maybe there are some convenient online tools or something?

Pretty trivial to write such tools for yourself, I would have thought.

iansjack wrote:Pretty trivial to write such tools for yourself, I would have thought.

I was thinking of writing this for myself.
But suddenly someone did it before me, in this case it is more convenient to use something ready-made.

mrjbom wrote:Now I have to translate the value from 16 to 2 number system and manually examine the bits by checking the documentation.

Well, if you are doing that, you are already doing something wrong (unless I misunderstood you). You see, each hex digit is a shorthand for four bits. This makes it both easy to identify what bits a given hex digit stands for (as it is always the same thing), and to locate the bit in the documentation.

For example, I'm defining the GDT as just an array of 64-bit numbers. So I have the assignment Cross-reference that with the documentation for a 64-bit GDT entry, and you see, for example, that the first "a" in the number means that the G bit and the L bit are set: "a" is "1010" in binary, and this one is two digits in, so eight bits in. And luckily in the GDT entry, most important things line up with boundaries divisible by four.

Doesn't always work that way, but then you just get as close as possible with hex digits. And so there is never really a reason to translate the number back to binary. One thing I particularly never understood is the insistence of some members of this community to use binary for full thirty-two bit numbers (or even sixty-four bit numbers). How do you even see anything in that long mess?

nullplan wrote:

mrjbom wrote:Now I have to translate the value from 16 to 2 number system and manually examine the bits by checking the documentation.

Well, if you are doing that, you are already doing something wrong (unless I misunderstood you). You see, each hex digit is a shorthand for four bits. This makes it both easy to identify what bits a given hex digit stands for (as it is always the same thing), and to locate the bit in the documentation.

Wow, I've never noticed this, although even with this it's not particularly convenient to manually check the documentation every time.

nullplan wrote:How do you even see anything in that long mess?

It's hard to see something there, so it was cool for some utility to see it for me

mrjbom wrote:Wow, I've never noticed this, although even with this it's not particularly convenient to manually check the documentation every time.

Unfortunately, I've found that symbolic constants don't help a lot, because the concepts are often too arcane, so you need to read the code with the documentation in hand anyway. And particularly in places where you only need the constants once, like in the GDT and IDT code (which I initialize once and then never touch again), I just use magic numbers and then put the whole issue to bed.