Frank T. Clark
Software Systems Design Engineer
/Home
/Professional
/Papers
/Exbi
www.FrankTClark.us
XB (Exbi) The Exbibit Nanoputer
The contents of this paper are preliminary and under development.
In about the year 1999, after almost 30 years of programming computers and writing computer software, I began to get sick and tired of all the problems in developing computer software. I started with programmable calculators and IBM mainframes in 1971. Microcomputers were a breath of fresh air in 1981 but over the years they degenerated into the same complexities and problems. Then they got worse! I began to daydream about just what it would take to make things work better.
Introduction
The Exbibit Nanoputer is the name I have given to a
concept I have been thinking about for a new paradigm
in computers.
Just as the microcomputer followed the minicomputer
which followed the mainframe, there needs to be a new
concept.
The microcomputer has now become just as complex as the old mainframe used to be.
The costs, problems, and errors associated with software development have skyrocketed
while the cost of hardware has plummeted.
We are near the day when there will be a total
reversal of the old status where you bought a machine
and the software came with it for free.
Soon (if not already in some cases) you will buy an application software package and the computer comes
for free.
My apologies to Richard Stallman
and the Free Software Foundation
but I think they are wrong.
The computing industry is in grave trouble, because development and
maintenance costs are soaring and the public at large is getting
disillusioned with its products.
Edsger Wybe Dijkstra EWD920-0 1985-05-01
Notice the date.
It hasn't gotten any better has it.
The new software behemoth (Microsoft) has replaced the old hardware behemoth (IBM) and
there has to be a better way to do things.
There must be some way to radically simplify the development of software (and hardware).
It used to be (still is?) that software programming was used to overcome hardware limitations.
It is time for the hardware to take care of itself and
even take over some software tasks.
When I look at the current state of computing I am saddened by the program crashes, system crashes, viruses, spam, trojans, and all that ilk.
The one concept from mainframes that didn't make it to
the microcomputer is security and reliability.
I have spent a lot of time pondering just what the
next generation ought to look like.
These are some of my ideas.
The name exbibit is derived from the planned 2 to the 60th power bit local address space.
The term nanoputer takes the next division from micro which corresponds nicely to the current typical
nanosecond cycle time of a 1Ghz processor and combines it with a shortened form of computer.
It also reminds me of the greeting of Mork from Ork.
I confess that I did not make the word puter up.
That is what my children when they were young and now
my grandchildren have always called the computer.
Principles
There are three primary principles which must be the foundation of the twenty-first century computer,
the nanoputer.
Reliability
The nanoputer must be a device you can trust to just
work.
It has to be as dependable and easy to use as electricity.
Security
The most important aspect of reliability is security.
If you can't trust a device you can't make full use of it.
The device must not allow any harm, damage, or abuse to the information with which it is entrusted.
Simplicity
Simplicity is a virtue unto itself.
The most important method I can think of to achieve the first two principles is simplicity.
Simplicity is prerequisite for reliability.
Edsger Wybe Dijkstra EWD498 1975-06-18
Simplicity also holds the key to massive cost reduction.
Changing all the legacy tools developed for the Windows/Intel cartel will not be cheap.
The replacement must be as cost effective as possible.
Exbibit Nanobus
You can't just change the software or the operating system, or the processor.
You can't fully achieve the goals without changing the bus. The exbibit nanobus must be scalable from the simplest imlementation to the largest you can imagine. It must be advanced enough to handle all internal device interface needs.
The nanobus must have a hot plug interface to a standard
module design.
The data bus and interface must be completely electrically isolated.
The obvious solution is optical fiber.
Each module initializes to a default ready state just by being plugged into the nanobus .
The mechanical procedure to unplug must automatically
notify the nanobus and shut down.
The nanobus is semi-intelligent and maintains type and status of all modules.
The nanobus handles cross notification of module plug and unplug to other modules that need notification.
The nanobus itself will probably be implemented with an exbibit nanoprocessor.
Exbibit Nanoprocessor
These are some of the core concepts and characteristics of the exbibit nanoprocessor.
- "C" assembly language.
- 64 bit fixed length instruction.
- 128 bit native data type.
- Data typed memory addresses.
- Bit addressable memory.
- Exbibit address space.
- 32 bit process memory addressing.
- 64 bit module memory addressing.
- 96 bit bus memory addressing.
- 128 bit fixed length bus instructions.
- I/O addressed as memory.
- Modular harware designs.
- Hot plug in multiprocessor support.
- Hot plug in memory support.
- Hot plug in storage support.
- Interrupt free hardware interfacing.
- Hardware multitasking.
- Hardware global object directory memory address translation.
- Hardware memory access synchronization.
- Hardware memory management.
- Flexible memory addressing.
I am not an expert in all the fields that these concepts cover so excuse any naivete.
These are clean slate, blue sky, zero based concepts.
"C" assembly language.
The first and most basic concept I suggest is that we adopt a minimal version of "C"
as the native assembly language of the processor.
All basic "C" expressions are one machine instruction.
All "C" expressions can be composed of multiple basic "C" expressions.
There will be an assembler which translates basic "C" expressions to machine instructions.
The assembler will be fully structured deprecating the use of goto.
Only the machine language instructions should use the goto.
The full "C" compiler will translate complex expressions to basic expressions.
The definition of basic instructions is broken down into two categories:
- Computational instructions
- Control instructions
Computational instructions
The computational instructions take the basic form:
{*}a{[]} {+, -, *, /, &, |, ^, %, >>, <<, ~}= {*}b{[]};
Unfinished. More details to be added.
Control instructions
The control instructions take the basic form:
if (0 {<, <=, ==, !=, >=, >} {*}a{[]}) goto {*}b;
Unfinished. More details to be added.
64 and 128 bit native data types.
The processor supports: unsigned/signed integer arithmetic on a 64 bit value.
Unsigned integer arithmetic on a 128 bit value.
Signed floating point arithmetic on a 128 bit value.
This removes almost any need for decimal arithmetic for accurate large numbers and
allows some floating point to be replaced with integer arithmetic.
64 bit fixed length instruction.
The machine code for our "C" assembly language is a 64 bit fixed length instruction.
The basic instruction is composed of a 32 bit address and a function code.
Unfinished. More details to be added.
Data typed memory addresses.
All addresses are data typed.
This means that the address itself specifies the data type it references.
Careful analysis and consideration has led me to the conclusion that bit order should start with the high order bit.
Bit 0 is set to indicate a signed value.
The bits 1 - 3 are a code indicating the data type:
- 0 = 1 bit (bit)
- 1 = 2 bits (dbit)
- 2 = 4 bits (qbit)
- 3 = 8 bits (byte) (char)
- 4 = 16 bits (dbyte) (short)
- 5 = 32 bits (word) (int)
- 6 = 64 bits (dword) (long)
- 7 = 128 bits (qword) (float)
Unfinished. More details to be added.
Memory task partitioning.
Every task has its own 32 bit address space.
It is physically impossible for a task to directly address memory outside of its own address space.
The upper 32 bits of the address are the task number.
Task 0 is a priviledged task.
This is the only task allowed to address all memory.
Memory segment partitioning.
The top 4 bits of the address space are a code to the memory usage.
Code and data never mix.
It is impossible for the code to be corrupted by any instruction the task can execute.
- 0 = Code
- 1 = Code
- 2 = Code Stack
- 3 = Code Gate
- 4 = Data
- 5 = Data
- 6 = Data Stack
- 7 = Data Gate
Bit addressable memory.
Unfinished. More details to be added.
Revised 2005-01-25