Does NASM support ARM and AARCH64? because according to Wikipedia it
doesn't.
> 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.
Are you sure assembly never get's inlined? I'd expect optimizers to work on
assembly/bytecode level and at least GCC's O3 function enables -finline.
On Wed, Dec 2, 2015 at 6:32 PM, Andrew Fish <af...@apple.com> wrote:
>
> > On Dec 2, 2015, at 8:44 AM, Michael Zimmermann <sigmaepsilo...@gmail.com>
> 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
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
