Choosing the simplest platform version of a source when porting to another platform

Question

The question will sound weird as I'm not very experienced in C, C++ and ASM.

Let's say I have a hard time finding a C# managed, safe-code-only solution to solve a problem. Then I find that in 1998, some codes for (e.g.) a codec have been written in C for PPC, x86, arm, etc. This code can have 20000+ lines, and I need to port it.

Then I try one platform, and notice a lot of API call, CUDA stuff, inline assembler in most of the code. Etc.

Is there a preference, concerning portability, between PPC, PS2, x86, arm, sparc, etc, when porting to another platform that helps reducing the number of platform-specific code occurrence? I know that all these builds exist especially because there are specific features on each processors, but I wonder if some processors have less antennas, third eye, and four legs, and are less simpler (or "limited") than others.

I spent the last week porting codes, and had the intuition that focusing on certain aspects helps finding more cross-platform code. I may be wrong, and I - know - that it highly depends on skill. But that doesn't change anything to the fact that, e.g., a 20000 lines Java code may be easier to port to .Net for Windows Phone than a x86 asm code.

More specifically, my question is about a good approach when porting Orange to Peach, and avoiding going through several platform specific implementations.

Answer 1

If I understand correctly, what you seem to be describing is that you have a highly-optimized C implementation of some codec that you need to bring to a platform-agnostic managed environment like .NET.

There are some problems with this.

A codec that has been optimized for several CPU architectures includes a lot of platform-specific code, because that's the only realistic way to achieve a level of performance that allows relatively real-time operation. This is why C and assembler were chosen over a managed language. (Setting aside the fact that it apparently predates most modern managed platforms - modern codecs like x264 and Vorbis are still written in C for this reason.) When performing complex transformations on large sets of data in a real-time setting, careful optimizations are made to account not merely for the CPU's features, but for the CPU's behaviors. The codec makes certain assumptions about the CPU's caches and timings to make the most of every single operation.

These kinds of optimizations are not possible in a managed environment. It is neither worth your time nor effort to port these kinds of things to a managed language.

Rather than porting this complex (and likely fragile!) code, you should instead use your chosen platform's ability to interact with unmanaged code. In .NET, you would probably want to use P/invoke to access the codec, and simply ship a pre-built copy of the codec for every platform you will deploy on.