Page 1 of 6

Nice Architectures to work with

Posted: Tue Jan 15, 2008 6:28 pm
by loadquo
I'm not looking at fastest or powerful. Just clean and nice to write an OS for. Good documentation wouldn't hurt.

Disclaimer: I have an adaptive computing background and I am trying to add to an arch a form of reinforcement learning. I want a clean base to extend, as I will have to build and adapt an OS for it as well.

Posted: Tue Jan 15, 2008 7:44 pm
by Pyrofan1
the intel x68 arch is widely used and very well documented.

Posted: Tue Jan 15, 2008 8:24 pm
by piranha
Pyrofan1 wrote:the intel x68 arch is widely used and very well documented.
Do you mean x86? :wink:

Posted: Tue Jan 15, 2008 9:38 pm
by Pyrofan1
hehe, typo

Re: Nice Architectures to work with

Posted: Wed Jan 16, 2008 2:06 am
by Solar
loadquo wrote:I'm not looking at fastest or powerful. Just clean and nice to write an OS for. Good documentation wouldn't hurt.
Don't laugh, but if fast / powerful / useful as a desktop is not an issue, how about a C64? The 6502 Assembler is about as simple as it gets, the C64 is exhaustively documented, and readily available as emulation.

Re: Nice Architectures to work with

Posted: Wed Jan 16, 2008 3:14 am
by JamesM
Solar wrote:
loadquo wrote:I'm not looking at fastest or powerful. Just clean and nice to write an OS for. Good documentation wouldn't hurt.
Don't laugh, but if fast / powerful / useful as a desktop is not an issue, how about a C64? The 6502 Assembler is about as simple as it gets, the C64 is exhaustively documented, and readily available as emulation.
/vote Zilog Z80 (or the Hitachi h180 clone, which has a bigger instruction set and TWO onboard serial ports! :o) 8)

Posted: Wed Jan 16, 2008 3:19 am
by 01000101
I dont know too many people with a spare commador64 or similar just kicking around ready to be developed on. may be heavily documented, but it is probably a pain in the arse to physically aquire.

I'd say just stick with x86/IA-32 architecures as you will find both manufacturer documents that are up to date, and be able to hold a conversation with modern os developers to help troubleshoot issues.

Posted: Wed Jan 16, 2008 3:58 am
by Solar
01000101 wrote:I dont know too many people with a spare commador64 or similar just kicking around ready to be developed on. may be heavily documented, but it is probably a pain in the arse to physically aquire.
Why physically? C64 emulators are not exactly hard to come by, which has the additional benefit that you can use the more powerful cross-assemblers available for the PC...

Posted: Wed Jan 16, 2008 4:59 am
by loadquo
As I am going to be extending it (adding new instructions etc) I will be extending an emulator to start with as my dev environment. I probably should have also said that it needs to have interrupts at the least. I'm not quite sure whether it needs an MMU or not.

I was wondering whether 68K, ARM, powerPC or even opensparc had a less cruft filled way of doing things (I've been looking at how interrupts and the GDT are setup in the x86, and it is just a little nasty).

Anyway, thanks for the advice. I've found the wiki very useful

Posted: Wed Jan 16, 2008 5:11 am
by Solar
Don't look at the PPC. While it's a "cleaner" architecture, it's a RISC CPU, which means the instruction set is even less suited for manual assembly than the x86.

I can't speak for ARM, but 68k might actually be worthwile. If you go for ColdFire (a successor of the 68k), you can even get your hands on developer boards if you have need for that.

Posted: Wed Jan 16, 2008 12:30 pm
by Combuster
I agree with solar: you'd probably want a CISC architecture. x86 is one, but it has become bloated after eons of applying backwards compatibility. The 68000 architecture is cleaner, but harder to get your hands on. If you have one of those with which you can work, I think that would be the best choice.

I'd definately stay away from HPPA and MIPS architectures. Their assembly is evil. Super-H is only marginally better but still a no. These are all RISC btw.

Then the architectures I am only marginally familiar with:
- 6502: IIRC it has a 16-bit address bus and 8-bit registers.
- AVR: 8-bit, RISC, slow, and runs on flash memory. But, you can get these from the local store for little money (like, you could try and build your own computer with only $25)

speaking of old machines, both the nes/famicom and genesis/megadrive have interesting hardware (6502, 68000 architecture respectively). You'll only need to solder a bit so you can run your own cartridge. I found stocks of those machines on the bazaar so you could probably pick up one if you know where to look.
And of course, there are emulators for those as well.

Posted: Wed Jan 16, 2008 1:49 pm
by Zacariaz
i have a zx81 for sale ;)
Anyway, i dont have a lot of knowledge about the various architecures, but i do know that when it comes to os development i hate x86.

Posted: Tue Jan 29, 2008 6:34 am
by AndrewAPrice
What do you hate about it? Once you're past the initial 1% of your kernel code which is x86 specific the rest of your code would be the same regardless of the architecture.

It's not the most perfect architecture, but it provides enough features for my needs (i.e. separating address spaces (paging), protecting kernel from programs (ring protection), atomic operations).

After all, I don't develop for the platform (I let the compiler handle that), I develop my operating system for itself and use the features given to me by the platform to achieve my goals.

I came to realise this when developing my game engine that works across both Direct3D and OpenGL (two very different APIs). Designing my engine for an API tied my engine down feature-wise and made development harder. Rather, I designed my engine for itself around the concepts in my head and used Direct3D and OpenGL as tools to help me accomplish my goal. When I thought about it this way, I realised neither is better than the other and I do not have a biased opinion against one or the other.

And when you think of programming like that, the same can be applied to your operating system. No platform is necessarily 'easier' to developer for than the other. You design your operating system how you want it to be designed, and use the features provided by the platform to turn the design into a reality. In practise this results to writing your code as platform independent as possible and abstracting away platform specific code behind functions such as AssociateMemoryWithProcess, and then you grab the architect's documentation and think; "how do I associate a memory address with a process?" and then you consider how paging can be adapted to suit your situation and not how your situation can be adapted to fit paging. Whether it be segments or pages or a flat memory system it should not matter nor affect the design of your operating system, since this is hidden behind a simple set of functions (InitialiseMemory, AllocateProcessMemory, DeallocateProcessMemory, etc) which use the features provided by the architect to achieve the goal of the function.

Posted: Wed Jan 30, 2008 10:42 am
by Dex
If i was starting again, i would go with the ARM, maybe gp2x or Nintendo ds and code it with FasmArm.

Posted: Wed Jan 30, 2008 8:01 pm
by elfenix
ARM -

Developer kits are fairly inexpensive.

And there is now a company offering a VERY reasonably priced platform.

I'm actually considering doing a bare-bones 'board bring-up' example:
http://www.buglabs.net/products

It's also one of the very few areas you can actually make money doing OS dev (believe me, I know)...