On 2 December 2015 at 19:50, Michael Zimmermann <[email protected]> wrote: >> But, I believe -- I could be wrong -- that for ARM/AARCH64 the assembly >> syntax has been uniquely determined anyway. (If this is not the case, I >> hope I'll be corrected.) > > Unfortunately not. From ArmPlatformPkg/PrePi/Arm/ to ./Library/ArmLib - > there are always both asm and S files. >
The .asm files are only there for ARM: the proprietary 32-bit toolchain RVCT has its own syntax that is different from what GNU binutils uses. Fortunately, for AARCH64, there is only one asm syntax to support. The proprietary 64-bit toolchain is clang-based, which uses a syntax that is compatible with binutils/gas for AArch64. -- Ard. > On Wed, Dec 2, 2015 at 7:34 PM, Laszlo Ersek <[email protected]> wrote: > >> On 12/02/15 18:37, Michael Zimmermann wrote: >> > Does NASM support ARM and AARCH64? because according to Wikipedia it >> > doesn't. >> >> It doesn't. >> >> But, I believe -- I could be wrong -- that for ARM/AARCH64 the assembly >> syntax has been uniquely determined anyway. (If this is not the case, I >> hope I'll be corrected.) >> >> Thanks >> Laszlo >> >> >> 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 <[email protected]> wrote: >> > >> >> >> >>> 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 >> > >> >> > _______________________________________________ > 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
