1. Home
  2. Electronics Design
  3. (Software Driven) Transputer.

(Software Driven) Transputer.

Hello,

Here is an idea for futher exploration, it may become the future of computing in the far future, but perhaps it has some merit today.

The "Software Driven" transputer is the most purest form of computing possible.

The word transputer in this case is not derived from "transistor" and "computer" but more from "transition" and "computing", which is kinda the same.

Though transistor does seem to have "transition" in it ;)

The "software driven" transputer could be something like this:

It is basically an input/output system. X ammount of input bits can be given which can lead to Y ammount of output bits.

Most if not nearly all transistors on the "software driven" transputer would be allocated to holding "transition tables".

For starts the sixteen two inputs and one output tables can be stored in the transputer.

I1 I2 O1

0 0 0 1 0 1 0 1 1 0 0 0

Above is for example the xor transition table.

The idea is to make it possible for larger transition tables to be stored inside the transputer.

So it can store for example a transition table for 5 input bits and 3 output bits.

The size of these transition tables increase rapidly as the number of input and/or output bits grow.

The interesting thing though is that these transition tables are "software". Thus many different transition tables can be tried.

Which would allow many weird/strange computations to take place... perhaps it might also be interesting for printing/weaving purposes and parallel computers.

However currently not enough transistors would be available to make 32 input bits and 32 output bits a reality. So to compensate for the lack of transistors there would also need to be:

input data path A input data path B output data path C

perhaps even one more for kicks and extra power/flexibility: output data patch D

Perhaps these input and output paths would need to be configureable... not sure about that.

Perhaps there would also be a need to specify how these bits flow through the transition tables which are available to actually do computations/transitions, step-wise (multi cycle wise).

The hope with this design is that 32 bit and 64 bit instructions that we have today can be simulated with lookup/transition tables and some code or data flow like approaches to compute these operations in parts.

What could be an advantage of such a transputer ?

Well for starters it might be possible to mimic every possible instruction set and thus be fully compatible with any computer ever created.

That in itself is kinda interesting.

Ofcourse such emulation can already take place in software... however now it may execute a bit faster thanks to this transputer.

Another interesting property is:

New/strange/experimental instruction sets.

The ammount of input/output combinations/transition tables is so large that for the next 1 billion years human beings will probably be busy exploring them. Though perhaps quantum computers and/or artificial intelligence will speed this up considerably.

How many undiscovered and practical instructions remain to be discovered is unkown :) but it is a source of fascination.

Perhaps AI/evolution could try evolve it's own instruction sets and see what it leads to.

So basically that the "software driven" transputer comes down to is a "lookup table computer" perhaps with some additional capabilities to compensate for the lack of transistors to cover all possibilities and work around this lack with path/data flow into transition tables used to compute partial results which are combined to full results.

Instead of booting the operating system... perhaps it would first load transition tables in some kind of format.. to load into it's own processor memory.

For now I would expect this transputer to be slower at mimicing existing instruction sets... it might be usefull for non-existing/experimental/future instruction sets though... or very old ones.

Bye, Skybuck.

Reply to
Skybuck Flying
Loading thread data ...

That would be a field programmable gate array. However I do agree with the idea of displacing complex function evaluations to memory lookup. You need somewhat more complex data structures though. For example Bloom filters, hash tables, decision trees etc.

Reply to
sean.c4s.vn

Lookup table cpu was done years ago.

formatting link
It can indeed improve performance to tr count ratio.

NT

Reply to
tabbypurr

" That would be a field programmable gate array. "

Perhaps this software driven transputer can be more optimized then a fpga and thus faster.

"However I do agree with the idea of displacing complex function evaluations to memory lookup. You need somewhat more complex data structures though. For example Bloom filters, hash tables, decision trees etc."

The complex data structures can be created by the software which would run on the software driven transputer.

So there are two kinds of software.

The lowlevel software which configures the transputer and pretty much tells the transputer what kind of instructions it has.

And the usual software which consists out of instructions which the transputer can execute.

