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.

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

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:

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.

Bit addressable memory.

Unfinished. More details to be added.


Revised 2005-01-25