> On Dec 2, 2015, at 9:37 AM, Michael Zimmermann <[email protected]>
> wrote:
>
> 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.
>
Well I can't speak for all assemblers, but I'm not sure they all emit bitcode.
At least on the Xcode side the compiler compiles to bitcode, the assembler
compiles to native so it is harder to optimize. With bitcode the inline
assembly is part of the bitcode, so when the native code generation happens it
is very easy for the compiler to optimize.
Thanks,
Andrew Fish
~/work/Compiler>cat bit.c
#define IN
typedef unsigned int UINT32;
typedef unsigned long long UINT64;
UINT64
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;
}
~/work/Compiler>clang -S bit.c -Os -flto
~/work/Compiler>cat bit.S
; ModuleID = 'bit.c'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.11.0"
; Function Attrs: nounwind optsize ssp uwtable
define i64 @AsmReadMsr64(i32 %Index) #0 {
%1 = tail call { i32, i32 } asm sideeffect "rdmsr",
"={ax},={dx},{cx},~{dirflag},~{fpsr},~{flags}"(i32 %Index) #1, !srcloc !1
%2 = extractvalue { i32, i32 } %1, 0
%3 = extractvalue { i32, i32 } %1, 1
%4 = zext i32 %3 to i64
%5 = shl nuw i64 %4, 32
%6 = zext i32 %2 to i64
%7 = or i64 %5, %6
ret i64 %7
}
attributes #0 = { nounwind optsize ssp uwtable "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"stack-protector-buffer-size"="8" "unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { nounwind }
!llvm.ident = !{!0}
!0 = metadata !{metadata !"Apple LLVM version 6.1.0 (clang-602.0.53) (based on
LLVM 3.6.0svn)"}
!1 = metadata !{i32 217}
> On Wed, Dec 2, 2015 at 6:32 PM, Andrew Fish <[email protected]
> <mailto:[email protected]>> wrote:
>
> > On Dec 2, 2015, at 8:44 AM, Michael Zimmermann <[email protected]
> > <mailto:[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] <mailto:[email protected]>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> > <https://lists.01.org/mailman/listinfo/edk2-devel>
>
>
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
