When there is a mention of software / firmware that has been ported to a certain architecture from another, I still struggle with the concept exactly.
If software has been ported to the ARM architecture for example, if this is C/C++ code, my understanding is that the source code doesn't need to change and we just use the ARM specific compiler to compile the code into instructions understood by the ARM chip?
If the source code needs to change depending on the architecture (whether it's ARM, PowerPC, X86 etc.) could you give me an example of why?
I've been reading about U-Boot and it states that it started out as a bootloader for embedded PowerPC chips and since then it got ported to ARM and other architectures. Again, would being ported mean that it simply got compiled with a different compiler? I'm almost certain that it is not as simple as that, so please explain what would need to change in the source code etc. to suit a particular architecture.
Since you asked for a few examples here are two relatively simple non-portable examples in C, just to start off.
(Do note that these are examples of non-portable code. Porting activities may also include tasks not related to existing code, like writing an interface or a new hardware abstraction layer for a custom target/processor)
sizeof(uint32_t)
Easy to expect this evaluates to 4, but, on architectures like TI C2000, this evaluates to 2. An algorithm assuming 4 (which of course is buggy in the first place) will compile fine for C2000 and may run as well, but, is highly doubtful if will produce the expected results
Typecasts
typedef struct _M {
uint32_t a;
uint32_t b;
} M;
uint8_t *p = (uint8_t *)malloc(100);
M *m = (M *)p;
printf("%d", m->b); //may cause hard fault at m->b on Cortex-M0
The last line will always work on a Cortex-M4, but, may cause a hard-fault on a Cortex-M0 depending on p's alignment to a 32-bit boundary. See this