Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Embedded Systems

The DOORS OS


Using the DOORS OS

If this operating system can be loaded into memory at any location, how do you design programs so that they can call these functions? If these subroutines aren't even a part of your user program (but instead reside only in the HC11's memory), how does the compiler/assembler know where they're located (remember, this OS can be loaded into just about any memory address)?

The simple solution would be to remember where in memory you placed the OS, then hard-code the addresses of the start and stop process functions into user programs. However, this approach presents several problems (What happens if you move the OS to a different memory location?). A better solution—and the one I actually used—is to have the OS keep a "pointer" to itself in memory location $0000 (the start of internal RAM on an HC11). Since this pointer is always in the same exact location, your programs will always be able to look it up.

So upon reset, the DOORS OS stores in address $0000 the address of the subroutine runCommand (in kernel.asm and Listing Four, available at www.ddj.com/code/). This subroutine is the one that the user program calls to access all required OS functions. When run, this subroutine checks to see what value register Y is (this is the only argument required by this function). If it's a 0, then startProcess is run; if it's a 1, then stopProcess is run. Likewise, if it's a 2, the time elapsed since reset is returned, or a 3, then the startProcess command is run with the request for an exact stack copy to be made.

With all this in place, you can see that it is easy to call an OS function. For example, to start a new process (without stack copy), load all internal registers with the needed data (mentioned before and as shown in Listing Five; available online), then store the value 0 in Y to specify that you want to run the startProcess command. This is followed by looking up the memory address that's stored at address $0000 and jumping to that address. runCommand takes it from there! Listing Five is a sample program in assembler that starts two processes.

Using SmallC++

The DOORS OS SDK includes the SmallC directory and readme.txt file with instructions on how to setup the SmallC++ compiler (www.geocities.com/waltsrobots/ smallc.html) to work with the OS. All that's required is to copy a few different files to different locations.

Once you've done this, your C++ programs can access OS features. By including the DoorsOS.h file in your program, you have access to the startProcess(), stopProcess(), getTime(), and fork() functions.

If you're familiar with the UNIX system call fork(), the DOORS OS version is virtually identical. When called, it creates an exact copy of the current process (creating an exact copy of the calling process's stack, which includes variables and return addresses) and returns control to the "parent" (the original calling process), which resumes running for the remainder of its time. Eventually, however, the "child" process (the new process that was created after the call to fork()) will run and resume execution from the same position after the fork() call.

Since both the parent and child processes resume execution from the same exact point (right after the call to fork()), how do you know which is which? Well, the fork() function returns a valid process ID (a value greater than 0) if the current process is the parent. Otherwise, a 0 is returned. Using this return value, a process can know exactly whether or not it's the parent or the new child process. Listing Five (available online) provides an example.

Conclusion

Even though this DOORS OS was originally designed to run on the HC11, there's nothing preventing you from porting the code over to your processor of choice. If you have any questions at all, please to send me an e-mail.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.