sponsored by

OSdata.com

Hardware (Physical) Layer of an Operating System

    The Hardware Level of the operating system controls the use of physical system resources, such as the memory manager, process manager, disk drivers, etc.

• other web pages in this section
• basics of computer hardware
• what are computers used for?
• processor
• arithmetic and logic
• control
• main storage
• external storage
• input/output overview
• input
• output
• processors
• CISC
• RISC
• DSP
• Hybrid
• processes and jobs
• general information
• linking
• loading
• run/execute
• buses
• kinds of buses
• bus standards
• memory
• memory hardware issues
• main storage
• external storage
• basic memory software approaches
• static and dynamic approaches
• absolute addressing
• overlay
• relocatable software
• demand paging and swapping
• program counter relative
• base pointers
• indirection, pointers, and handles
• stack frames
• virtual memory
• OS memory services
• memory maps
• PC-DOS and MS-DOS memory map
• MS-DOS TSR memory map
• Mac Plus memory map
• Mac Plus video memory locations
• Mac Plus sound memory locations
• low memory
• character codes
• assembly language (huge web pages contains detailed information on how processors work)
• intro to assembly language
• data representation and number systems
• registers
• addressing modes
• executable instructions (huge web page with instruction summaries)
• data and address movement
• integer arithmetic
• floating arithmetic
• binary coded decimal (BCD) arithmetic
• advanced math
• data conversion
• logical
• shift and rotate
• bit manipulation
• string and character
• table operations
• high level language support
• program control and condition codes
• input/output
• system control
• coprocessor and multiprocessor
• trap generating
• on this web page
• kernels
• number of bits
• multiprocessing
• multitasking

    This layer of an operating system is often called the kernel. The exact boundaries of what constitutes the kernel varies by OS and often includes portions of the Logical Layer.

kernels in use

     BSD: FreeBSD^e104, ULTRIXe100

     MACH: Digital UNIX^e45, Mac OS X^e75, Mac OS X Server^e75, MkLinux (PowerPC, Intel, and HP/PA)^e75, NeXT (2.5)^e44, Rhapsody^e75

     LINUX: LINUX^e61

     Proprietary: (NOTE: Each would be a different proprietary kernel) AmigaOS, BeOS, IRIX^e46, Macintosh, MVS, NetWare, OpenVMS, OS/2, Pyramid^e97, Windows

