OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Dec 14, 2017 7:37 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: what are those constructs?
PostPosted: Wed Oct 18, 2017 11:50 am 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 293
Location: San Jose San Francisco Bay Area
I see them a lot in UEFI code:

normal C calling constructs:

<return type> <function name> (<param1 type> <param1>, <param2 type> <param2>,....<paramN type><paramN>)
{
<function body>
}

in UEFI code, I see a lot:
EFI_STATUS EFIAPI <function name> (IN OUT <param1 type><param1>)
{
<function body>
}

Here I see EFI_STATUS is a return type, but how about EFIAPI, IN and OUT keywords?
May be I have grab my C primer that is collecting dust in my shell to see anything is there.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


Top
 Profile  
 
 Post subject: Re: what are those constructs?
PostPosted: Wed Oct 18, 2017 1:07 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 217
Location: Ukraine, Bachmut
That's easy. IN, OUT, there might be also their combination are just a convenient way to hint you of a purpose of this parameter - are they input for a function, output or both. Microsoft has a lot heavier system for this. They even call it somehow, forgot it.
Above things defined just as empty macros. For example:
#define IN

As of EFIAPI, it is a calling convention (CC) specification marker. UEFI requires all defined by the specification functions to follow the convention defined by UEFI. If your compiler supports several CC, there should be one compatible with UEFI's. And then you might bind EFIAPI specifier to the compiler's keyword for that CC. Something like this:
#if defined(___cool_n_free_as_in_beer_and_vodka_compiler_blablabla)
#define EFIAPI ___declspec(CALLING_CONVENTION_COMPATIBLE_WITH_UEFI)
#elif defined(some_else_cool_n_free_compiler)
#define EFIAPI XXX
#endif

That said, mostly EFIAPI defined as an empty macro as well. :)

Speaking by my own experience. So far I am working with MIPS architecture, and since UEFI doesn't have this architecture included and thus, - doesn't have any CC specification for it, I chose it by myself. I chose O32 calling convention it's good and simple, everything needed. Since it's a default CC for GCC I use, I defined EFIAPI as a plain macro.

An excerpt from my own Uefi.h file, as an example:
Code:
/* ABI specification */
#define EFIAPI   /* for mips32 it's o32 */

#define NULL      ((PVOID)0)
#define IN
#define OUT
#define OPTIONAL
#define CONSTANT   const
#define CONST      const

_________________
future big goal: ANT - NT-like OS for mips, arm and x86 (and, possibly, ppc and itanium, hehehe).
current smaller goal: efify - UEFI for a couple of boards (mips and arm).


Top
 Profile  
 
 Post subject: Re: what are those constructs?
PostPosted: Wed Oct 18, 2017 7:14 pm 
Offline
Member
Member

Joined: Wed Nov 18, 2015 3:04 pm
Posts: 293
Location: San Jose San Francisco Bay Area
zaval wrote:
That's easy. IN, OUT, there might be also their combination are just a convenient way to hint you of a purpose of this parameter - are they input for a function, output or both. Microsoft has a lot heavier system for this. They even call it somehow, forgot it.
Above things defined just as empty macros. For example:
#define IN

As of EFIAPI, it is a calling convention (CC) specification marker. UEFI requires all defined by the specification functions to follow the convention defined by UEFI. If your compiler supports several CC, there should be one compatible with UEFI's. And then you might bind EFIAPI specifier to the compiler's keyword for that CC. Something like this:
#if defined(___cool_n_free_as_in_beer_and_vodka_compiler_blablabla)
#define EFIAPI ___declspec(CALLING_CONVENTION_COMPATIBLE_WITH_UEFI)
#elif defined(some_else_cool_n_free_compiler)
#define EFIAPI XXX
#endif

That said, mostly EFIAPI defined as an empty macro as well. :)

Speaking by my own experience. So far I am working with MIPS architecture, and since UEFI doesn't have this architecture included and thus, - doesn't have any CC specification for it, I chose it by myself. I chose O32 calling convention it's good and simple, everything needed. Since it's a default CC for GCC I use, I defined EFIAPI as a plain macro.

An excerpt from my own Uefi.h file, as an example:
Code:
/* ABI specification */
#define EFIAPI   /* for mips32 it's o32 */

#define NULL      ((PVOID)0)
#define IN
#define OUT
#define OPTIONAL
#define CONSTANT   const
#define CONST      const


thx, looks like these are something i have never bothered to deal with, will look into it.

_________________
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails


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

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 5 guests


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