OSDev.org

Where did you go to learn basic computer architecture when you started the journey of OS development (besides school)?

I learned ZX Spectrum architecture by reading the associated manual (there was no Internet at that time), fortunately I had a printed version with full hardware schematic and CPU instruction set manual. When you know that little basics, its easier to go forward.

Raspberry Pi, as simple as it is, has not the simplest architecture, since it's a modern machine. But it has some hardware manuals online, and it's always the same hardware so it's easier for start.

Start with a simple older system architecture, understand how it works, then move on to more complex ones.

If you're the book type, there are various books describing how the computer parts are connected, try the books thread here or just amazon for "computer architecture".

HTH

Books, internet. Someone had to pay for and attend CS classes, while the basics were available at the course pages online for anyone to read for free.

Well, I guess I need to learn C and/or Assembly before tackling this theory.

But, my aim for OSDev isn't like very high now. I just want at least something that's a command line. I don't really have a specific reason for my goal other than to just learn or make something cool.

When I was little and more interested in computers than today, I told myself that I was going to make my own OS similar to Windows LOL.

I don't think I'll be able to study any old computer reference manuals without learning the language first.

Hey,

The wiki has an excellent page for the Required Knowledge you are assumed to have: http://wiki.osdev.org/Required_Knowledge

Also, here is a quick guide on how you can get started: http://wiki.osdev.org/Getting_Started

Best,

Lev

You can mix them, get a bit of theory then write some assembly to try it out. I used to do that with Peter Norton's PC book, which described all BIOS and DOS services (it was in the age of real mode, but still - the same idea applies - read about some interesting piece of hardware, go and play with it).



Design-wise it's a wrong approach, because command line in your case is the end of the line - you need to have A LOT of other things working before you will have a properly working command line. And the command line (or "a shell") will be perhaps the simplest part of the whole design.



Manuals are written in English language and you seem to already know it. Assembly language is specific to each CPU architecture, so if you start tinkering with RaspberryPi - you'll have to learn ARM assembly, if you try to play with wifi routers - you'd need to learn MIPS assembly and so on.

However, IF you started with computer architecture first, you'd see that assembly just describes CPU commands which are pretty common and it doesn't matter if it's called MOV, LD/ST or something else.

I did get my hands on the old Apple II reference, is that good? I think so.

If you're looking to write programs for the Apple II, sure. It won't help much for programming a system that uses a different CPU, however; the 6502, an 8-bit CPU designed in 1975, is quite different from the Intel x86 architecture that is used in PCs, even more divergent from the Motorola 68000 used in early Macs and Amigas, and even further still from the ARM architecture used in the Raspberry Pi and the majority of smartphones and tablets.

I am guessing you knew that already, but it is always worth reiterating, as I don't know for sure how familiar you are with systems which are older than the majority of posters here are.

For that matter, it wouldn't help much with other 6502-based systems such as the Commodore 64, the Atari 400 and 800 (the Atari 2600 also used that chip, but the 2600 used it very differently), or the Nintendo Famicom/NES (which, like the Atari 2600, was a cartridge-based console). Most of these systems are seen mainly as emulations today, though plenty of the original hardware units are still around, but they all had very different video, memory, and sound systems from the Apple II, and even later systems in the Apple II line were quite different from the original.

Anyway, that doesn't mean it isn't worth reading; if nothing else, it should be easier to understand some of the descriptions, so reading it now it may help you later when you do look at more recent designs, and you may find it interesting as historical background material (in which case you might want to look up some of the retrocomputing websites, and YouTube channels such as The 8-Bit Guy). However, it will be of little immediate use in understanding the PC or any other design from after the early 1980s.

As a starting point, you could do a lot worse, so I would go for it.

Yep, that's good, it's an old and rather simple 8-bit CPU, should be easy to figure out it's hardware in an evening or so.

As for general textbooks on computer architecture, the best known and most widely used books are Computer Organization and Design: The Hardware/Software Interface and Computer Architecture: A Quantitative Approach, both by David Patterson and John Hennesey. The two books are complementary, with the first being focused mainly on the programming aspects, and the second on the design of the CPU, memory bus, and other hardware. They are used in most computer architecure classes, and while they focus on the MIPS and DLX designs (both of them originally by Patterson and Hennesey themselves, with the DLX being a simplfied version of the MIPS meant for teaching IC design), they do cover other CPU architectures as well.

