Re: [oc] Beyond Transmeta...

[Suboner@aol.com]

I have been doing a little programming. If you want to see what an 3bit add 
network looks like you can download what I have done so far at...

http://members.aol.com/suboner/binet.zip

Its a windows executable (:p), but there is source code there and since it 
was written for gtk+ using glade, you can probably take that source code and 
alter it (add bnet.c to the make file) to have it compile for Linux. It 
basicly shows a simple network, I gave the bits names so you can understand 
them a little better, and the instruction 4 bit instruction is under that 
name along with a name for the instruction.

I'm mostly experimenting with the interface code for right now so there is 
really no functionality at all except drawing a network (or one way I think I 
am going to have it drawn), but I want to figure out a way that it would work 
in hardware and to implement a simulator for it, and to represent the network 
in a way that is similar to hardware that could potentially run it.

> yes, of course, but what am I trying to tell you:
> 1. you still need ~32 cycles per add, RISCs need 1c, thus sequential time to
> execute
> is a lot larger

I already know that to. I'm sorry if I am repeating myself... we are going in 
loops here.

> 2. you cannot have more than 32 parallelly running adds, so your network is
> just a (let's say a few times) faster than RISC - just because of frequency,
> but only if you have such parallelity.

These is probably a balance somewhere in there between the number of 1bit 
processors and the frequency they run at, that will give them their best 
performance, because I would think that having more 1 bit processors would 
probably lower their ability to clock higher. The thing is though (and I am 
probably repeating my self here) you can have a mixture of operations you can 
do simulataniously not just adds, and it also depends on the network.

In reality its hard to compare it to normal processors, because its not 
really a normal kind of processor. It has the potential to be faster in some 
cases and slower in others, it may just be that in most cases it will be 
slower, and in the least situations it will be faster, but this will change 
with memory. The more memory you have the more the network can rearrange 
applications to run more in parrallel and more reactionary and more 
persistent (only doing work when it needs to, and doing this on the bit 
level).

> suppose you know that your network can be only slower than normal add
> network consisting only of gates. I think that 32b+32b adder needs 23 layers
> of logic. For same implementation you would need much more gate layers!

I'm not sure what a gate layer is, but I believe it would take 124 
instructions to comple a 32bit add, and 4 instructions can be executed in 
parallel (except the last 4), which result in 32 cycles, 32 layers that can 
be done in parallel.

> uhh... this thing has to be done in HW. It really complicates all thing.
> it would be better if you would route things staticaly (by compiler), and
> then
> use free instructions/functions (if not free =>wait). Only small
> instructions
> should be inlined.
> BTW: you can pipeline one function (if it doesn't contain loops) so you can
> execute 1 function/cycle, regardless of function length.

I'm a little lost here, as I am not sure which you are saying is complicated, 
the perstent network or the processor network?

> You could also have two bits for each signal:
> 1. data (same meaning)
> 2. 'clock' bit - changes only when data hasn't changed
> Using this principle network can be totally unsinchronized.

I'm sorry, I think I am sleepy or something, I've been having a hard time 
following you here... I'll think about what you have said and reread it 
tomarrow, if you want to you can try explaining it diffrently, maybe its just 
that I do not enough knowledge of hardware in some cases, and 
misunderstanding in others. Well I am off to bed, thanks, and don't forget if 
you can check out my program above.

Leyland Needham