OSDev.org

Antti wrote:With a very little knowledge, everyone can have a "Hello World OS" for their x86 PC. I don't currently even know where to get an ARM-based machine that is "open enough" to do that. I don't mean the "a-toy-computer-toolkit" but "real systems". Jailbreaking a closed proprietary system would be one way, maybe.

You see, "x86 PC compatible" is not just a CPU family, it's an architecture specification. Every "x86 PC" shares not only the CPU, but many significant details of how it works (BIOS / EFI boot, 0xb800 being the text buffer, etc). Initially, this platform did not even have software to go with it (the good few days before IBM hired Bill Gates to do MS-DOS).

On the other hand, "ARM" is merely a CPU architecture description, an instruction set architecture, and a reference implementation. Licensees take this technologies, and do whatever they like with it. The Broadcom BCM2835 and the WonderMedia WM8505 are both "ARM", and of course there are some similarities between a Raspberry Pi and a JayBook 9901 in that they support LAN and USB and audio-out etc., but there are also bound to be huge differences, because there was never meant to be "the" ARM platform. And either comes packaged & shipped with its intended software installed & running, so the manufacturer doesn't bother much about how a hobbyist might access it.

Ah...

True for the JayBook 9901, anyway.

Solar wrote:

Antti wrote:With a very little knowledge, everyone can have a "Hello World OS" for their x86 PC. I don't currently even know where to get an ARM-based machine that is "open enough" to do that. I don't mean the "a-toy-computer-toolkit" but "real systems". Jailbreaking a closed proprietary system would be one way, maybe.

You see, "x86 PC compatible" is not just a CPU family, it's an architecture specification. Every "x86 PC" shares not only the CPU, but many significant details of how it works (BIOS / EFI boot, 0xb800 being the text buffer, etc). Initially, this platform did not even have software to go with it (the good few days before IBM hired Bill Gates to do MS-DOS).

Careful there. The definition of the hardware in an "x86 PC" is getting looser; for example, under EFI, hardware text mode is dead.

Actually, we are rapidly heading towards a stage (thanks to EFI and ACPI) where the only defined hardware in a PC will be the CPU and architecturally defined hardware (e.g. the IO APICs, HPET). Everything else is rapidly going. Keyboard controller? Gone (even on some BIOS machines!). PIC? Also gone.

We are in an exciting period. The legacy free PC is approaching... and with it, Intel have, in a way, shot themselves in the foot. You see, both EFI and ACPI support ARM... and PC hardware is about to become almost as fragmented as ARM.

With Windows RT being ARM+EFI based... we may be rapidly approaching the point at which you can get ARM devices which are as inter-compatible as PCs are today.

I think it's time for me to retire participating in this hobby altogether. My active knowledge is rapidly approaching the stage of "outdated, dangerously so".

It is clear that I compare every CPU architecture with x86 because almost all my low-level programming have been targeted to it. However, I have glanced through a book about ARM7 assembly and been somehow impressed by it. I am looking forward to study other architectures also to get some perspective on CPUs. Such a small detail in ARM7 as an exception and interrupt handling vector was interesting. A vector containing actual instructions rather than addresses fit perfectly with the fixed instruction width.

As an ontopic, my ideal CPU has a very big cache. The traditional main memory is non-volatile memory that replaces hard disk drives so all the data are stored in 64-bit memory space.

A vector containing actual instructions rather than addresses fit perfectly with the fixed instruction width.

Apart from on M class, where this isn't the case.

I have been looking through the post and the ideas are different but at the same time good ideas. In about 2-3 months I'm going to start building my own processor architecture and then implement it on my fpga board I'm building right now. The actual internals aren't worked out yet so there lots of room for ideas. I'm designing it to be a vector processor. It'll have busses to connect each processor and from the beginning a "BIOS" (not a bios but a similar idea) will check how many vectors cores (meaning there could be 1 fpga with two core and then there could be another fpga with only 1 core) there are and divide the signals between them making it faster. If any body wants to join in pm me and we can work out with desktop sharing software.

Requirements:
To know verilog, system-c, or ect.

BTW I know the forum doesn't like things like this so to be back on subject my os dream cpu is what I mentioned above.

I hate caching and cache coherency. I think they are a plague on the industry. My dream CPUs run in a multi-CPU environment while destroying the entire concept of caching. I think the resulting simplification in the chip design would immensely improve the computer design.

