Easiest non-x86 architecture

[inx]

Well, I'm thinking of doing a rewrite of my kernel, and as an added measure to ensure portability, I'm thinking I'd like to write it for a non-x86 system first.
So, this question just goes out to anyone who's ported their kernel to or done research on a non-x86 system with an MMU: Which architecture do you think
has the most documentation/standard peripherals readily available? Also, I'd be curious as to what you think the best emulator (preferably with debugging
facilities) you think is best for your suggested arch.

[Love4Boobies]

I don't know about emulators (though you can probably check out the ones Wikipedia spits out) but the easiest architecture is probably ARM. You could also look for RISC CPUs such as MIPS. You could have omitted "non-x86" architecture from your subject since it's probably the most arcane.

[inx]

Thanks, I'll look into those. I would imagine I'll be able to find something about MIPS, my worry about ARM is finding a platform. I know the CPU's nice,
but if the documentation for the rest of the hardware sucks, that's a bit of a problem. For example, I was looking into PowerPC, and from the CPU manuals,
it's rather nice. However, practical documentation on open firmware's API is extremely lacking, and that's the easiest way to do video at all on PPC.

[manonthemoon]

QEMU supports several non-x86 architectures: ARM, SPARC, MIPS, and PowerPC. Also, PearPC emulates the PPC architecture.

PS: You can debug via a GDB stub on QEMU.

[Combuster]

Get an old macbook and you have a PowerPC box with all the gimmicks you might want. Coming by an ARM devkit or MIPS box is much harder.

[Brendan]

Hi,

If you filter out all the "sealed case" proprietory systems (with no documentation), and then ignore everything that isn't currently in production (e.g. guaranteed to be obsolete by the time your OS is finished), then filter out experimental stuff (FPGA, various development boards, etc); then that leaves you with about 3 choices: PowerPC, Itanium and SPARC (all relatively expensive servers).

From this I'd probably choose PowerPC or SPARC, as you can develop most of the OS on cheaper/older hardware before worrying about more modern systems. In both cases there's 32-bit CPUs and 64-bit CPUs, and I'd want to start with a 64-bit CPU, which would mean maybe a second-hand Apple G5 system (around $300), or a second-hand Sun UltraSPARC (around $100).

Also, all of these architectures (PowerPC, Itanium and SPARC) support standard PCI devices, which means you should be able to port device drivers between different versions of your OS, rather than writing extra device drivers specifically for some non-PCI architecture.


Cheers,

Brendan

[Solar]

If "easiest" is actually your main concern, I would point out the 680x0... but I assume you are also looking for "contemporary power" and "availability of real hardware"...

[JamesM]

I'd go for PowerPC. It's the daddy

I'd also avoid SPARC with a 12-foot bargepole. Having written an emulator for it, I can confirm that it is nasty*.


* All opinions expressed are the opinion of the author only.

[jal]

then filter out experimental stuff (FPGA, various development boards, etc)

That seems rather arbitrary. I'd definitely look into ARM, e.g. the Beagle Board. It is very well documented.


JAL

[Love4Boobies]

The problem with ARM is that CPUs are not compatible from one generation to another. In a way, it's really nice that the x86 and clones have kept compatibility to nearly 100% - although this also means that everything is rather arcane and all bad decisions from the past are still screwing with us.

[Brendan]

Hi,

then filter out experimental stuff (FPGA, various development boards, etc)

That seems rather arbitrary. I'd definitely look into ARM, e.g. the Beagle Board. It is very well documented.

You're right - I've made assumptions.

