Re: [oc] MISCs and partially desinchronized networks

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

> > 1. Multi-task environment? How will you handle address translation?
> >     and Context Switch?
> Multi tasking can be run as on normal RISC, but you can run multiple
> functions at the same time, of course. If you run out of space/processors
> you must swap to external memory.
> ^^^^^^
> Here, I am still curious about your idea...Since your programs
> are written in C. OK. now you disassemble your program.
> What's your program like? If your program use not only 4 GPRS/per MISC.
> How did you alias your registers? How do you locate eight registers,r1
> to r8, to two MISC? How did you describe it in assembly?
No, you got things wrong. Only memory can be accessed by any
FUs, 4 (local) registers (+PC,flags) are only for MISC itself.
Memory accessing is done via messages.

> Besides, the task "run out of space/processors, you must swap to
> external memory" is a big task. Where will you store it? And
> next time, where will the interrupted task be loaded? The same
> MISC? Maybe it should be relocatable and located to another MISC.
Yes, unfortunately swapping is big task. You have to transfer data outside
of matrix if memory units are full. You can have normal memory arhitecture
there. I suppose memory throughput needed would really be large.
But I think this is common for so many programs.
I was thinking more of dinamic processor allocation (done by scheduler) -
special task (probably not running on FU0).

> have similar problems, so I can look there :)
> ^^^ I feel it's still a problem... How do you enable users to
> set break point? Once CPU is stopped, How do you let users
> read other MISC status, for example, the farest MISC from current
> one?
I agree, debugging is by default much more complicated than on RISCs.
Hmm... FU0 should set these things - maybe messages as step would
be sufficient, you should be able to simulate breakpoints with them.
Debugging sure is important - I will give it some thoughts if we find out
speed is not a problem.

> > 4. How to map each MISC's memory space to global memory space?
> Basicaly MISC memory is used for program, but if there is enough space
> available you can simulate stack for local variables. Local memory is not
> mapped into global memory space. It could be done, but I don't think it
> is smart.
> There is greater issue for memory units, since its practical to partition
> processes
> near memory units they use.
> Each byte of memory in both memory and MISC units can be addressed via
> fractal idea, I mentioned - you can have 4+4b for each layer.
> ^^^^^ layer? What's this?
sorry. Layer is a matrix of layers, last layer is matrix of MISC = cluster.

> important - you just more time for research and implementation itself. I
> rather
> concentrate on simple and uniform structure.
> ^^^^^^^^^ I don't think that will succeed if you only concentrate on that.
> If you want your architecture succeed, your view had better be global.
> Otherwise, if no commercial CPU with your architecture sails worldwide,
> how can you prove your thinking is correct? But commercial product
> is not easy, especially in high-end processor.
I completely agree.

> Simple and uniform structure has been studied for a long time.
I know it is 'impossible' to implement something useful and even if
you do, you are not first.

> is a must. Besides, if you would like your MISC to emulate X86 or
something
> like that, how do you do that?
Yes, simulating X86 would be a problem - you have to convert code
to MISC code and find basic blocks/functions. That should be a problem, but
I takes some time. And even then performance would be low for sequential
programs. As I stated this computer was never meant for standard sequential
programs. Whole code have to be written in some parallel language or in C
and have many threads.

> Simple is good. But your architecture is feasible?
> I feel OK. Now you have come to the point of using this architecture.
> At least, you must reconsider it top-down again.
>
> 1. overall instruction set, special registers, MMU, Virtual memory,
>    bus interface? the data and instruction flow?
> 2. OS? how?
> 3. compiler or other system software?
> 4. application? embedded? or high-end supercomputing?
>    or low-power mobile?
Currently it is suitable only for supercomputing ;)

> If you can plan this overall and convince others, then
> others on the internet may give you hands.
> I could help you, too.
Hmm - porting Linux would be quite a job.

Thank you for your help, I will rethink this all over.

Marko