The motherboard would provide access from the CPU sockets to burst-mode main data memory, a separate multi-ported code memory, and a separate "shared message space". There would be a very limited total number of sockets on the motherboard, for both CPUs and devices (eg. 32).

The code memory would understand the opcodes well enough to "force feed" instruction bytes to the CPU. The CPU would not need to "request" memory transfers from code memory except on branch instructions (when they would set a "took a branch to a new address" flag).

Main data memory is divided into big "pages" that are owned by particular devices. Transfers are done an entire page at a time.

Shared memory would contain a very limited amount of RAM, shared between each pair of sockets. Each socket would know exactly which addresses contained input from every other socket, and which were output to every other socket. Interrupts would be automatically sent when input was available from any socket. Since the inputs and outputs are unidirectional, there would be no need for locking. "Messages" sent from one device into a shared memory area would be automatically queued. Maybe they would have a particular fixed-length format.

Other devices plug into sockets on the motherboard, and have access to both burst-mode and shared memory (not to code memory). The devices communicate with each other through the shared memory, and use it to pass commands and ownership of burst-mode pages between devices. CPUs also use the shared memory area to handle software locking. Most of the logic in today's software drivers gets encoded into the silicon of the device driver chips. It has been far too many decades that lazy designers have left all of the work to software -- it's past time to move the work back into the silicon where it belongs. The protocols and standards have matured enough to make them concrete now. All the functions of each device chip are accessed by sending asynchronous commands and replies through the hardware shared memory system.

There would be one special "alarm clock device" that controls ownership and timing of all the devices on the motherboard.

The CPUs are built to have millions of on-chip indirectly addressible registers, arranged in pages. Some pages are active, and other pages are inactive (where they can be flushed and loaded to/from burst-mode memory asynchronously). Programs use registers for all variables, including all arrays. Since they are indirectly addressible, they have pointers. Programs never access burst-mode memory at all. The pages of CPU registers are self-relocating, so that programs see a contiguous empty address space of registers.

bewing wrote:The CPUs are built to have millions of on-chip indirectly addressible registers, arranged in pages. Some pages are active, and other pages are inactive (where they can be flushed and loaded to/from burst-mode memory asynchronously). Programs use registers for all variables, including all arrays. Since they are indirectly addressible, they have pointers. Programs never access burst-mode memory at all. The pages of CPU registers are self-relocating, so that programs see a contiguous empty address space of registers.

In the above post, do s/registers/memory/, s/pages/lines/ and s/burst-mode memory/SDRAM/. Sound familiar? You just reinvented caches.

The number of tractable CPU registers is capped at somewhere in the region of 256 (this is probably on the high side, but Itanium manages it). Even at that size you're putting real pressure on the size of the architectural register file, and this is going to cause hell for your register renaming engine. You've probably also reached the point where your physical register file is smaller than your architectural register set, so you end up with disjoint fast physical register file (used by the register renamer) and a slower architectural register file (used by registers which have 'fallen out of' the renamer). If you go much above 256 registers, you've probably reached the point where your actual register file is significantly capped on its port count in similar ways to an L1 cache today - e.g. one read/write port for the CPU, one read/write port for the coherency, speculative fetch and eviction side of things (and, really, thats what your "asynchronous loads to/from burst-mode memory")

So, lets reinsert traditional registers so this whole thing has some possibility of acceptable performance. You've essentially ended up with a system which behaves like a modern PC, except without cache coherency. You can get this today; for example, take any ARM multicore chip, and mark all of your memory as "cached non-coherent".

I disagree, of course. The devils and angels are in the details, and you are missing the details.

My dream cpu (gaming oriented):

