Part 1: Introduction




Overview

To begin your initiation into the world of operating system coding.







This section in especial is a supplement to the SigOps Introduction. Read it if you read nothing else from that set of tutorials.

Working with SPARC processors is of course a bit different than an i386 processor; however, you gain a few advantages:

  • No real mode v. protected mode. The machine only has one mode, and it can address all of its physical memory, to boot!
  • Functions in the PROM to write to the screen, determine your physical memory configuration, and figure out what kind of devices are attached to your workstation.
  • A Forth interpreter in PROM. Well, I think it's cool.
  • Debugging features in the PROM. The PROM even installs trap handlers during boot so that if a trap occurs, it will tell you the type and drop to the monitor, instead of just rebooting like its Intel counterpart.
Needless to say, the boot PROM in SPARCstations is rather cool. This attribute prompted the comment in the Linux source "The PROM is the computer."

Unfortunately, SPARC processors provide some interesting challenges when compared to i386 machines:

  • Noncontiguous physical memory. Unless your workstation has its maximum amount of memory, there will be gaps in the memory space. Even if you do have the maximum, don't depend on it, since you won't run on other machines then. Details of dealing with this obstacle will come later since its not important yet, as you have at least four megabytes at 0x0, which is enough to get started.
  • Load-store architecture. The only way you can access memory is through load or store instructions. This should not be too much of a concern though, since you won't be writing much assembly.
  • Register windows.
  • Branch delay slots. When the processor executes a call, branch, or jump instruction, the instruction after the call, branch, or jump always gets executed, regardless of whether the branch is taken.
  • No hardware-based context switching. You have to manage saving state, switching stacks, address spaces, etc. and make sure it all gets done in the right order.

Now, let me give you a bit of advice. If you want to have your operating system running on multiple architectures from the same codebase, decide that now because you will have to abstract the hardware a bit to do so. If you don't plan for a multiplatform codebase now, porting down the line will be difficult at best to impossible at worse without a complete rewrite. Trust me. I've rewritten my operating system thrice. The last was because of this problem.

Writing an Operating System for SPARC-Based Computers is Copyright © 1998 by Sidney Cammeresi in its entirety. All rights reserved.

Permission is granted to make verbatim copies of this tutorial for non-commercial use provided this notice remains intact on all copies.