“It was also determined that most of the Assembly code has little value. “
I guessing he meant it is not worth porting since the code itself obviously has a lot of value for the architecture it was written for and they already have code for the target arch.
But other than that sentence, no surprises. Most of the assembly code is in the kernel or in low level libraries like gstreamer and ffmpeg.
So there’s dozens of multimedia apps for Linux, but none of them have assembly code because they all use some low level library that handles all the nasty performance issues.
I forgot to mention, the real nastiness of porting to another architecture usually isn’t the assembly code, it’s the differences in endianness and type sizes of the compilers.
Unless the original author of the code went out of his way to insure that the code could be ported to a compiler for an arch that has different type sizes and endianness, the code will be filled full of bugs when ported. This is especially true of C-code.
I’ve worked on a project where we were required to write C-code that worked regardless of the endianness and the type sizes so from first-hand experience I can say it’s a lot of extra effort. OTOH, I’d recommend everyone still do it because it actually makes your code a lot more robust. You’ll be amazed at how many little bugs get exposed when you port your code to a CPU with a different word size and endianness.