- 32-bit RISC architecture
- customizable microdes
- quad-core
- memory mapped io
- graphics and audio processing locked to cores
- hardware multithreading (so cores don't have to be identical, allowing each of them to be more task oriented; inter-process communication is simpler; resources only have to be loaded once)
- 8MB cache


My dream cpu (pc oriented) is pretty much the same, except it'd be 64-bit, have hardware multiprocessing instead of multithreading, and have a 64MB cache. Looking at my list, I kinda realize why I'm so attracted to PSP programming now...

Additionally, I'm a bit of a fan of bank-switching, it's so much simpler than page tables

A specific instruction type I'd like to see is something like x86 movs with adjustable spacing and directionality on either end of the transfer.

The thing that inspired this was printing strings in text mode on PCs. You generally want to store your strings as a simple sequence of printable characters, but video memory alternates character and attribute bytes. On that account, it would be nice to have something like "movsb 1:2" that moves a string at ds:si + 0,1,2,3,... to es:di + 0,2,4,6,...

Of course, text mode just a wee bit old-fashioned, and doesn't need to be done the way the PC does it anyways, but there are probably other situations where something like "movsb 1:2" would be useful.

Another nice thing to have would be something like movsb 1:-1, which copies a string backwards (ds:si + 0,1,2,3,... -> es:di - 0,1,2,3,...).

FYI.. Transmeta had a 256 bit version of the Crusoe called the Efficieon. It apparently fixed up a bunch of the drawbacks and upped the clock speed to 1.6Ghz which would have made it probably similar to a 1Ghz Pentium M or so. I have a Lifebook P1120 I have XP, Haiku and Gentoo on it runs at 800Mhz and that is rouchly as fast as a PII at 400Mhz depending on the task and how long it runs etc (the hit from the code morphing software goes down for longer runs)

Personally I would like a 32 bit Sparc with PCI express ,SATA, and a wide memory bus. Most of the ARM processors these days are probably ram bandwidth limited especually as they share with thier GPUs. So basically an ASIC Leon4 with a PCI-e bus and integrated SATA lol... and I wouldn't want to pay $5k for it either more like $50 at most for the chip which probably isn't going to happen but also isn't unreasonable if they manufactured enough of them.

Clearly the ideal processor is one that will be able to resolve endless arguments on the forums.

I'm not sure that's computable, however.

Owen wrote:Careful there. The definition of the hardware in an "x86 PC" is getting looser; for example, under EFI, hardware text mode is dead.

I have several PCs with EFI, and all of them still have text mode. At least you can achieve text mode by writing to 0xB8000. If it is hardware based or not is not important, as long as it works the same way from a software perspective. VBE is also still supported on new PCes, although some have faulty implementations.

Owen wrote:Actually, we are rapidly heading towards a stage (thanks to EFI and ACPI) where the only defined hardware in a PC will be the CPU and architecturally defined hardware (e.g. the IO APICs, HPET). Everything else is rapidly going. Keyboard controller? Gone (even on some BIOS machines!). PIC? Also gone.

Not really. I have a brand-new PC that still has the legacy keyboard connector, and the keyboard-controller seems to work as expected (at least from a software perspective). What I've noticed on several PCs is that the mouse connector doesn't work. The migration from PIC to APIC has gone further, but OTOH you need APIC mode in order to do SMP so that's not a big problem. The legacy PIT also seems to work on most new PCs.

So I think the legacy-free PC is not here yet. Most PCs sold today are not legacy-free.

rdos wrote:

Owen wrote:Careful there. The definition of the hardware in an "x86 PC" is getting looser; for example, under EFI, hardware text mode is dead.

I have several PCs with EFI, and all of them still have text mode. At least you can achieve text mode by writing to 0xB8000. If it is hardware based or not is not important, as long as it works the same way from a software perspective. VBE is also still supported on new PCes, although some have faulty implementations.

When booted from EFI, one can't assume that the graphics card, assuming it is a VGA compatible controller (likely, but I expect increasingly unlikely in the future) is in text mode - or is even in a legacy mode which can in any way be configured without a dedicated graphics driver

rdos wrote:

Owen wrote:Actually, we are rapidly heading towards a stage (thanks to EFI and ACPI) where the only defined hardware in a PC will be the CPU and architecturally defined hardware (e.g. the IO APICs, HPET). Everything else is rapidly going. Keyboard controller? Gone (even on some BIOS machines!). PIC? Also gone.

Not really. I have a brand-new PC that still has the legacy keyboard connector, and the keyboard-controller seems to work as expected (at least from a software perspective). What I've noticed on several PCs is that the mouse connector doesn't work. The migration from PIC to APIC has gone further, but OTOH you need APIC mode in order to do SMP so that's not a big problem. The legacy PIT also seems to work on most new PCs.

So I think the legacy-free PC is not here yet. Most PCs sold today are not legacy-free.

Most aren't. Expect Windows 8 to change this, being as it is mandating UEFI anyway. Some machines being sold, however, already are legacy free; and you have been able to buy mostly legacy free machines since 2005