> On Dec 2, 2015, at 8:44 AM, Michael Zimmermann <[email protected]>
> wrote:
>
> Hi,
>
> sorry if this is documented somewhere but I've always wondered what this
> whole assembler file situation in EDKII is about.
> What I mean is that there are two versions of every assembler file - for VS
> and GCC compilers I guess.
>
> What I've noticed though is that most of these files are almost identical
> except for minor differences like different export macros and comment
> characters.
>
> I think (I hope I'm wrong) that there even are some projects where one
> version of these files is outdated/not maintained.
>
> If I'm right and the differences really are that small, couldn't we just
> write some kind of converter so we can remove all this duplicate code?
>
I think the longer term direction is to move to nasm. There are still some
issues of nasm working with Xcode as the DWARF info does not get placed into
the Mach-O files.
The MdePkg Libraries are designed so that you don't need to write assembler. On
an ARM based system you may also need some help from the ArmPkg. So the general
answer don't write assembler. You can usually use the BaseLib to do what you
need to do.
On the x86 side there are a few exceptions:
1) Reset - You start in real mode with no stack
2) Interrupts - You need to save state.
3) Mode Switches - PEI is 32-bit (No place to store the page tables) and DXE is
64-bit
4) SMM - More strange mode switching
5) Optimization - Usually not needed (MdePkg has optimized CopyMem etc.)
Now I would say an issue I've seen is that the Silicon folks like to "reinvent
the wheel".
>find . -iname '*.S'
...
./Vlv2TbltDevicePkg/FspSupport/Library/SecFspPlatformSecLibVlv2/Ia32/Stack.S
./Vlv2TbltDevicePkg/Library/CpuIA32Lib/IA32/CpuIA32.S
./Vlv2TbltDevicePkg/Library/CpuIA32Lib/X64/Cpu.S
If you look at these files you will see that MdePkg has SwitchStack functions,
and the CpuIA32Lib is the old EDK names for functions that exist in the MdePkg
BaseLib. So this is an example of unneeded assembly code in the tree.
#------------------------------------------------------------------------------
# UINT64
# EfiReadMsr (
# IN UINT32 Index, // rcx
# )
#------------------------------------------------------------------------------
ASM_PFX(EfiReadMsr):
rdmsr
shl $0x20,%rdx
or %rdx,%rax
retq
Looks a lot like:
UINT64
EFIAPI
AsmReadMsr64 (
IN UINT32 Index
)
{
UINT32 LowData;
UINT32 HighData;
__asm__ __volatile__ (
"rdmsr"
: "=a" (LowData), // %0
"=d" (HighData) // %1
: "c" (Index) // %2
);
return (((UINT64)HighData) << 32) | LowData;
}
Not sure why the Vlv2TbltDevicePkg needed to add that assembly code? I would
also point out that the inline assembly will optimize better as the compiler
will always call the .S function, but the optimizer can inline the C function
if needed.
Thanks,
Andrew Fish
> Michael
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
