Porting an existing codebase to a different chipset

Question

I heard that Microsoft ported Windows on ARM chipsets.

I just wondered that what does it mean to port a program to a different chipset. Being a Java programmer I do not know much about the low-level details.

Naively I suppose that Windows is written in a mixture of C, C++ and C#. I'm pretty sure that ARM already had its C and C++ compilers so these codes should have been only recompiled using these compilers. C# needs the .NET interpreter that might be also written in lower level languages and theoretically could be recompiled with the ARM specific C or C++ compiler.

I know of course that the procedure is not so straightforward, so I'd like to learn about the theoretical limitations, possible problems and so on that could make such a procedure difficult.

Note: the question is not specific to the example that I mentioned

Answer 1

Computer programs tends to be quite different in nature. You can have a trivial "hello world!" for example, then you can also have an full-fledged OS.

An OS with classical definitions (from Tanenbaum) of "The Operating System as an Extended Machine" and "The Operating System as a Resource Manager" needs to provide many things.

When OS needs to act as a Resource Manager it is just running on bare bones of the underlying machine controlling its features like booting, interrupts, I/O, security modes, etc. While we can't look into Windows' source code to see what are the differences in these aspects we can look at an open source competitor of it which already runs on both x86 and ARM architectures - Linux!

On Linux support for different architectures lays in arch directory. For example we have x86 and ARM directories among many others there. I believe even checking the directory names there gives you a hint on the required effort (boot, power, memory management, etc.)

There are quite differences between ARM and x86 worlds. In x86 pretty much everything is standardized (ever heard about IBM PC compatible?) with many vendors building clones of an architecture. On the contrary in ARM ecosystem, ARM company itself just being an IP provider every vendor has slight to great differences between each other (just check the sub directory names in arch folder starting with mach - that's for machine, or plat - that's for platform). With ARM you had nothing like a BIOS just before recent developments with UEFI which is still not vastly implemented (I don't say BIOS is a good or bad thing, just an example).

For the OS's "extended machine" role, which makes Windows what it is, porting should be relatively easier. This is mostly about features like calling an hard disk partition "c:" - having of file permissions like read-only or hidden and keeping the core APIs like Win32 API mostly functional. Yet again this is not straight forward.

I'm expecting MS to strictly define on what kind of ARM machine Windows can run on with what kind of peripherals compared to very open world of Linux to secure the quality and speed to market.

These are the two big tracks of problems I can imagine, however then with every turn there can be small issues like; ARM is a 32 bit RISC architecture, char is unsigned, even recent high end ARM cores doesn't have integer division support (performance?), all those small things Windows code thought for granted might bite them back...

Answer 2

The problems differ, but generally they fall into these areas:

1. Where non-standard features are used. For example, declaring variables after executable code in a block is not valid in ANSI C, but is in C99 and C++. But Microsoft compilers do not support C99. Related to this is anywhere that is not covered in the standard, for example process creation CreateProcess v. fork/exec, signal handling, etc.

2. Programmer makes incorrect assumptions. For example, assuming that a long is 32 bits. These can be real pigs to find and fix.

3. Compiler does not conform to the standard. Less common these days. More common is the lack of library implementations on some platforms. Of course the standards are not perfect, there can sometimes be different interpretations of the same standard.

4. Genuine architectural differences: For example, big endian / little endian issues, filename formats, and so on.

Answer 3

Although the vast majority of the code on an operating system is written in C, there is still a sizable portion that is written in assembler. This will need to be ported to the new platform. Some of this is just done is assembly because it is more efficient (things like memcpy) but some assembly is written because there is no equivalent C instruction (like making a system call or for correct handling of spinlocks). All this needs to be ported.

An operating system also directly accesses hardware and there will be a small subset of hardware like timers etc that are essential for the operating system to work. All these will need to be ported.

In protected mode operating systems that require an Memory Management Unit (MMU), one will have to port the code that does the MMU handling.

Most of this will to some extent be abstracted from the rest of the operating system but some of these abstractions may be based on certain assumptions. When this is the case, one will need to fix these instructions in order to get all this to work.

Then there is the boatload of drivers that will need to be ported to the new hardware.