Assumptions about non-x86 hardware

[paulbarker]

I would like to know what I can assume about the hardware that my OS
will run on, in order to improve its design. I want to avoid designing
a system which cannot run on a major hardware platform, including
hardware platforms of the future.

To get a bit more specific, I am currently assuming the following is
true:

- The processor supports paging and virtual memory (ie. it has an MMU).

- User programs can be stopped from modifying or reading the kernel and
other user programs (by the use of protection levels or similar).

- The processor supports 8,16,32 and 64bit integers, or the compiler is
capable of emulating these without a huge performance loss (a slight
loss is acceptable, an order of magnitude loss is not).

- Some form of hardware clock or timer is provided, using IRQs (so
preemption can be supported).

- To support thread switching, the stack pointer register is accessible
as an ordinary register (so we can switch the stack), or hardware task
switching is provided (similar to x86 TSS's).

Are any of these not true for current platforms? Are future platforms
likely to support all of these? I think the answer is yes to both of
them, but if you can provide some advice or links to a comparison of
features provided by different platforms (I want to avoid looking
through hardware manuals for several architectures, at least for the
moment) I would be very greatful. I am specifically interested in all
recent flavours of PPC, MIPS and ARM (ARM sponsors the university
course I will be starting in september so I assume their processors
will be somewhere on the course), but information any other common
platforms is welcome.

Thanks in advance,
Paul Barker

[JoeKayzA]

Well, from what I can tell you, most embedded processors do not support an MMU, nor any type of privilege levels. AFAIK, ARM was designed mainly for embedded processors, and I'm quite sure that there is no MMU design for ARM based platforms...

Most other architectures I know of (PPC, MIPS, SPARC, IA64) have a standard MMU, which is likely to be implemented in the desktop and server versions of the CPU, but not in the embedded versions (note that there are plenty of PPC and MIPS microcontrollers out there). So far about the MMU...

Not all architectures provide instructions for all possible wordsizes (such as x86-64, which provides virtually all arithmetic instructions with wordsizes of 8,16,32 and 64 bit). ARM, for example, typically only supports either 8 or 32 bits. A good compiler (with support library) should be capable of emulating the other wordsizes, but the overhead depends on the compiler, and with heavy usage it might get quite significant. IMO you are best off when you use the CPU's native wordsize in the first place, and probably larger ones when really needed.

About the stack: Some architectures deal with the stack in a different way. SPARC and IA64 for example use register stacks and register windows - most local variables, parameters for subroutine calls and stuff are all kept in registers, when a subroutine is called, the addressable registers are 'shifted' out of the register window, and new ones become visible for use by the subroutine (it's quite hard to explain, so it's best you take a look at the IA64 manuals for more information). When there are no more free registers, the OS is called (through a trap) to save (and later restore) the registers to some memory location - the 'real' stack. So this might need a bit of rethinking to port your OS to these architectures.

cheers Joe

[paulbarker]

For actual arithmatic I will be using the native wordsize wherever possible. The main issue here is one particular structure, which I will have one per page.

Code: Select all

struct page {
    uint8_t next;
    uint8_t prev;
    uint16_t flags;
    uint32_t owner;
}

No arithmatic will be performed on any of these members. 'owner' is an index in a list, but the actual type it refers to hasnt been chosen yet. 'next' and 'prev' are links to the next and previous pages in a list (freelist, clean list, dirty list, etc). Since pages will be managed in blocks of 128, the range of these only needs to be 128 (with 0xFF used at end or start marker).

The point is that the memory usage per page is then fixed at 8 bytes, independent of the platform. Using native words or pointers here would take up much more space and it would also be variable.

On the point of an MMU, I was thinking of how to get from a page address to a page_t structure. Using the MMU, a set of virtually consecutive (but not physically consecutive) pages can be used and the page number just becomes an index into this big list. Without the MMU, the best I can thing of is a folded table (each entry points to a page full of entries, with maybe more levels here). It shouldnt be too hard to support both and decide which to use based on the presence of an MMU.

I'll have a think and add some more later.

[Pype.Clicker]

Well, from what I can tell you, most embedded processors do not support an MMU, nor any type of privilege levels. AFAIK, ARM was designed mainly for embedded processors, and I'm quite sure that there is no MMU design for ARM based platforms...

There are different "levels" or ARM. The ARMv7 you find in the Gameboy, Sharp Zaurus and IXP network processors do have an MMU and kernel/user levels.

ARM, for example, typically only supports either 8 or 32 bits. A good compiler (with support library) should be capable of emulating the other wordsizes, but the overhead depends on the compiler, and with heavy usage it might get quite significant.

Yep. That's quite typical from RISC computers. Intel x86 is one of the sole architecture that has "sub-registers" for accessing individual bytes of a word. For others, bitfield 16..23 do not differ from bitfield 15..22 for access code.

About the stack: Some architectures deal with the stack in a different way. SPARC and IA64 for example use register stacks and register windows - most local variables,

true, yet as far as i know, that doesn't mean you don't have the "stack pointer" available from a register ... note that some architecture do not automatically use a stack for procedure linking but instead receive the address of the "CALL" instruction in a specific register (which they can put on a stack afterwards if they want to). What you'll probably miss the most will be "pushad" instruction -- i can't think of a RISC machine with an equivalent.

[Brendan]

Hi,

I've got an odd/related question, but now that Apple is using Intel too, if an OS developer was thinking of developing for a second or third architecture, which architecture would be the most important after 80x86?

For example, in 5 years time will Itanium, Alpha, MIPS, PowerPC, Cell, Sparc or something else have the second largest desktop/workstation/server market share?

I've been trying to find out (Google), but haven't had much luck... Of course no-one can predict the future, but rough guesses can help - I'd hate to buy an Alpha machine and spend years figuring things out, only to find out it's been discontinued...


Cheers,

Brendan

[zloba]

Intel x86 is one of the sole architecture that has "sub-registers" for accessing individual bytes of a word. For others, bitfield 16..23 do not differ from bitfield 15..22 for access code.

how do you access bits 16..23 using subregisters? (without shifting or swapping)

[Colonel Kernel]

Hi,

I've got an odd/related question, but now that Apple is using Intel too, if an OS developer was thinking of developing for a second or third architecture, which architecture would be the most important after 80x86?

For example, in 5 years time will Itanium, Alpha, MIPS, PowerPC, Cell, Sparc or something else have the second largest desktop/workstation/server market share?

I've been trying to find out (Google), but haven't had much luck... Of course no-one can predict the future, but rough guesses can help - I'd hate to buy an Alpha machine and spend years figuring things out, only to find out it's been discontinued...


Cheers,

Brendan

Some believe that x86 (or presumably x64 nowadays) will simply push all the other competitors aside, now that the CISC nature of the instruction set no longer dictates a CISC implementation. Once again, backwards compatibility trumps technical elegance.

Don't bother buying an Alpha. I think it's already dead (unfortunately). IIRC, Compaq bought DEC and then discontinued the Alpha in favour of the Itanium.

[Brendan]

Hi,

Some believe that x86 (or presumably x64 nowadays) will simply push all the other competitors aside, now that the CISC nature of the instruction set no longer dictates a CISC implementation. Once again, backwards compatibility trumps technical elegance.

Don't bother buying an Alpha. I think it's already dead (unfortunately). IIRC, Compaq bought DEC and then discontinued the Alpha in favour of the Itanium.

Thanks. I'm not sure what this leaves though - I can imagine PowerPC dying (or being replaced by Cell), and MIPS and ARM being used for embedded systems and not much else.

Sun seems to be using Opteron in addition to Sparc, so I'm wondering how long it'll take until they're using Opteron instead of Sparc.

That seems to leave Itanium and Cell - both very interesting CPUs, but both a little hard to get hold of (and no emulators for either AFAIK)...

BTW - I heard Alpha died too, but HP are still selling them!


Cheers,

Brendan

[JoeKayzA]

I don't believe that PowerPC is dying, AFAIK it's just as common in the embedded sector as, for ex., MIPS. But it's true, now that Apple turned away, the future for non-x86 machines on the desktop sector seems to be spoiled...

On the server market however, I believe that POWER will still play an important role in the next years. Also don't forget that the Cell is still based on a PowerPC core. I would say that it's actually an extension rather than a replacement to current ppc machines.

So for me, I'd say that PPC and Itanium are the most important machine architectures for the next years, in this order.

cheers Joe

[Solar]

Since it's guesswork anyway, I'll just give my ?0.02.

x86, AMD64, Cell for the desktop. (And no, I don't share the optimism of the Amiga fans that the PPC will remain a force in the desktop market.)

IA64, AMD64, POWER, Sparc for the server.

ARM, XScale, MIPS, PPC, Coldfire for the embedded sector. (SH4 was a big player a couple of years ago, don't know how they fared.)

[Pype.Clicker]

Intel x86 is one of the sole architecture that has "sub-registers" for accessing individual bytes of a word. For others, bitfield 16..23 do not differ from bitfield 15..22 for access code.

how do you access bits 16..23 using subregisters? (without shifting or swapping)

poor example from me. should have said "8..15" ratyher than "16..23"

[RetainSoftware]

assumption is the mother of all fuckups ;D

Sorry, i got told this so many times that it pops up every time i hear the word assumption.

[Solar]

I've coined a TLA (three-letter acronym) for it:

DNA. (Do not assume.)

[paulbarker]

Well you have to assume the platform provides at least some minimum level of functionality. I'm just trying to get straight whats a 'common' feature and whats infact quite rare.

[Solar]

Well... when I started my OS project a couple of years ago, I was all "portability" myself. Today - with the advent of the x86 Apple - if I would start a desktop OS project, I'd probably focus on x86 / x86_64 and leave the rest to some enthusiasts to port over...