Re: [oc] MISCs and partially desinchronized networks

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

> Since you have more than one ALU, you obviously have multiple data.
> Some machines send the same (single) instruction to all processors in
> each cycle. So if one is reading a word for its right neighbor and
> adding it to its second register in that clock, all the others are
> doing the same. This is very limiting (you can't do an if-then-else
> based on the value of a register, for example!) so most practical
> designs allow you to set a flag in each processor and have the
> current instruction be treated as a NOP by those that have that flag
> cleared. An external circuit feeds the instructions to all the
> processors, so they don't need control instructions (jump, call and so
> on).
Every MISC has its own program.

> Since you indicated in another message that each of your processors has
> its own PC register, there are obviously multiple different
> instructions being executed in each clock. So yours is a MIMD machine
> (like a Linux Beowulf cluster, for example). But in that case, you need
> control instructions to change the value of the PC in each processor,
> don't you?
Yes, I looked back in my first e-mail and saw that forgot to write
instructions:
jmp and jf (jump if flag set). Sorry.

> > Only communication needed is communication between functions and
> > accessing memory units. Most of communication is done with direct
> > neighbours and FU0. Although this MISC matrix does calculate
> > sequential programs much slower than other ideas you mentioned.
>
> But you mentioned a "fractal design", which I understood to mean an
> expansion of the network by hooking up the FU0s from different chips
> together.
Yes fractal design means right that.
But if you have several processes, you will put them in same cluster
and their data near them, right? So mostly (like 95%) there are only local
communications.

> You can be sure of this. I did a lot of simulations of different
> communication patterns in networks with different sizes, different
> topologies and different routing algorithms and I can tell you that
> there were many surprises. Einstein was right: "Make things as simple
> as possible, but no simpler!".
I am a bit worried by 16x16 size (like Jimmy mentioned), but there is no
problem to decrease this to 8x8 or 4x4, only thing is that you have more
special FUs, which decrease computation power and make connections
more difficult to route.

Marko