> 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. 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
