Thomas,
Work is underway right now on removing Shell dependencies from StdLib. Target
= 3Q2014.
Once that is done, the runtime environment will be modularized so that the
overheads associated with exit(), abort(), signal(), onexit(), etc. do not have
to be borne unless one wants.
If your tests show that the overhead is acceptable, the only remaining portions
of StdLib that depend on the Shell are file-system and console I/O. That is
what I am working on removing right now.
As far as the intrinsic libraries go, the ultimate solution would be to build
special versions of the GCC and VC++ CRTs that don’t include the OS, and other
unneeded, dependencies. That way, I wouldn’t get stuck with discovering the
names and parameters of the CRT functions every time they change, and having to
figure out what they are supposed to do.
Daryl McDaniel
"It is the mark of an educated mind to be able to entertain a thought without
accepting it."
– Aristotle
From: Thomas Rognon [mailto:tcrog...@gmail.com]
Sent: Wednesday, August 20, 2014 3:58 PM
To: edk2-devel
Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for
64-bit right shift
I agree with Tim. I end up porting a lot of libraries that I want to use for
drivers that will not be run from the shell. Even partial support would make
this a lot easier. This may be off topic, but a lot of StdLib functions, not
just the intrinsics, would be useful to have for drivers as well. Has anyone
considered making as much of that as independent from the shell as possible? It
would make UEFI a much more portable-code-friendly platform.
On Wed, Aug 20, 2014 at 5:38 PM, Tim Lewis
<tim.le...@insyde.com<mailto:tim.le...@insyde.com>> wrote:
Mike –
However, as compilers do require intrinsic functions in order to support basic
C/C++ operators, and as the ArmPkg has already implemented this sort of
function for support of ARM tool chains, and as it regularly causes compile
failures for reasons obscure even to engineers well versed in the art, I think
it is time to revisit that decision. Raise your hand if you have done a search
on u
Even a partial solution will be better than no solutions because the net result
is fewer hard-to-understand linker errors than before. If you miss one
function, the net result is no worse than today.
Tim
From: Kinney, Michael D
[mailto:michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>]
Sent: Wednesday, August 20, 2014 12:30 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for
64-bit right shift
Thomas,
A design decision was made early in the EDK II project to not depend on any
compiler intrinsic functions. The reasons include:
1) Linking against OS specific C libs has risks because it can potentially
introduce OS specific sys calls.
2) Linking against OS specific C libs can potentially produce larger
firmware images.
3) Different compilers and each compiler release can choose to
add/remove/modify intrinsic functions the compiler generates to meet that
specific compiler’s requirements.
4) Not all intrinsic functions generated by all compilers are fully
documented.
When the AppPkg and support for C lib was added, there was a new requirement to
support building exiting C application sources “as is”. This meant that some
intrinsic functions could not be avoided, so the minimum set of intrinsic
functions were added to the C lib support and the C lib maintainer has to
handle the issues listed above. As a result, the compiler compatibility of the
AppPkg may not be the same as the rest of the EDK II packages.
I may be a good idea to move the just the intrinsic functions into their own
lib instances in the AppPkg, so they are available for linking against firmware
modules to work around porting issues until the intrinsic functions are
replaced with MdePkg lib calls.
Best regards,
Mike
From: Thomas Rognon [mailto:tcrog...@gmail.com]
Sent: Wednesday, August 20, 2014 11:34 AM
To: edk2-devel
Subject: Re: [edk2] [StdLib] Patch for review: Add VC++ helper function for
64-bit right shift
UefiCpuPkg/Library/CompilerIntrinsicsLib would be awesome. I feel like I'm
always battling the compiler with math and memory intrinsics. I hope this
happens.
On Wed, Aug 20, 2014 at 1:06 PM, Tim Lewis
<tim.le...@insyde.com<mailto:tim.le...@insyde.com>> wrote:
Daryl –
Do we want to create the equivalent of the ArmPkg/Library/CompilerIntrinsicsLib
for x86 so that these sorts of math-helpers can be used across the whole build?
Perhaps UefiCpuPkg/Library/CompilerIntrinsicsLib?
Tim
From: Mcdaniel, Daryl
[mailto:daryl.mcdan...@intel.com<mailto:daryl.mcdan...@intel.com>]
Sent: Wednesday, August 20, 2014 10:56 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] [StdLib] Patch for review: Add VC++ helper function for 64-bit
right shift
Jaben, Erik, or Lee (or anyone else ☺),
Please review the attached patch. llshr.c is a new file, LibC.inf was modified.
StdLib: Add a runtime helper function for VC++ 64-bit right shift on Ia32
target architectures.
Add new file StdLib/LibC/CRT/Ia32/llshr.c
Add references to the new file to StdLib/LibC/LibC.inf
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
<daryl.mcdan...@intel.com<mailto:daryl.mcdan...@intel.com>>
Reviewed-by:
Daryl McDaniel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
