#387 Consider using nasm instead of yasm in CMake port

[Maarten]

I created a few patches to improve yasm on CMake support, with the hope of finding out why CI is failing.
Since I cannot reproduce the error locally, I've not yet created a fix.

It looks like yasm is EOL.
Perhaps it makes sense to move to nasm?
See https://github.com/yasm/yasm/issues/295

[Thomas Orgis]

So did nasm survive its fork yasm? I'm not sure about the specifics. I only used barebones as personally. Do we need to change anything in the code or is it just adapting configure and cmake scripts? Actuallyt … I do wonder if we could get rid of yasm stuff in configure.ac, as it is only for AVX from times where the default assembler didn't support it, I presume.

[Maarten]

nasm is Intel-syntax only. So all AT&T syntax would have to be converted.
The GNU assembler supports this syntax with .intel_syntax noprefix.

It looks like nasm supports the latest intel instruction set extension (avx512/amx).

Perhaps it would be possible to assemble the sources with the Microsoft assembler and get rid of the nasm/yasm requirement for MSVC?

I spent yesterday writing a very rough converter for AT&T to Intel (see attachment).
Applying it to mpg123's assembly sources, I can build a amd64 mpg123 on Linux using the GNU assembler.
x86 is almost there, but has an issue with LOCAL_VAR.
I pushed these changes to https://github.com/madebr/mpg123/tree/assembly-intel-syntax

(I did not validate the resulting binary)

[Maarten]

I now can build libmpg123 for x86_64 on Linux using both nasm and gas.
Let me know what you think of the current approach.

I'm verifying the equivalence between intel syntax (gas and nasm) against the original AT&T sources by comparing the output of objdump -d <obj> of the objects, and so far everything seems to be looking good.

[Thomas Orgis]

That needs some thought … for clarification: Do you intend to only use the translated files for nasm/Windows or rather aim for replacing all old .S files with new intel-style ones?

Reading https://wiki.osdev.org/GAS#Intel_Syntax_Support … I guess forking translations only to be used with nasm seems safer, also not touching the other assembly sources

[Thomas Orgis]

The other approach for x86-64 and ARM would be trying if re-implementing the ASM with intrinsics does work well. Would they offer the same performance? I see weird subtle effects when re-arranging C code, a few percent performance are lost easily with innocently-looking changes.

[Maarten]

The intention is to replace all AT&T sources with Intel version. They are currently added with a -intel suffix (for easy comparison), but the originals should be 100% replaced by their Intel counterparts.

The wiki says Intel syntax is supported since binutils 2.10 (2000-11-07), so well old enough?

With C intrinsics, you depend on the compiler allocating the registers in a way that the hot loop does not spill them to the stack, so similar performance is not assured.

Looking at this table, by using Intel syntax, all assemblers are unlocked (in principle).

[Thomas Orgis]

I am referring to this paragraph from osdev wiki:

It is generally discouraged to use
the support for Intel Syntax because it can subtly and surprisingly different than the real Intel Syntax found in other assemblers. A different assembler should be considered if Intel Syntax is desired.

Has that changed? Do we need a checker that we keep gas' dialect of Intel syntax?

Regarding intrinsics: I'd suspect that they will be somewhat distant from optimal. Though the hope still remains that compilers at some point can create fast numerical code ... with some hints about allowed tradeoffs...

I also wonder how many CPU and object format features will keep cropping up to annoy me, having to update the asm files with random new sections, flags, and instructions (bti, nonexec stack).

That points towards having only one version per asm file. And if the okd x86 ones are translated, comparison of generated objects should be the standard, as you started out with, otherwise we'd need to dig out the actual CPUs concerned to make proper comparisons.

--
sent from mobile device, trustworthy or not