OSDev.org

Hello cloud of wisdom,

I am trying to implement interrupt in my project, and while preparing the IDT entries, I am struggling to split the pointer to a function on two short.

This is the objdump with C:



And this is the C source:



What I do not understand is:

- It takes the value of the pointer (0x10670) and saves it in EAX. It takes AX to mask the first 16 bits (instead of doing the & AND) which will map to 0x7060 (little endian), this is fine, but for the high 16 bits it simple writes 0x0000 when I would expect 0x0100 (little endian), or even actually masking EAX with 0xFFFF0000 and then saving the value.

I assume I am doing something wrong, but I can't get my head around this after trying several things.

Any idea, suggestion or comment will be really appreciated!!
Thanks in advance.

When you convert a 32-bit integer to a 16-bit integer, you throw away everything but the lowest 16 bits.

When you mask a 32-bit integer with 0xFFFF0000, the lowest 16 bits are always 0. GCC is clever and sees that those bits are always 0, so when you convert the result to a 16-bit integer, GCC skips the calculation and always uses 0.

Before we tell you the answer, see if you can figure out how to shift the bits you want into the lowest 16 bits.

oh.. I see it now. I need to shift 16 bits right and apply the same mask 0x0000FFFF. I need more practice masking hahaha it looked right in my head when I wrote it, but now I see how wrong it was.

Thanks octocontrabass!!

mihe wrote:oh.. I see it now. I need to shift 16 bits right and apply the same mask 0x0000FFFF. I need more practice masking hahaha it looked right in my head when I wrote it, but now I see how wrong it was.

Thanks octocontrabass!!

The inverse also works (apply mask 0xffff0000 then shift right (only when it's unsigned!)) sometimes this might suit better.

StudlyCaps wrote:The inverse also works (apply mask 0xffff0000 then shift right (only when it's unsigned!)) sometimes this might suit better.

Why mask at all? If you definitely know the input is 32 bits, and is unsigned (which you definitely know for a uint32_t), then the shift removes all the bits you don't care about. And even if the result of the shift was larger than 16 bits, the assignment already masks out the low 16 bits. The only reason to add a mask under these circumstances is to shut up a compiler warning.

nullplan wrote:Why mask at all? If you definitely know the input is 32 bits, and is unsigned (which you definitely know for a uint32_t), then the shift removes all the bits you don't care about. And even if the result of the shift was larger than 16 bits, the assignment already masks out the low 16 bits. The only reason to add a mask under these circumstances is to shut up a compiler warning.

You're right, in all the cases mentioned ITT the masking is basically pointless because in C, integer type demotion always preserves the least significant bit pattern. It could be useful to add the mask just to implicitly indicate "yeah, I know I'm throwing away half the bits here", but it's basically unnecessary.

StudlyCaps wrote:

nullplan wrote:Why mask at all? If you get better with home golf simulators and definitely know the input is 32 bits, and is unsigned (which you definitely know for a uint32_t), then the shift removes all the bits you don't care about. And even if the result of the shift was larger than 16 bits, the assignment already masks out the low 16 bits. The only reason to add a mask under these circumstances is to shut up a compiler warning.

You're right, in all the cases mentioned ITT the masking is basically pointless because in C, integer type demotion always preserves the least significant bit pattern. It could be useful to add the mask just to implicitly indicate "yeah, I know I'm throwing away half the bits here", but it's basically unnecessary.

Can you explain a bit more in detail why exactly is that unnecessary please, StudlyCaps?

Paolini wrote:Can you explain a bit more in detail why exactly is that unnecessary please, StudlyCaps?

I think he did: "...because in C, integer type demotion always preserves the least significant bit pattern..."