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.
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
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, als not touching the other assembly sources
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.
I finally added this for UFID. Other extra text fields should follow for mpg123 1.34.0. For your test file, mpg123-id3dump output now includes: UFID description(http://musicbrainz.org) 61363061343237322D383734642D346131372D613532372D333663646364313861643136 This is added to mpg123_id3v2.extra as discussed. I think we don't need a switch for this. Can you verify that this makes sense for your application, and that the rendering is correct? Edit: Of course I'm talking about current svn trunk wich is...
I finally added this for UFID. Other extra text fields should follow for mpg123 1.34.0. For your test file, mpg123-id3dump output now includes: UFID description(http://musicbrainz.org) 61363061343237322D383734642D346131372D613532372D333663646364313861643136 This is added to mpg123_id3v2.extra as discussed. I think we don't need a switch for this. Can you verify that this makes sense for your application, and that the rendering is correct?
Add NULL check in streamdump.c
1.33.6 is out. Thanks.