Processor Independent Operating System (PIOS) Information

[Mike Prince]

10/17/94
By: Mike Prince
    mprince@crl.com
    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 
computer applications.

Contents of this document
=========================
1.      How to Participate
2.      Battle Cry!
3.      Mission Statement
4.      Design Ideas
5.      Preliminary Architecture
6.      Agenda
7.      FAQ's
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 
ground.  

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 
you personally.

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 mprince@crl.com.
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.

Application-Centric Paradigm
============================
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.

Logical Configuration
=====================
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.

Physical Configuration
======================
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.

Resource Management
===================
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.

Security
========
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.

Intermediate Language
=====================
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?

Specialized Platforms
=====================
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)
Fast
Application centric
Allow for any level of security, based on applications need
Parallel processing intermediate language
        not for human consumption
Organic System
        "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
============================
Microkernel (10-20K)
        Processor (application, when run on top of an OS) initialization
        MMU functions
        Creation, Bundling and Unbundling for transport, Destruction of
                Agents
                Tool boxes
        Interpreter (in kernel for speed)
        Compiler (in kernel for security?)
        Automatic segment expansion/contraction?
        Workspace tool box mapping/redirection

Tool Boxes
        Inter-microkernel packet communications manager
        Tool box re-allocation algorithms
        Device drivers (HDD,TCP/IP)
        General applications
        High level to intermediate code compiler (gcc?)
        Development tools
        GUI
        Global tool box mapping/redirection
        Nearby workspace utilization, access speed, etc statistics
        Intermediate code to binary compiler (as resource for versatility?)

6.  Agenda
==========
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
PIOS specifications
Coding
Beta testing
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

7.  FAQ's
=========
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 
oriented technology?

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
our project.

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.