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.
Nice Architectures to work with
-
piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Do you mean x86?Pyrofan1 wrote:the intel x68 arch is widely used and very well documented.
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: Nice Architectures to work with
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.loadquo wrote:I'm not looking at fastest or powerful. Just clean and nice to write an OS for. Good documentation wouldn't hurt.
Every good solution is obvious once you've found it.
Re: Nice Architectures to work with
/vote Zilog Z80 (or the Hitachi h180 clone, which has a bigger instruction set and TWO onboard serial ports!Solar wrote: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.loadquo wrote:I'm not looking at fastest or powerful. Just clean and nice to write an OS for. Good documentation wouldn't hurt.
) 
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.
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.
Website: https://joscor.com
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...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.
Every good solution is obvious once you've found it.
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
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
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.
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.
Every good solution is obvious once you've found it.
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
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.
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.
-
AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
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.
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.
My OS is Perception.
-
elfenix
- Member
- Posts: 50
- Joined: Sun Dec 02, 2007 1:24 pm
- Libera.chat IRC: elfenix
- Location: United States
- Contact:
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)...
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)...