[ale] OT fyi interesting historical info on memory management

[Ron Frazier (ALE)]

On 6/29/2013 11:04 AM, Michael B. Trausch wrote:
> 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
>
>

Hi Mike T,

The info you shared is very interesting.  I'll bet you're one of a small 
number of people on the list that understands these esoteric processor 
modes.  I programmed 6502 assembly language back in the dark ages (1985) 
when I was getting my BS-EET degree.  We built the equivalent of a 
microwave oven controller with hex keyboard and display.  I think I had 
60 pages of flow charts of little modules.  I'm sure we had a few 
interrupt handlers in there.

Based on what you've said, I think I'll stick to programming the PC in a 
higher level language for now.  Maybe, when I have lots of time to kill 
(ha ha), I'll jump into assembly just for kicks.

Sincerely,

Ron


-- 

(PS - If you email me and don't get a quick response, you might want to
call on the phone.  I get about 300 emails per day from alternate energy
mailing lists and such.  I don't always see new email messages very quickly.)

Ron Frazier
770-205-9422 (O)   Leave a message.
linuxdude AT techstarship.com
Litecoin: LZzAJu9rZEWzALxDhAHnWLRvybVAVgwTh3
Bitcoin: 15s3aLVsxm8EuQvT8gUDw3RWqvuY9hPGUU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130629/429bf5d8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1701 bytes
Desc: not available
URL: <http://mail.ale.org/pipermail/ale/attachments/20130629/429bf5d8/attachment-0001.png>