<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 6/29/2013 11:04 AM, Michael B. Trausch wrote:
<blockquote cite="mid:51CEF761.40802@naunetcorp.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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 moz-do-not-send="true"
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:part1.09020208.06090206@techstarship.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>
<br>
</blockquote>
<br>
Hi Mike T,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Sincerely,<br>
<br>
Ron<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
(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
</pre>
</body>
</html>