Re: [oc] Beyond Transmeta...

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

> > What I ment was - how many instructions and cycles do you need to
calculate
> > all 32 bits of e.
>
> For e alone, it would take 124 instructions... the amount of cycles it
takes
> depends on the number of 1bit processors. 1 processor is 124 cycles, 4
> processors is 32 cycles. In this case for 1 add you don't need anything
> higher then 4 processors. Of course this depends on the how the network is
> setup to do the add.
I suppose it would be nice if network would be optimized like normal
circuits.
But I am still concerned about speed - normal adder would probably add much
faster.

I think calculations for 4 processors are meaningless. You should calculate
number for larger numbers, like 32, 128,... (all for 32b operands)

> Yeah, I think 2 output connections may be the limit, but having 2 as a
limit
> means you can link another one to it and then have that one with 2, making
it
> 3., and you can keep doing this until you get the amount of connections as
> needed, but this eats clocks though.
yes, you would probably lose much more than 5% like on or2k.

> I agree, I'm still not sure how it can be done and still have self
> modification. I'm trying to think of another way of doing self
modification,
> I believe neural networks use something called back propagation, I'm going
to
> have to study some of that. A self modifying network would seem to work
best
> with at least a backwards network to alter it. hmm.
I don't see how could be back propagation used here.  But you can have
connections
like neural networks - in layers. But I would still suggest to use some sort
of uniform
basic topology with 4 or 6 connection. Otherwise performance would degrade
too much.

> Message passing? Hmmm, would this increase the amount of work the 1bit
> processor does, or do you think a seperate component does the routing and
> message passing?
Message passing could be done in three ways (I can think of):
1. you can have special modules which route specific message (with
destination address=
    to destination), but I don't think this comes handy for simple 1b
processor
2. you can hardwire routing - allocate path and define f(x)=x functions
there
3. general f(x) would be too complex (takes too much time) connection
matrixes
(or something) could be placed and would work similarly to 2.

> > I don't see a problem here if routing would be enough general. But even
if
> > not
> > nets can be optimized pretty good, shown in or2k example. Speed loss
> > in 3x3 or2k matrix because of connections inside basic block is just
around
> > 5%.
>
> hmmm, I wish I could pretend to know what you mean but I am at a loss.
If you could have all possible connections between two processor then speed
would
be at 100%. Now, with limited connections speed fell to ~95%.

> > You can surely use function like use normal instructions. But you cannot
> > gain
> > parallelity this way.
>
> Thats right, but you reduce network redundancy and decrease memory usage.
I don't see how - if you pass parameters to function-network is like you
pass
registers to normal function. Parallelity is limited because you must wait
for
function result.
How you gain free memory?

> > There is another thing I am not sure I understand - how would you know
when
> > certain network finishes its work?
> > You cannot know that from result itself unless it changes, but you don't
> > know if
> > it ever will. So when may you use it to send it to next network?
>
> Well, it depends on how the network is configured.
>
> If it is configured to work like a CPU, then it will try to emulate what a
> processor does, either through a timing network that consumes clocks and
is
> setup to alter a bit when the estimated amount of time to do it goes by,
each
> type of CPU instruction could have its own kind of timing network. This
would
> eat up clock cycles though, and bits and require routing as well. I think
> networks have the ability to replicate any kind of hardware logic, if you
can
> create a processor that does it in real life, then a network could be
setup
> to do the same... At least I think so...
Yes, that is true, but only if have good routing...

> When its configured to be a persistent network (where things only update
if
> necesary), then timing is less of an issue, although a part of the network
> will probably be setup to act like a timer, or some input bits will take
in
> an external timer, but for this kind of network its less important to know
> when they finish its work because they only update if their work needs to
be
> changed.
Yes, but for final result you should know that. I suppose that some
operations
could take variable times (like loops). You must calculate clocks then.

It would be interesting if network would't be synchronised - no global clock
(BTW: with larger network you would have serious clock problems),
that means longer routing takes more time, but when signal arrives and
stabilises you should have your result ready. But there are problems with
calculating. Of course this timing could (and probably must) be calculated
by compiler.

Marko