kernels by operating system

    Digital UNIX: Mach 2.5-based implementation of BSD 4.x^e45

     FreeBSD: BSD 4.4 + enhancements^e104

     IRIX: Proprietary. “SGI has put a lot of work into IRIX; it isn’t just someone else’s kernel with some bundled software on top. It also predates MACH or any other open unix standard by a number of years.” — Walter Roberson^e46

     LINUX: LINUX. “The Linux kernel was originally written by Linus Torvalds (hence the name “Linux”), and it maintained by a team of developers. The kernel itself is released under the GPL (GNU Public License).” —Rich Steiner^e61 (See also: http://www.linuxhq.org

     Mac OS X: Mach^e75

    Mac OS X Server: Mach^e75

     NeXT: Mach 2.5-based implementation of BSD 4.x^e44

    Netware: Proprietary.^e97

     Rhapsody: Mach 2.5 (with custom enhancements)^e75

number of bits

    One area of operating system support is how many bits of address and data space it can deal with. Early microprocessors were typically four or eight bits, while early mainframes and minicomputers were typically eight or twelve bits. Modern mainframes and microcomputers are typically either 32 or 64 bits.

    The biggest advantage of more bits is a larger addressable space, both more RAM and larger disk (or other) storage space.

    The bit-ness of an operating system or even of application programs can greatly exceed that of the underlying hardware. Classic examples include multi-precision mathematics in science and engineering and large data space in graphics software.

    The bit-ness of the hardware can exceed that of the operating system or application programs. This is generally not a problem. It can lead to inefficiencies in operand fetches or writes and in allocation of data storage space, although this is not normally the case as hardware generally keeps smaller bitsize operations in the instruction set.

    A related situation is the running of old legacy software on modern hardware. This can lead to inefficiencies in both allocation of space and in fetch and write of operands. The typical solution is for an operating system to provide an environment for legacy software that recreates the expectations of the older software.

    In general, the more bits an operating system can handle, the more ready it is for the upcoming demands of truely large graphics and database operations, as well as being able to smoothly scale many everyday processes to the size needed for a large scale operation (such as web servers handling huge amounts of traffic). Most modern operating systems are in the process of the changeover to 64-bit hardware.

     “Digital UNIX continues to dominate the 64-bit arena, leaving HP-UX and IRIX to contest the second position, followed closely by AIX. Solaris and NT trail significantly behind. Digital benefits not only from strong software support for 64-bits, now being matched by other players, but also from top-to-bottom 64-bit hardware support and a lack of the minor compatibility tradeoffs required by other vendors’ solutions. AIX offers good backwards compatibility for 32-bit applications and a few other compatibility bonuses. However, IBM has lagged behind its competitors in providing 64-bit hardware, shipping its first 64-bit server only now. HP scores slightly better, having progressed about halfway through its hardware transition to 64-bits, also offering good backwards compatibility for 32-bit applications. IRIX has transitioned its hardware line completely to 64-bit technology, but lags in the area of 64-bit standards conformance, without support for the predecessor of the 64-bit UNIX98 standard, UNIX95. Solaris is the sole UNIX operating system that does not yet provide support for 64-bit processes, so it falls somewhat further behind and potential compatibility issues remain largely unknown. Still, Sun has migrated over half its product line to 64-bit hardware, and provides support for large amounts of physical memory, both of which are still missing from NT. NT runs on 64-bit Alpha hardware and offers 64-bit files and file systems but has yet to address the key 64-bit requirement to support large amounts of physical memory for enhancing database performance.” —D.H. Brown Associates^w43†

    64-bit OSs: BeOS, Digital UNIX, HP-UX, IRIX, LINUX (depending on the processor used)^w90, Mac OS X, Mac OS X Server, NetBSD^e113, OpenVMS (on Alpha) ^e111, Solaris^e107, Sun-OS^e107

    32-bit OSs: Amiga^e95, FreeBSD, LINUX (depending on the processor used)^w90, Macintosh, NeXT, OpenVMS (on VAX) ^e111, OS/2, Pyramid^e97, Rhapsody, Solaris, ULTRIX, Windows 95, Windows 98, Windows NT, Windows NT Server, Windows NT Server Enterprise Edition

    24-bit OSs: Windows 3.1

    16-bit OSs: MS-DOS

multiprocessing

    Some operating systems can support more than one processor in a single machine. This is called multiprocessing.

    “Writing an efficient, scalable mp kernel is not an easy task.” —Orphy^e74

number of processors supported:

     IRIX: 128 processors^w34

     HP-UX: 128 processors^e121

     Solaris: 64 processors^e64

     SUN-OS: 64 processors^e64

     OS/2: 64 processors^e122

     OpenVMS: 32 processors^e120

     Mac OS X: 32 processors^e125

     Rhapsody: 32 processors^e125

     AIX: 24 processors (in the S80 model )^e112

    Pyramid: 24 processors^e65

     BeOS: 8 processors^e82

     Windows 2000 Advanced Server: 8 processors^w50

    ULTRIX: 6 processors (in some models of VAX 6000)^e100

     FreeBSD : 4 processors (Intel SMP)^e104

     Macintosh : 4 processors^e114

     Windows 2000 Server: 4 processors^w50

     Windows NT: 4 processors —Jim Carr, MicroTimes; Oct 30, 1998^m1

     Windows 2000 Professional: 2 processors^w50

     Amiga: 2 (one 68060 and one PowerPC)^e95

     NetBSD: 1^e113

     NeXT: 1^e132 “Max. Processors was 1 on all architectures. Rhapsody and OPENSTEP will work on some multiple CPU Intel systems, but will only use the first CPU.“—Graham J Lee^e132

    MS-DOS: 1

    It’s going to take me a while to get all of the operating systems charted and footnoted. Please be patient. Thanks.

multitasking

     OS/2 Warp: “real multitasking for greater productivity”^w27

related web sites

    http://www.dhbrown.com/cfeprise/page_int.cfm?OBJECTID=131&Method=VIEW “Operating System Scorecard — 64 bits — D.H. Brown Associates”

geek humor

    “That kernel’s got a mean streak a MILE WIDE!!” —Chip Salzenberg

    A web site on dozens of operating systems simply can’t be maintained by one person. This is a cooperative effort. If you spot an error in fact, grammar, syntax, or spelling, or a broken link, or have additional information, commentary, or constructive criticism, please e-mail Milo. If you have any extra copies of docs, manuals, or other materials that can assist in accuracy and completeness, please send them to Milo, PO Box 1361, Tustin, CA, USA, 92781.

    Click here for our privacy policy.

Return to Scalability

previous page	next page

home page

one level up

system components

peer level

• Internet Services
• Logical Level of Operating System
• Graphics Engine
• User Interface
• System Services
• Command Shell
• System Utilities
• Programs

one level down

• basics of computer hardware
• processors
• processes or jobs
• buses
• memory
• memory maps
• low memory
• character codes

    This web site handcrafted on Macintosh computers using Tom Bender’s Tex-Edit Plus and served using FreeBSD .

    †UNIX used as a generic term unless specifically used as a trademark (such as in the phrase “UNIX certified”). UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd.

    Copyright © 1998, 1999, 2000, 2001, 2004, 2006 Milo

    Last Updated: September 11, 2006

    Created: June 4, 1998

Return to Scalability

previous page	next page