OSDev.org

Hello,

I'm getting to the stage with my OS whereby I'm interested in porting it to other architectures. Currently, my OS is only designed to work on i686.

What things can I rely on the existence of? I want to segment by source code by arch, but I need to know how "generic" I need to make the cross-platform region of the code. Chips I'm potentially considering supporting in the future:

- x86_64
- ARM (v7)
- PowerPC

Can I rely on the existence of:

- IRQs?
- Paging?
- Segmentation?
- A serial I/O device?
- Multiboot-compliance bootloaders?

For clarity: I'm not suggesting these systems should all work the same way internally. I'm asking whether it's okay to assume these all exist in some form such that I can have a "paging.h" header or whatever that is standard across all platforms and then have platform-specific implementations.

Without knowing which of these I may / may not have available in the future, it's hard to structure the source code in a way that will allow for further expansion with minimal effort.

You can rely on existence of a CPU, there is usually some sort of IRQ system, but it works differently in all systems. The rest from your list may or may not be present.

So really, you can only rely on CPU being there, unless you compile for a DSP.

So you can't really rely on anything being there. Why would you?


You can look at how other OSes structure their source code for portability. There are a few notably portable OSes, take a look at their source code structure.

zesterer wrote:- IRQs?

Yes. I'm not sure I could name any CPU architectures that don't have IRQs.

zesterer wrote:- Paging?

Some will support it, some (mostly embedded CPUs) won't.

zesterer wrote:- Segmentation?

No.

zesterer wrote:- A serial I/O device?

This depends on the hardware around the CPU, not the CPU itself (except ARM SoC).

zesterer wrote:- Multiboot-compliance bootloaders?

The Multiboot specification only covers x86, but I did find an unofficial ARM version.

Octocontrabass wrote:

zesterer wrote:- Paging?

Some will support it, some (mostly embedded CPUs) won't.

Is it sensible to imagine that I'd not have paging on a target? I hear that Linux requires paging... I think a rough generalisation is "I'd like to be able to port to most systems that Linux has been ported to". Is paging / other stuff still not a guarantee?

All archs that are able to run a usual Linux user space (e.g. bash and GCC) support paging.

Korona wrote:All archs that are able to run a usual Linux user space (e.g. bash and GCC) support paging.

Except cortex-m series which don't have an MMU.

Okay, thanks for the info everyone

dozniak wrote:

Korona wrote:All archs that are able to run a usual Linux user space (e.g. bash and GCC) support paging.

Except cortex-m series which don't have an MMU.

Does Cortex-M run a GNU userland (and not just the Linux kernel with a specially crafted userland)? fork() requires an MMU and fork() is heavily used in many standard Linux tools.

Korona wrote: Does Cortex-M run a GNU userland (and not just the Linux kernel with a specially crafted userland)? fork() requires an MMU and fork() is heavily used in many standard Linux tools.

It runs uCLinux userspace.

(uC)Linux can run without an MMU. There even was a Playstation Portable port of Linux.

Roman wrote:(uC)Linux can run without an MMU. There even was a Playstation Portable port of Linux.

It's worth noting that the PSP has a MIPS R4000 processor with an MMU that supports a 40/64-bit virtual address space and a 36-bit physical address space. Really quite beefy for such a small machine from the early-mid 2000s!

Roman wrote:(uC)Linux can run without an MMU. There even was a Playstation Portable port of Linux.

and a Nintendo DS too !

Octocontrabass wrote:

zesterer wrote:- IRQs?

Yes. I'm not sure I could name any CPU architectures that don't have IRQs.

Several early architectures did, before they were actually invented in the mid-1950s. According to Wikipedia, hardwired, special-purpose interrupts were first used on the Univac 1103A as an optimization, but as a general design principle they didn't really exist until the early 1960s, in the IBM Stretch (again according to Wikipedia). I don't know of any microprocessor in general use that didn't other than maybe the VIPER (it was designed for 'provably stable operation', and had foregone other things such as a hardware stack on the basis that they were "inherently unreliable", supposedly).

The Ceres workstation didn't use interrupts - the CPU it was based on, the NS32032, did support them, but the interrupt lines were disabled because Wirth decided he didn't like the idea of interrupts after he had trouble with the interrupt logic on the Lilith. He argued that the problems arising from the non-determinism they created were more of a drag on performance (sue to added hardware and the need for the software to be reentrant, among other things) than polling did, and that it was took great a source of instability in any case - but then, AFAIK he also banned any use of languages other than Oberon itself in the operating system of the same name which it was used with, and required that the compiler automatically insert 'voluntary' sleeps into the application programs, so make of that what you will.

well that's ugly.
The only reason I'd avoid using interruption/event mechanism would be to make a system that could guarantee the max duration of any syscall. But this has a cost , and probably you'd have some syscall called GuessIfThatEventHappned which would be Very slow , probing CPU ports and memory.

I don't think anyone needs to worry about interrupts not being available on modern CPUs. Sure, architectures like that used to exist before people figured out that they can be used to increase CPU utilization during I/O operations, when multiprogramming first appeared, or before they became inexpensive. For general-purpose machines, you can also assume you will have some sort of virtual memory (usually paging but sometimes segmentation). This is certainly true for all the architectures mentioned in the original post.

However, I think you're looking at this all wrong. Computers are tools used to solve problems and so are operating systems. In order to solve problems, tools are often used together. Hence, if you want to solve a problem, you have to think both about what hardware components to use and about what software components are appropriate. Therefore, it's perfectly reasonable to require an architecture with interrupt support if your solution requires interrupts. If you just want a piece of software to run on as many machines as possible, what is the ultimate problem you are trying to solve? Does it have any real value or are you just compromising left and right so you can increase the architecture count of a component of purposeless systems?