Now, part of the problem is that they term 'computer architecture' is overloaded, and often used ambiguously. The general term is used to describe the general approach to computation, with the basic architecture of pretty much every modern computer being the Register Machine model. These in turn get divided into types by how they treat program memory into the Von Neumann (data and program in a single address space), Harvard (separate address spaces for data and program, with no ability to modify program code once loaded), and Modified Harvard (shared address space divided into segments or pages, with read-only protection which can be programmatically set) architectures - most modern systems originated from Von Neumann designs, but gradually adopted a hybrid approach and are now Modified Harvard systems.

However, the term is also used to describe the instruction set used by a CPU or family of CPUs, and more often than not, this is how the term gets used here. The Instruction Set Architecture (ISA) of a type of CPU determines how you program them, and whether a program binary image can run on that CPU directly. Today, ISAs generally are grouped into Complex Instruction Set (CISC) and Reduced Instruction Set (RISC) designs (also called load/store designs), with the PC being (from the developers perspective, that is) a CISC design and most of the other current systems being RISC. While one could argue about the issue for days, the biggest difference is usually considered to be whether or not the CPU has any instructions which act directly on main memory other than loading from or saving to a given address, or if the other instructions can only operate on registers (individual pieces of fast memory internal to the CPU).

The reason this matters is mostly related to how memory is accessed, and the speed of memory access versus the speed of register operations; the principle behind Load/Store designs is that it is usually faster to load a piece of data into a register, perform several operations on it, and then save it back to memory, than to perform the operations directly on the memory it is in. There are a lot more issues involved, involving the use of 'microcode' (a sort of hardwired interpreter in the CPU that breaks complex instructions down into simpler ones) and the value of having infrequently used operations in the instructions set (among other things), but that is the most prominent question on that topic.

There is also the memory architecture of the CPU, which is closely tied into the ISA, and the bus architecture of a given type of computer, which can differ even if they have the same type of CPU.

Anyway, most of the time, in this group we are talking about the specific ISA of a type of CPUs used in different kinds of computers and programmable tools such as tablets. This is the part you actually need to know about when writing an OS. The specific bus and peripheral architectures are also important, though mostly in regards to performance and the design of drivers. So, if someone is talking about the "PC architecture", they are usually talking about an x86 ISA and memory architecture (which is derived from the Intel 8086 CPU design of the late 1970s, but which is now something very different, with 32-bit and 64-bit extensions), combined with the PCI Northbridge and Southbridge buses which are distant evolutions of the original IBM PC from 1981.

Don't worry if this doesn't make sense yet, it will probably take some time for you to digest all of this.

Good advice. As I said, just because it doesn't apply to more recent designs directly doesn't mean it won't help you understand those later.

It doesn't really matter to me much about what my target architecture is. What's the reason most on here choose x86, besides that one being the most documented?

Hi,



I'd say that the underlying reason is backward compatibility - it's why documentation has been accumulating over a few decades, it's why there's standards (AHCI, UEFI, etc) instead of dodgy manufacturer datasheets and/or no information, it's why there's existing source code that can be referred to, etc. It's also part of why people choose "80x86 PC" for OS development - they know that if/when they actually finish writing their OS (in 10 years or so) that "PC" will probably still be compatible with their OS (and that they haven't spent years working on software for something that will be obsolete before the OS is ready).

The other reason people choose "80x86 PC" for OS development is pure numbers (market share). For example, it's easy to find/buy/borrow multiple different computers to test your OS on, and most people are using "80x86 PC" to write (and compile/build) their OS anyway.


Cheers,

Brendan

The other part of this is that PC architecture is "open" i.e. you can install your own bootloader and use it for running your own OS (well, lets put secure boot aside for now). The market share of the ARM CPUs is MUCH bigger than PC (tens of billions of devices) but you have absolutely no access to it's boot process and even less access to the documentation for the actual board it's installed on.

Hi,



It's probably not a good idea to compare the market share of a range of incompatible CPUs (that have no "standardised architecture") with the market share of an actual standardised architecture. More sensible would be to compare the market shares of (e.g.) ARM's Server Base System Architecture with "80x86 PC", or Raspberry Pi Foundation's "de-facto Raspberry Pi version 1.0 architecture" with "80x86 PC", or...


Cheers,

Brendan