Re: [oc] Beyond Transmeta...

["Marko Mlinar" <Marko.Mlinar@campus.fri.uni-lj.si>]

> > 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.
ILP= instruction level praralelism

> > 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.
Yes, that's true - I haven't looked at it this way...
So if I understand you correctly you are trying to calculate each 'bit
plane'
as fast as possible (from its point of view). I suppose this could be
theoreticaly
done faster than calculating 32b operands even for sequential programs.
But I am worried that programs would be extremely large.

In how many cycles can you execute this? How many instructions do you need?
c = add32(a,b)
e = add32(c,d)

BTW: I am not such pesimistic guy trying to criticise everything. When we
were
developing or2k such 'comments' were very welcome.

> 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).
I suppose you can link data back to loop start, can't you? Parallely you can
detect
whether loop should be finished. Of course this isn't normal equation
anymore...
But otherwise I don't see a problem here.

> 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.
Yes that is true for basic blocks. But not for functions. Compiler would
create
separate network for each function (there are too many problems otherwise).
You cannot link them dinamicaly together. I won't go in detailed
explanation,
even when detecting parallelity between functions there are certain
problems,
unless program (meaning of program) itself is modified. ILP here stand for
inductive logic programing.

Marko