I assumed that the OS developer is hoping that normal people (people who aren't programmers and aren't manufacturing embedded systems) might use their OS sometime in the future (and that other programmers will recognize the OS's potential and volunteer to write some things, like device drivers).

If you don't care if anyone uses your OS in the future, then you can pick any architecture you like - I'd suggest Commodore64: it's very well documented, very easy to program and very cheap to buy (people give them away for free); and there's several emulators, and no hardware compatibility problems.


Cheers,

Brendan

[inx]

Thank you all for your suggestions and insight.

If you don't care if anyone uses your OS in the future, then you can pick any architecture you like - I'd suggest Commodore64

Whether I do or don't care, though, the C64 fails that whole 'MMU' requirement.

Anyway, I actually have a lot of both PPC and 68k macs, so I do have real hardware for both of those. Unfortunately, they both fail my hope for lots of
documentation. I can almost manage to figure out open firmware for the PPC ones from the Linux source, however that's rather difficult without some
form of documentation in the first place. Reverse engineering may be necessary, but that doesn't mean I have to like it.

What else do I have in storage... A 286 almost counts, but precisely because its MMU is barely passable as one. lol

I don't actually have any requirement about modern general purpose-style power. My goal is to have a RAM requirement of 4MB for the whole system in
text-only/serial console mode. ARM/MIPS are interesting, especially because, if I'm willing to reverse engineer docs from Linux source, I can use a relatively
cheap router as my real hardware.

Unfortunately, I have no real hardware for anything 64-bit other than x86-64, although that's not that far from x86. Also, now that I think of it, I should probably
use something big-endian, such as my m68k or PPC boxes. Makes sure I do no endianness stupidity.

If I'm going for something for which I have real hardware, I should probably do PPC first, since it meets so many of my "difference" goals. It's almost ideal..
Half of my PPC systems have NuBus, the other half PCI, which gives some good practice for inter-architecture portable drivers. For NuBus, my m68k machines
have that, so I can test portability there, and for PCI, x86 has that.

I actually think I will go that route. Start with PPC, then most likely port to x86_64 so that I can ensure 64-bit portability, then to x86 and, lastly, m68k. I guess I
am going to commit to some reverse engineering. I have terrible short term memory, though, so it's most likely going to be a matter of having a separate
ongoing project of writing documentation for myself. I'll try to keep it clean and readable, and I can add it to the wiki as I go, if you're all interested.

I'd also avoid SPARC with a 12-foot bargepole. Having written an emulator for it, I can confirm that it is nasty*.

That's disappointing. I haven't dug too deeply along those lines, considering that's server only these days, but it seemed intriguing. If I may ask, what main
point(s) make(s) you feel that way about it?

Coming by an ARM devkit or MIPS box is much harder.

I actually did some correspondence via email with a MIPS rep about this at one point. Believe it or not, they want US$10,000 for the starter board with no addons.

As far as PowerPC goes, the unfortunate bit is that there's a lot of good documentation about open firmware all over Apple's info archives, but, predictably, almost none
about interfacing with it, just a lot about configuring and patching it (from the Rhapsody era) and (oddly) the FORTH interface. If anyone knows of any good documentation
about, say, the memory structures involved, I'd much appreciate a tip there.

P.S. Sorry for rambling.

EDIT: Does anyone know if QEMU's GDB stub stuff works cross-platform? I was looking at the docs, and its PPC emulator supports one exact system that I own, but I'd hate to
have to run a PPC emulator on a 350MHz PPC... I'm fairly certain KQEMU doesn't work on PPC, and even if it did, that's a bad idea for debugging.

[JamesM]

I can almost manage to figure out open firmware for the PPC ones from the Linux source, however that's rather difficult without some
form of documentation in the first place. Reverse engineering may be necessary, but that doesn't mean I have to like it.

Have you considered looking at the Openfirmware documentation? You'll also need to look at some of the bindings, specifically the PowerPC one.

Having written a PPC port of my OS, I can confirm that there is enough information there and in the POWER architecture specifications (plus a processor-specific manual, all available for free from google) to write one without *too* much reverse engineering.

[jal]

I assumed that the OS developer is hoping that normal people (people who aren't programmers and aren't manufacturing embedded systems) might use their OS sometime in the future (and that other programmers will recognize the OS's potential and volunteer to write some things, like device drivers).

I'm pretty sure that most OS developers with any sense of reality do not hope "normal people (...) might use their OS", as that pretty much for certain will not happen. Not knowing better, I'd almost pass you for a newbie on this.

If you don't care if anyone uses your OS in the future, then you can pick any architecture you like - I'd suggest Commodore64: it's very well documented, very easy to program and very cheap to buy (people give them away for free); and there's several emulators, and no hardware compatibility problems.

There's no need to be sarcastic. We are talking modern hardware here. Home computers of times past have all kinds of restrictions which make them very interesting, but not for (most) OS developers.


JAL

[inx]

Have you considered looking at the Openfirmware documentation? You'll also need to look at some of the bindings, specifically the PowerPC one.

Thank you! That's wonderful, exactly what I've been looking for. I really have tried to search for that, repeatedly. I'm not sure why I never managed to find it.