OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Sep 16, 2019 10:32 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Fri Jan 18, 2019 3:19 pm 
Offline
Member
Member

Joined: Sun Oct 21, 2018 1:37 pm
Posts: 38
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:

Image

And this is the C source:

Image

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.


Top
 Profile  
 
 Post subject: Re: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Fri Jan 18, 2019 3:32 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1636
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. ;)


Top
 Profile  
 
 Post subject: Re: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Fri Jan 18, 2019 4:49 pm 
Offline
Member
Member

Joined: Sun Oct 21, 2018 1:37 pm
Posts: 38
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!!


Top
 Profile  
 
 Post subject: Re: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Sun Jan 20, 2019 7:01 pm 
Offline
Member
Member

Joined: Mon Jul 25, 2016 6:54 pm
Posts: 181
Location: Adelaide, Australia
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.


Top
 Profile  
 
 Post subject: Re: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Sun Jan 20, 2019 11:23 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 239
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.


Top
 Profile  
 
 Post subject: Re: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Mon Jan 21, 2019 12:15 am 
Offline
Member
Member

Joined: Mon Jul 25, 2016 6:54 pm
Posts: 181
Location: Adelaide, Australia
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.


Top
 Profile  
 
 Post subject: Re: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Fri Feb 01, 2019 7:24 am 
Offline

Joined: Thu Jan 31, 2019 4:33 am
Posts: 1
Can you explain a bit more in detail why exactly is that unnecessary please, StudlyCaps?


Top
 Profile  
 
 Post subject: Re: Masking an 32bits pointer to two 16 shorts issue
PostPosted: Fri Feb 01, 2019 7:59 am 
Offline

Joined: Mon Nov 26, 2018 9:14 am
Posts: 6
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..."


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group