Bye, Skybuck.

Reply to
Skybuck Flying

" Lookup table cpu was done years ago.

formatting link
It can indeed improve performance to tr count ratio. "

"tr" ? what that mean ?

Bye, Skybuck.

Reply to
Skybuck Flying

Let's try and design one right now for practical purposes:

Inputs 1 to 32. Outputs 1 to 32.

Unfortunately this would lead something to 32 to the power of 32 gate configurations, so it's not practical.

Let's do the usual

8, 16, 32, 64 inputs. 8, 16, 32, 64 inputs.

4 to the power of 4 = 256 gate designs.

However implementing transition tables for 32, and 64 not gonna happen.

So these can probably be safely removed for now.

Though perhaps it's possible to make some special gate logic which doesn't execute a transition table... but just a transition table path...

So the transition table... would be more like a table explaining which other tables need to be executed and in what order preferable.

Possibly example of this idea:

32 to 32 8 8 8 8 8 T1 8 T2 8 T3 8 T4

Maybe this might be sufficient to explain which parts of input 32 needs to be excuted and to which output it needs to be piped.

However.. a single transition table call seem unlikely for more complex functionality.

Perhaps these tables could be made 3D to give more calling oppertunities.

Not sure in what order it might make must sense to execute...

All at once, and then slice wise

Or depth first.

Perhaps that could also be a configuration for maximum flexibility. This would make the instruction encoding a bit more complex but still doable I think.

Instruction encoding could be something like:

TransitionTableToBeCalled, 3DProcessingOrder, Argument1, Argument2

I will leave it at that for now...

Perhaps this byte-wise approach might make practical sense...

Though a bit-based one might also be more interesting.

Bye, Skybuck :)

Reply to
Skybuck Flying

transistor. What else :)

NT

Reply to
tabbypurr

If you've got 2 input numbers & 1 process, each 1-32, the number of lookup cells is [naively] 32x32 = 1024. You might reduce that with a few tweaks, eg

- reordering the input numbers would permit proessing upto eg 16x32 or 32x16

- for some processes you might flip a line according to the input value, halve the input value then eg double the result after the lookup. etc

- symmetrical processes only need half a table etc

NT

Reply to
tabbypurr

" If you've got 2 input numbers & 1 process, each 1-32, the number of lookup cells is [naively] 32x32 = 1024. You might reduce that with a few tweaks, eg "

You're correct, I was wrong, thank you for correcting my mistake.

The number of configurations possible is indeed 1024.

The number of input+output gates for all of them would be: 33792

However the problem remains that to actually make a transition table for 32 inputs to 32 outputs, the number of transitions is quite large.

One possible solution could be to reduce the number of allowed transitions in total.. though this might create gaps in the logic... perhaps those gaps could find the nearest valid transition... not sure if that makes any sense though.

anyway...

This time I ll try to do a somewhat correct calculation or in the neighbourhood calculation for transition table size:

2 ^ 32 = close to 4 billion input possibilities... all of them will need a transition to some output possibility.

However nowadays chips to contain billions of transistors... so this possibility is getting closer and closer.

Though a chip with just 1 transition table would probably be not very usefull =D

Maybe in the far future when trillions of transistors on a chip, this software transputer might become a more interesting idea ! ;) =D

Bye, Skybuck.

Reply to
Skybuck Flying

damn. Is it? How do you get that?

that's effectively reducing the number of bits. You could get away with it in some cases though, where the mathematical function went through low slope.

If the idea works better as 16 bit, so be it. 16 bits can do plenty.

Maybe you're missing an opportunity... use a small amount of electronics to look up a table that's stored in ram. Gigs of ram is no problem.

So you use logic gates to look up table entries to replace logic gates. But in the process the number of trs used drops heavily. Low tr count makes it relatively easy to institute multiple cores.

I recall folks criticising the lookup table CPU back in the 90s I think it was, but its so-so performance took far less transistors than a so-so traditional cpu.

NT

Reply to
tabbypurr

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.