Portability (and virtual memory issues)

[Unwritten Axiom]

Hi.

I want my OS to be as portable as possible, but of course, there are some systems that would make porting a nightmare.
I didn't think the GBA was one of them, until I started thinking... "How would I implement virtual memory?!"
The GBA, as far as I can tell, doesn't support virtual memory, and I was wondering if there was a way to *fake* it, like how you can change the segment (on a x86) to make your kernel think its at 0xC0000000 when its actually loaded at 0x100000.

Also, are there any other systems (preferably widely used) that I could code my OS for? I only have x86s here, and I'd like to code for other systems. I'm trying to design my OS so it can run on anything with a video screen and some sort of an input device (a reasonable input device, of course).

I was thinking of PPCs, but I can't find any good emulators (Bochs-like), or compilers (Assembly/C).

My endeavors with the GBA have proven difficult, because most of my code has to be compiled by other people with Linux, because I can't get a reasonable ARM C compiler for windows. If anyone knows of a good one (NOT Devkit Advance), please let me know.

I'm hoping to try to get this off the ground for other platforms, I don't want to be limited to the x86 architecture.

Thanks.

[Tim]

Targetting systems without an MMU is a pain; you either support the lowest common denominator of all the systems you target, or write special code to support features differently on different platforms.

The lack of an MMU means that you don't get any automatic demand allocation of memory or swapping (which rely on a page not present fault), nor copy-on-write (which relies on an access violation fault on read-only pages). However, a single address space does make sharing easier, and allows faster IPC.

Regarding your second question, I'm writing this on a Sharp Zaurus handheld, which runs Linux. There exists source code for a couple of kernels for this machine, so it is possible to write your own OS, but apparently no simulators or emulators. As far as I can tell, you've got to re-flash the unit from Compact Flash every time you test.

Ebay sounds like a good place to pick up old or unusual hardware. I got a dual Pentium Pro motherboard, CPUs and memory from there a while ago.

[Unwritten Axiom]

Paging wasn't really such a big problem, because I could just dump the demand paging and only partially emulate it so I could change the address space.

I suppose if I only allowed one app to run at a time (on incapable machines) I wouldn't have to do any of this, but would it be the right choice when there is quite a bit of processing power going to waste[sup]*[/sup]?

[sub]*Not so much of a problem on a GBA[/sub]

EDIT: Now that I think about it, I need some sort of MMU/Emulated MMU, because limiting the number of apps running could be a mess, especially on a kernel that is designed to run as many apps as the resources will allow.

My main question is, is it even possible to emulate a MMU on a GBA?

EDIT2: Emulation is an especially tempting concept right now, because I wouldn't have to make any major modifications to the code, because the needed functions will just make a few calls to the emulator.

[Tim]

You could do this if you were willing to allocate all memory when it was requested, rather than when it was acutally used (as you would on a machine with an MMU).

So to map an executable or memory-mapped file, you'd allocate all the memory and read the whole file at once. When you created a thread, you'd allocate the stack to the maximum sie (and it wouldn't grow).

You might want to look at Minix for examples of this, although Minix doesn't use an MMU even if one is available (it uses limited segmentation on x86). The only other examples I can think of are Windows/286 and Windows 3.0 in real mode.

[Solar]

Mind if I ask one question?

With "portable", do you mean:

a) it is real easy to port the OS to a different hardware;

b) it is real easy to port an application to a different hardware running the same OS?

The two are very different things, you know...

[Unwritten Axiom]

I meant making the OS itself portable.
The applications would be machine specific.

I may try to implement an executable format that can be run on multiple machines, with an interpreter for each type of machine so it could run the opcodes in the exe.

[Curufir]

Hmm, what I'm thinking is something along the lines of Java. Cross platform applications can be distributed in a bytecode fashion (With the initial bytecode translation dealing with any platform common optimisations) then assembled on the desired platform (With any platform specific optimisations) at the installation phase.

Makes installation a little longer, but is a win scenario for producing a single installer that crosses all platforms the OS will support.

The basic concept is to present the app programmer with a defined set of interfaces to the OS and its functions that is independent of the target platform. The OS deals with the actual hardware interface, the apps float on top of it blissfully unaware of the actual hardware they are running on.

Ties in with the idea of having a single language to use throughout the entire OS. Programming, scripting etc, will all get handled in the same language (Or using subset of the language) and using the same mechanisms (Once I figure out the mechanics of the language ;D). Since it's a hobby and I don't have to persuade anyone to give up their pet HLL in favour of my own language this works fine. In real life there'd have to be some compromises.

[Solar]

I meant making the OS itself portable.
The applications would be machine specific.

...so you have an easier time covering multiple platforms, while your users still would have to port their code over?

Serious, I believe you have a think-o in there. You probably want to provide your users with an identical environment regardless of the hardware platform.

That doesn't really require your OS to be portable, but rather that you abstract the hardware the same way on different platforms.

Even if you have two 100% distinct operating systems, if their API is the same all it requires to "port" an application is a recompile...

[mr. xsism]

hey,
there is NO *real* /\way/\ to make a truely portable OS. Not even Java based OSes are truely portable because they rely on the JavaVM beong on the platform.

The best thing to do for portability is limiting the *ability* of your OS. Don't make it so hardware specific that it is easier to write an entire new OS for another platform.

It is most likely that when you port an OS to another platform you will end up recoding the OS from the ground up on about 80% of the code. This is ture because usually about 80% of the code in a OS/kernel deals diretly with a specific type of hardware.

You can always try to make the code modular not by just binary code, but the written code. don't blob a whole nuvh of similar code togther. Make it easy on yourself and other devers and seperate the code logically by it's purpose and responsibility.

That's my humble advice.

Regards,
mr. xsism

[be]

What about Inferno Virtual Machine?

[Pype.Clicker]

one thing you can make to make your OS easily portable is to abstract the virtual memory trough an interface that could be common for every platform (like "here's a mapping list i want to provide, change the hardware resources to make it so" ).

You could also define a set of higher-level properties like "this is a copy-on-write region" etc. and have the target-specific implementation of the MMU map the property to flags in the page tables.

This way, the rest of your code is independent of the actual MMU organisation, and all you have to do is linking your kernel with the proper MMU support implementation for the target architecture.

[Tim]

That's all very well, but what do you do if the target doesn't support these features, as the ARM in the Gameboy Advance doesn't? You're faced with a lot of conditional code everywhere.

[Solar]

Like, having the application provide a list of required services (copy-on-write, hard real-time scheduling, gfx support), and the OS denying execution (or better yet, installation) if one of those services isn't provided ("sorry, no gfx here")?

As the range of devices increases, chances are that not all devices up and down the scale can support all the applications. WebCam software requires a WebCam, and if you don't have one no-one blames either the app or the OS, no? So why not extend that notion to a list of well-defined OS services.

The thing is, you have to learn a *lot* about many different CPUs first, and the CPU manuals aren't always that obvious about it.