OSDev.org

Hi folks,

I have recently launched a new OS project for routers and switching devices. I decided to start up by writing an aarch64 (armv8-a) kernel first, then work on x86_64 later on when I feel interested.

Since this is my first time to program 64-bit ARM code, I am really amused. The instruction set is very well designed, and it provides you with a lot of varieties and options. Although the architecture is categorized by people as RISC, you have a good number of instructions and addressing modes that make your programming easy.

At first, I thought that I my assembler code for aarch64 will be as long and verbose as Java , but I was surprised by how I can do most things in a single instruction.

To give you a classical ARM example:

This cool instruction shifts-left X2 by 40 bits, adds the result to X1, then stores the result of the ADD in X3. You can imagine how the RISC pipeline can facilitate the execution of this instruction.

Compared to x86_64, I feel that aarch64 (as an architecture - in an abstract sense) is more well-designed than amd64. The latter has a lot of technical debt thanks to the long history of x86 architecture; and it feels more complicated and less flexible than the former.

You have got a lot of system registers in aarch64 that help you control the MMU, TLB, caches, exception levels, etc. Virtualization in aarch64 is easier to understand than VT-x and VT-d stuff. By basic understanding of the underlying pipeline, you can write highly-optimized code and you can easily count the cycles.

What do you think guys? Do you have any speculations on the future of the PC architecture? Will we ever have a new series of low-end arm64 computers targeting home users that will supersede the current x86 PC architecture? What about the competition between Intel, AMD, and ARM?

Thanks guys!

QUICK EDIT: seems that my post is wrongly posted to "OS Development". My intention was to put it under "OS Design & Theory". Feel free to move it there if you can. Thanks.

Thank you, Captain Obvious. AMD64 is the tail-end of a development that started on 8-bit microprocessors and tried to maintain some form of compatibility ever since. The reason for the weird and wasteful way segmentation works in 16 bit mode (21 bits of information encoded in 32 bits of data? At a time when the time stamps of the file system only could record in two-second granularity, since they couldn't spare that one bit? Sheesh) was that this way, the programs would rarely have to be changed (much).

Then 16-bit protected mode happened, and it hobbles the format of the descriptor tables to this day. 64-bit mode was actually a way to clean up much of the superfluous features of 32-bit mode that nobody ever used. But there's a limit to what you can clean up before it stops being compatible.

Most RISC architectures have a better designed interrupt system than x86. All the ones I know (ARM, PowerPC, Microblaze) only have a single vector for external interrupts, leaving the differentiation of interrupt sources to external hardware. This means, you have the IRQ available as data. Whereas on x86, you only get different entry points for your different IRQs, and most OSes end up having all of those push the IRQ number on stack and branching to a unified handler. So, using software to get what RISC hardware is giving you already.

Most RISC architectures also have more registers. Admittedly not ARM, which clocks in at 16 (and four of those are special-purpose), but both PowerPC and Microblaze have 32 registers. Well, OK, one of Microblaze's registers is permanently set to zero. They have so may, they can afford to spend one reg for that. It means they don't need special instructions for many things.

There are problems with other architectures, though. Most RISC architectures have a code density problem, meaning the same C code assembles to larger object code. However, in this day and age, I doubt the difference matters. And ARM has Thumb mode, if it does start to become burdensome.

However, I do not see ARM or any other architecture taking over the Desktop space. Too much inertia. For better or worse, for the foreseeable future we're stuck with this slapped together abomination that is AMD64. Replacement has been attempted in the past, and it has never worked. Technical merit does not matter to the consumer, they just want their MS Office to work.

Note that the classic distinction between CISC and RISC does not consider the number of instructions but the availability of complex addressing modes. CISC architectures traditionally have register-memory modes with complex memory addressing, while RISC are load-store architectures. The words "CISC" and "RISC" reflect their semantics very poorly.

TBH, the architecture doesn't really matter to most people. It's of interest to compiler writers, but most of us use high-level languages which mostly hide the underlying architecture.

The x86 processors do have a rich set of registers designed to cope with media processing, which is what a lot of computers are used for.