Yes
From: Mcdaniel, Daryl [mailto:[email protected]]
Sent: Monday, May 13, 2013 2:35 PM
To: [email protected]
Cc: Tim Lewis
Subject: RE: [edk2] x86 compiler intrinsics
Tim,
If the compiler "instinsic" libraries (both gcc and msvc) from StdLib were made
available separately and for general use (though still as part of EDK II),
would this satisfy your needs? This would get you memcpy/memmove as well as
the intrinsics needed to use the C math operators, +-*/%^
Daryl McDaniel
"In the pun, two strings of thought are tangled into one acoustic knot."
-- Arthur Koestler
From: Carsey, Jaben [mailto:[email protected]]
Sent: Monday, April 01, 2013 1:43 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] x86 compiler intrinsics
There is one created for porting EDK shell extensions into UEFI Shell
applications. Sounds like we need something like that for non-shell code.
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Porting_an_EDK_Shell_Extension
From: Andrew Fish [mailto:[email protected]]
Sent: Monday, April 01, 2013 11:49 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] x86 compiler intrinsics
On Apr 1, 2013, at 11:03 AM, Tim Lewis
<[email protected]<mailto:[email protected]>> wrote:
Andrew -
You are a UEFI expert with tons of background knowledge. Newer engineers see an
error like this and have no reasonable way to proceed. Try to dig up a FAQ on
this?
This sounds like an issue in general. It would be nice to have an FAQ or
porting guide some place.
The EDK2 environment should support normal C operations for all data types
which are in the ABI. I can understand not supporting float intrinsics (floats
aren't actually a part of the ABI, even if they can be used in a module) But
normal struct assignments, or UINT64 math?
The Math libs are probably a higher bar than a memcpy/memset. For ARM math libs
were required as one of the processors we targeted did not even have a divide
instruction. The biggest math lib issue for IA32.
Now x86 appears handicapped in comparison to ARM on EDK2. Why allow this to
persist?
Well there are really two issues: memcpy/memset vs. math. The math is only an
issue for IA32, while the memcpy/memset is more generic.
I'm not opposed to some one adding these kind of intrinsics to the
IA32/X64/IPF world, but these are the issues that I see:
1) It makes different version of the edk2 not compatible. The new code would
not be compatible with an older code base.
2) Some one has to add and maintain all these function. The math functions
being more complicated than the memcpy.
3) It is a possible extra per compiler porting work, but I have to say it turns
out that the intrinsics are more stable than we first thought since if the
compiler changes them it breaks standard libraries.
As you point out it might make it easier to port EDK code if we added the
memcpy, but there are still going to be porting issues. For example the scheme
for GIUD globals is very different between the EDK/edk2, so I think we need
some kind of FAQ to help folks out regardless of this memcpy issues.
Thanks,
Andrew
Tim
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
