[ale] OT fyi interesting historical info on memory management

[Michael B. Trausch]

On 06/27/2013 03:15 PM, Ron Frazier (ALE) wrote:
> Nevertheless, putting an OS, multi tasking hdd diagnostic, and Windows app in 170 KB is pretty impressive to me.

Check out BDOS (SF.net link <http://sourceforge.net/projects/bdos/>) for
a very tiny educational operating system written in x86 assembler.

Assembly language isn't hard, actually.  It is /quite/ simple.  However,
the problem is that the building blocks are literally so simple that it
takes a long time to---properly---write many different types of
functionality.  Often, assembler programmers use macros to be able to
"compress" common in-line stanzas into a single line that looks like a
special-purpose instruction call.  (Of course, this can be more
difficult to read, if you aren't quite familiar with the instruction set
of the system and the assembler's representation in the source...)

The other problem is that when you write an operating system for a
system like the PC, which is a rather complex machine, you have to be
aware of various things that you never would when working with
application level code:

 1. On the x86, before you can enter 32-bit protected mode, you must set
    up a number of data structures in the system's RAM, and point the
    CPU to them. These do things like allow the CPU's MMU hardware to
    enforce permissions on RAM, as well as be able to use virtual memory
    spaces and install handlers for interrupts (you need those to be
    able to interact with just about everything, including the keyboard
    and storage devices).  Of course, any interrupt that fires that you
    don't have a driver installed for will simply go ignored.
 2. Before you can enter unreal mode on the x86, you have to run through
    protected mode real quick to get the address space configured and
    available for use.  Unreal mode is not commonly used, though it can
    be useful when you have to interact with the BIOS firmware's API for
    maximum system compatibility.  (Just keep in mind that while
    internally, yes, most modern BIOS firmware uses unreal mode for its
    POST process, the API that BIOS exposes to the operating system
    usually does not allow the use of unreal mode addressing. 
    Therefore, when communicating with BIOS, values must "bounce"
    through conventional RAM before being used as parameters to the
    BIOS.  This incurs some overhead, and it is often simply better to
    port the application to run on Linux as /sbin/init.)
 3. On the x86-64 platform, it's a little different: Now, you can put
    the CPU in 64-bit native mode (called "long mode"), which is simpler
    than the legacy 32-bit protected mode.  It is also leaner: 16-bit
    code can no longer be run by the CPU when it is in this mode. 
    Additionally, some firmware actually runs 64-bit native code---but
    in order for the overall platform to remain backwards compatible
    with 1970s standards, the CPU is put back into real mode just before
    loading the boot sector.  Bah.  Anyway, you get more registers, a
    few less rules, and way larger address space and instructions that
    can work with more and larger data.  Win/win.  (Really
    forward-looking systems have a new ABI, BTW, which runs the CPU in
    64-bit long mode, while applications run in 32-bit "Compatibility
    Mode", often lowering RAM and disk footprints significantly for a
    large distribution.)

Anyway, assembly language is simple.

Programming directly on top of the system, though, is not.  All that
stuff that even C handles for you automatically, well, you have to do
it.  By hand.  :-)

    --- Mike

-- 
Naunet Corporation Logo 	Michael B. Trausch

President, *Naunet Corporation*
? (678) 287-0693 x130 or (888) 494-5810 x130

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130629/54a71dd2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ceadfeae.png
Type: image/png
Size: 1701 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20130629/54a71dd2/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mail.ale.org/pipermail/ale/attachments/20130629/54a71dd2/attachment.sig>