Re: [oc] MISCs and partially desinchronized networks

[jimmy87@sunplus.com.tw]

> 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?
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.

> 2. debugging environment?
When debugging specific function I think there are no problems.
There could be problems with message passing - but user doesn't
mostly doesn't need to know it's neighbours and processor internal
structure (mostly (s)he can rely on messages sent received).
Of course there are some great timing hazards if you program in
assembler, since messages doesn't come deterministicaly.
But if program was build by compiler this should be a problem.
I didn't find any practical representation by now, but I think all TTAs
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?

> 3. Each MISC has his own register file. But the whole chip register file
>     resides where? Or the whole chip register file is the collection of
>     all registers in each MISC.
Uh, It seems to me I wasn't clear enough.
MISC has 4 GPRs, and also internal memory of 128B.
There is no global register file - there are however memory units,
but they act as memory (dinamic allocation,...).

> 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?

> 5. How to handle the CPU's special registers or global control registers?
I don't understand what you mean by global control regs.
CPU doesn't have any special regs except PC and flag bit, which is not
explicitly accessible by SW.

> 6. what's plan of bus interface connecting chip to external world?
>     all by FU0? Then if one FU locating farest from FU0 wants to send
messages
>     out of the chip, the cost would be great.
Yes that is unfortunately true. However if implementation allows 'FU0' can
be placed
at (8,8).
If compiler could write programs that store data in memory units near them
then cost
is greatly reduced - memory units thus act similarly to cache.
I think that sooner or later all processors will have some sort of localized
structure,
I don't belive these problems can be easily solved. Surely you can have
implementation
that executes e.g. 40% faster, but this is constant factor, which is (of my
belief) not
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.
Simple and uniform structure has been studied for a long time.
But how can you make those idea come true. For example, the product
of Transmeta has been researched for a long time. But, after so many
years, Transmeta makes it come true. If you wish your idea comes true
when you are studying and implementing, I think globally thinking
is a must. Besides, if you would like your MISC to emulate X86 or something
like that, how do you do that?

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?

If you can plan this overall and convince others, then
others on the internet may give you hands.
I could help you, too.

If you can't, then your ideas may be like the past, a phantom idea.
Otherwise, everyone give you ideas. You can talk about it easily,
but every task you said is almost a hard task. That's why predecessors
fail.

Best regards, Jimmy