Processor Independent Operating System (PIOS) Information
Mon, 17 Oct 1994 16:16:55 -0700 (PDT)
By: Mike Prince
FAX: (415) 948-2172
Processor Independent Operating System (PIOS) Preliminary Information
Thank you for showing interest in the PIOS project. The following
document will provide direction during this start-up period. I hope after
reading this document that you are as excited as I am about the PIOS
microkernel. It will provide a foundation for future research into
operating systems, and allow for the development of new and exciting
Contents of this document
1. How to Participate
2. Battle Cry!
3. Mission Statement
4. Design Ideas
5. Preliminary Architecture
8. Points for Discussion
1. How To Participate
First read this document. None of the ideas set forth are cast in stone. I
am versatile, and will do what I can to make sure this idea gets off the
If you are interested in the project, but at this time are not able to
contribute, e-mail a message stating so, and I will keep you on the
mailing list. We would be more than happy to hear your opinions, and
exchange ideas with you.
If you have decided to join, please read the points for discussion.
Then e-mail me your positions on those points and comments. Please also
include a brief description of yourself, which I will compile into
a contributor profile to be distributed to all. This description should
include education, relevant projects, papers, etc, and small section about
Also include the level of participation you would desire and which aspect
of the project you interested in (an estimation of the number of hours
each week you would like to contribute would be helpful).
Last of all, (I hate to have to do this), please list three references,
with one being a professional or academic staff member.
Please send these by October 23rd. My e-mail address is firstname.lastname@example.org.
I also have a fax line at (415) 948-2172, if that is more convenient,
or if there is information that is on paper you would like to submit.
2. Battle Cry... How to Win
How do you win the OS war? Do not be subserviant. Create a design
that does things the others cannot do, or does what they do, but better,
faster, and easier. Layer your operating system ON TOP OF theirs for the
mean time. For that matter, layer it on top of everything that is out
there. You can not win from the bottom, you must battle from the top!
Exploit the fact that your OS can service the growing distributed
networking scene better than theirs. Write a killer app.
Exploit the fact that your OS can make the computer run faster for
less. Plug that card with 8 of the newest processors available
into that empty slot in your PC-XT. Watch all the software written
for your OS immediately run 100 times faster, while their software
doesn't even know whats going on. Tell that to all the Fortune-1000
companies, which every two years has to upgrade their systems.
Exploit the fact that your OS is a technological masterpiece. Write a course
guide and give the software to every university with a computer. Professors
love teaching the newest stuff, just give them the resources. Within
three years you will have a force of enthusiastic programmers.
Exploit that size of your microkernel, most computers out there are hidden
in microwaves and cellular telephones. Compete for the position to connect
all of them together. NT and beepers do not mix. Despite pagers abundance,
they are ignored. And here come the set-top boxes and ISDN interfaces...
Exploit the fact that the market is still fragmented. Your OS, running on
top everything, is great glue, but do not get sucked in to supporting
backwards technologies. When the time comes, your OS will slide towards
the hardware, supplanting everything in its path.
Battle from on top of their OS, not from below! You can win with
technological merit and marketing genius, you do not need marketing bucks or
huge R&D budgets.
3. Mission Statement
We are here to design a microkernel based operating system to serve
as the basis for the next generation of higher-level operating systems
and consumer electronics. The OS is to be able to optimize the use of
computing resources by re-distributing the computional burder of applications,
during execution, over a dynamic, heterogenous, wide area network. It
should execute on the largest range of platforms possible, from household
appliances to supercomputers. The OS will be the common denominator of all
systems. No backward compatibility will be designed in, so as to allow the
highest degree of design freedom.
4. Design Goals
What follows are some ideas I would like to implement in PIOS.
Process Migration in a Dynamic Heterogenous Environment
A little secret for now, but it can be done.
All commercial OS's are based on the machine-centric paradigm. In this,
an application is based on one computer and does communications with other
applications on the same machine or others. An application is grounded
to the machine it was initially executed on. Due to this prespective
software engineers have had a great deal of latitude in typecasting
their applications and OS's to one platform, thus reducing their portability.
An application-centric OS allows applications, during execution, to be
migrated to different machines. Applications engineers can no longer
assume certain static attributes of their platforms. The environment becomes
a dynamic one. The job of the OS is to allow freedom of the application.
The largest object is the tool box. A tool box is composed of an array of
arbitrarily sized data and code segments and a number of agents. Code
segments are viewed as tools. Data segments are viewed as stacks, however
data within the stacks can also be accessed directly. Agents are the
execution primitives. Agents execute tools, and have access to the global
tool box stacks, plus their own private array of local stacks. Agents can
move from tool box to tool box carrying their local stacks.
Physically, a tool box resides within one working space, and is usually
serviced by one CPU. Normally a working space contains several tool boxes.
Tool Box Migration
At the discretion of the OS a tool box may be migrated to another working
space. At such time all constituent parts of the tool box (tools and global
stacks, resident agents) and bundled up and moved to the new working space.
At the new working space the tool box is unbundled and all tools are either
re-compiled, or are deemed better interpreted for overall system performance.
The intermediate code is retained in case another move is warranted.
Tool boxes can be viewed as resources. Each tool box is named and all
inter-tool box communications are vectored according to that name. Names
may be shared by tool boxes, in the case of libraries for which there may be
instances in several working spaces. All services provided by tool boxes
must, by default, be stateless.
Inter and Intra Tool Box Communications
Agents carry all data in their local stacks. Typically, parameters will
be pushed onto a stack before a call, and popped off during the call.
The actual parameter passing format is up to the application.
All communications (agents) are vectored through a gate upon entry to a
tool box. The entry code can choose to do minimal checking to optimize for
speed, or extensive checking to maximize security. This checking is not
a function of the operating system, but instead of individual tool boxes.
All code is distributed in an intermediate language, below human programming,
but high enough to be applied to a wide range of microprocessors. It will
be simple to interpret, and quick to compile down to binary for speed
intensive applications. It is expected that human-oriented programming
languages will be layed on top of this intermediate language. I would like
to do an implemention of c(++) for the intermediate language. Though
c would not effectively utilize the attributes of the OS, it would satisfy
the short term complaints of those still bound to c.
Automatic Stack Contraction/Expansion
I'm not sure about this one yet. Each stack (tool box or agent)
grows from the bottom, and is used like a stack. It has a profile (
max size, grow/shrink increment, and stack pointer). Data can be pushed/
popped from the stack, or accessed arbitrarily inside the range below the SP.
When the stack overflows, the segment is automatically expanded. When
memory resources in the workspace run low, garbage collection can commence
by contracting stacks that are under utilized (stack top - SP > shrink
increment). I believe this might save space by applications using
only what they need, and by bundling the memory allocation code in the
kernel which might otherwise have many instances in the application code.
What do you think?
For truly speed intensive applications, the actual application code (tool
box) would be bundled with the PIOS microkernel and coded in the native
machine language. The tool box would be tied to the machine to prevent
migration, or an additional copy of the tool box (the intermediate language
version) could be migrated.
Optimization of Resources
Tool boxes should include a benchmark tool, which could be compiled
on a number of different machines to determine which has the best fit
of architecture to problem. This benchmarking can take place just before
initial execution, or during a re-optimzation of resources during execution.
Taking this measure, plus that of available network bandwidth, estimated
communications demands, etc, the tool box could be placed in the most
optimal workspace. Notice that we are entering into the territory of a
priori knowledge of application demands.
No File System?!
I don't believe in file systems (maybe I'll change my mind). In any case,
I'd like for tool boxes to behave like organic systems, going to sleep
on persistent computers when not in use, being brought back to the fast
non-persistent computers when being utilized. What is a persistent computer?
A hard drive with a very dinky CPU could be viewed as a slow slow computer
that is persistent, with a very large memory. Using the same algorithm for
optimizing the distribution of tool boxes, the less used ones would naturally
migrate towards the hard drive based work spaces when not in use. I look
forward to the day when all computers have soft power switches; ask the
computer to turn off, it moves the tool boxes to persistent storage, and then
turns the power supply off.
Design Goals Overview
The migration of processes (tool boxes and agents) during run-time in a
dynamic heterogenous environment
Small minimalistic microkernel (10-20K)
Allow for any level of security, based on applications need
Parallel processing intermediate language
not for human consumption
"HDD as slow persistant computer" storage (instead of file based)
No file system?!
development as an interactive process (FORTH like)
Implement initial design on top of existing OS's.
(distributed file system as improvised network? Or jump straight
in and do a TCP/IP implementation?)
All original coding!! No copies of others work (for legal reasons)
5. Preliminary Architecture
Processor (application, when run on top of an OS) initialization
Creation, Bundling and Unbundling for transport, Destruction of
Interpreter (in kernel for speed)
Compiler (in kernel for security?)
Automatic segment expansion/contraction?
Workspace tool box mapping/redirection
Inter-microkernel packet communications manager
Tool box re-allocation algorithms
Device drivers (HDD,TCP/IP)
High level to intermediate code compiler (gcc?)
Global tool box mapping/redirection
Nearby workspace utilization, access speed, etc statistics
Intermediate code to binary compiler (as resource for versatility?)
Determine preliminary goals of project
Determine structure of organization
Determine participants and roles
Determine development schedule
Finalize PIOS goals
Agree on methods to attain PIOS goals
End of phase I
Creation and distribution of academic materials (specifications, development
tools, sample code, etc...)
Second recruiting of strategic partners
Development of commercial products
Q: What will be the functionality of the microkernel?
A: The microkernel will be a minimalist one, see part 5.
Q: How do you migrate processes in a heterogenous environment?
A: Thats a little secret for now.
Q: What type of implementation are you looking at? You mention an
intermediate language but what? Have you considered using object
A: See part 4 for implementation. The intermediate language would
be a proprietary one. Object oriented technology in programming languages,
for the most part, is for programmers, not for computers (I know
I'll get hell for saying that). This OS is for computers. (More
inflammatory remarks expected...). Object oriented technology, as far as
viewing system components as objects which can talk to each other, is what
we are trying to accomplish, without relying on OO programming principles.
Q: How about the big guys? You can create an absolutely great OS but if you
can't get their software to run on it then you won't sell it.
A: See our battle cry at the beginning...
Q: Have you looked at TAOS?
A: TAOS uses VPcode as an intermediate code. VPcode is tied to a virtual
RISC processor, that for now is easy to compile down to the target machines.
In the future machines will not match VPcode as well (larger register sets,
larger word sizes, etc). Once VPcode is compiled down to a target machine,
that code cannot migrate during execution. That is one of the goals of
8. Points for Discussion
What are our exact goals?
(See goals section.)
What shall be the organization of our group?
I opt for a for-profit business even though we do not have funding
as of yet. If all our work just benefits the research community
then great. But if there could be buck to be made for all of us in
the end, then even better. I'll be pushing for equity distributions
during two phases of the project. These distributions will be
based on the number of hours put into the project, capital invested,
or equipment donated. A $/hour rate for programming (which
likely will be inflated to compensate for the risk) will be arrived
at. Equipment will be valued at the street price. Everything else
we will vote for and agree upon before accepting. The distributions
would be 30% first round distributions/30% second round distributions/
40% myself. The first round distributions would primarily be for
those who donated programming time and any equipment donations we
might get. The second round distributions would be to generate
capital to fund further development.
What will be the structure of our organization? Benevolent dictatorship,
republic, or just where in between? Who will provide direction?
Who will represent us? How should we resolve differences? Etc.
What kind of participants do we need? Where do you fit in? What would you
like to do?
What is a reasonable development schedule? Do we even need one?
(See agenda section.)
Should we widely disseminate our developing technologies (a la Linux), or
should we all sign non-disclosure agreements and keep this a
BIG SECRET? Is there a middle ground?
Start thinking about terminology. We are going to be breaking some new
ground here, and there is an opportunity to coin some new terms.
Most importantly though, we need to agree on the usage of current
and new terminology so we can communicate.