<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 06/27/2013 03:15 PM, Ron Frazier
(ALE) wrote:<br>
</div>
<blockquote
cite="mid:f067bff3-451b-4833-8c4d-5d76c5a3d3ab@email.android.com"
type="cite">
<pre wrap="">Nevertheless, putting an OS, multi tasking hdd diagnostic, and Windows app in 170 KB is pretty impressive to me.</pre>
</blockquote>
<br>
Check out BDOS (<a href="http://sourceforge.net/projects/bdos/">SF.net
link</a>) for a very tiny educational operating system written in
x86 assembler.<br>
<br>
Assembly language isn't hard, actually. It is <i>quite</i>
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...)<br>
<br>
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:<br>
<ol>
<li>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.<br>
</li>
<li>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.)</li>
<li>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.)</li>
</ol>
<p>Anyway, assembly language is simple.<br>
</p>
<p>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. :-)<br>
</p>
<p> — Mike<br>
</p>
<div class="moz-signature">-- <br>
<table border="0">
<tbody>
<tr>
<td> <img src="cid:part2.03060306.07010300@naunetcorp.com"
alt="Naunet Corporation Logo"> </td>
<td> Michael B. Trausch<br>
<br>
President, <strong>Naunet Corporation</strong><br>
☎ (678) 287-0693 x130 or (888) 494-5810 x130<br>
<br>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>