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 <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
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
