Re: [oc] Beyond Transmeta...

[Suboner@aol.com]

> I think you are forgeting something. Time to execute 100 sequential
> instructions
> with ILP=3 can NOT be executed faster than 33 cycles! (if not using
> superpredictivity
> methods, which are useless for real implementations).

Oh no, I'm not sure what you mean by ILP=3.

> Another thing is:
> When writting mouse handling routine you would implement mouse button as
> integer... you are SW guy, you should know that. Everybody is doing so.

For the persistent network only 1bit will be necesary per button. When using 
a network as an X86 processor it would probably be an integer for 
compatibility. The network excels at bit alignments, it can interlace bits, 
numbers that are integers do not even have to exist right next to each other.

> Your network simply won't know that there won't be other number than 0 or 1.
> Reading from HW port itself leads a compiler without clue what will it get
> from there...
> And I assume that you consider having all port values documented by compiler
> tremendous overkill. But this is not HW port property - external functions
> all have such uncertanties...

Ports are mapped to bits in the network, when the bit's values change, their 
relationships are recalculated, and all related bits if effected by the 
change are recalculted. Think of it as each bit connected to a port are like 
interrupts, when their values change the interrupt the system to be executed, 
this makes the system more reactionary to outside influence.

The compiler does not have to look at things as bits, although it would help 
in reducing memory usage. This also depends on how the network is configured, 
if the network is configured like an X86 system, then it would compile just 
like an x86 compiler, if its setup like an RISC the same thing, if it was 
custom it would compile for that custom processor, or if it was setup as a 
persistent network or somewhere inbetween a single processor and a persistent 
network, it would convert the code into a network. I believe I have discussed 
this before, when I was converting number equations into a network, I don't 
see code being much diffrent except added branching and looping, which can be 
achieved in various ways (branching seems easy enough o me, and looping is 
probably the more complicated one to setup because it is a nested branch). 
The better part of it is the shifting, being able to shift a network 
representing a program around, like shifting an equation around will allow 
you access to certain variables from other equation. Shifting may be the 
other hard part to solve for, but if it works it should do many great things, 
and its use will result in an effecient system, the more resources its given 
the more just about every application can effectively use to increase 
performance, imageine if you could build an application and it would build a 
custom processor for every part of that application (the application plays 
music, so it creates a network of multiple DSPs, and decompressors, and a 
processor to run the application), and you had a lot of 1 bit processors 
crunching away at this and enough memory to hold those processor networks. 
Your creating processors from bits and their relationships.

> You should know that programs have to be written for parallelity you
> mentioned.
> (there are special languages for parallel computers, but who uses them?)
> There is currently no known way to find parallelity between functions,
> etc...
> I am currently fighting this battle myself. I will try to find a way to
> convert
> sequential programs to parallel based through ILP (or any other suitable
> method).

If you look at functions as a serial stream of instructions, then there does 
not seem to be an easy way to find parallelity between functions. Once they 
are converted to a network, its just like an equation, they get broken down 
naturally, and you find that some instructions can be executed simultaniously 
while others cannot (they are to dependant on order), and by rearranging how 
a function works you can cause even more parallelity between functions, the 
network would essentially do the same thing. For example if I had to add 10 
number together, there is some things you cannot do in parallel. If you do it 
serially you do 9 adds one after the other, if you break it down to a network 
you can see that you can shift them around and do 5 adds simultaniously, and 
then 4 adds simultaniously after that, that is 2 passes versus 9 passes. And 
if you can only do 2 adds simultaniously then you would do 4 passes. Addition 
is simple but you can get more complicated forms of shifting with using 
subtraction, multiplies, divides, square roots, etc... in a binary network 
output is a result, inputs are your variables.

Leyland Needham