Who says this?

Marcel Verdaasdonk wrote:

The Idea slave is bad. if you would use a clone core to do loop and repeatative task acceleration you would cause less trouble.(suffice it be independent)

As a Clone core is the same as slave core - where is your point?

Marcel Verdaasdonk wrote:

IMHO i think it is more important to actually finish the 68050 core and then start work on the 68070 as this would be a clean and clear solution.

What are you talking about?
Of course the 070 will befinished before cloning the core.
Marcel you really need to try to read more careful before you post.

The whole point of the "clone" idea is.
When the 070 is finished there might be lot of space available to use... Expecially in NATAMI2. Cloning the 070 is simple, take no time  and allows scaling in performance.

I had thought of doing exactly this already too. It's an excellent idea that easily solves the hardest problem of adding multiprocessing. There are plenty of other problems (stack problems?) though and would likely require changes to the OS. How many non-memory protected processes can be done too?

[Sigh. Is nobody reading my posts or is nobody understanding my posts?]

Greetings,
Thomas

I understand what you write but I don't understand the relationship or dependency between the operating system and hardware

Please persevere

On the basis it means without creating a brittle system that would stop it's (co-processor) slave core at the drop of a hat.
A hardware solution wouldn't do the specific trick and would cost a lot of space in the process.

Forbid() is a locking mechanism.
But most of the software indirectly use it in the form.
SysBase->TDNestCnt++

If you would bus snoop on this you will lock more times then you need to.
If you only check on Forbid() you undershoot your target.

Why intervention before the execution would be a problem?
And how can we be sure of the space needed?

For now, I still think that a hardware solution is the best approach. The "OS" should not be changed, but expanded, and I still think that a master-slave configuration is a good deal.

I think what Gunnar proposed is something like a conditional memory breakpoint on SysBase->TDNestCnt address (implemented by hardware).

By inserting a delay, it should be a less onerous than checking instructions.
 
  examples probably stupid
  to intercept interrupt request
  to intercept a hardware or software interrupt code.

This solution is quite simple.
 
And dont think that its expensive!
This s not expensive!
We can code the VHDL for this on a weekend and its will take only peanuts of FPGA space.
 
I hope this explanation is clearer now.
If you think that it would not work then please tell me what I've overlooked.
 
Cheers

No, the addres could be configured.

I think the logical flow would be the following.
1) The systems reboots.
Only the first core is active.

2) The OS does boot.

3) On Workbench you launch a tool to enable all the cores.
This tool will poke the magic address in the Cores.
From now on all the cores are active and all will sleep if FORBID is called (except the calling core)

Does this make sense to you?

But for a bad program which work directly in hardware, what would be the impact?

Merci

One of the dirty ways of getting full control of the System is to disable the interrupts. This will of course work.
And has of course to disable the other cores too.
Simple and fully backward compatible.

For example, in the current multitasking system, operations like

cmp.l (a0),a0
beq.s listisempty
...

are atomic - and in use by the Os, for example in exec/GetMsg(). It is an atomic check used there whether a list is empty.

A similar trick:

bset #0,lib(a6)
bne.s isIsUse
; some critical code goes here
isInUse

will detect whether a certain code-piece is in use by another task simply because the bset is an atomic instruction in a single-core environment - task switching can either interrupt before or after the bset, but not in between.

And, believe it or not, such code exists. Even in the Os. They are perfectly fine as they are, nothing wrong with them.

Now, this situation changes dramatically in a multi-core environment. Instead of the first construction, one would have to use "cas", instead of the second, one would have to use "tas". Instructions you should *not* have used in the original Amiga hardware, though.

Please, forget this crazy idea - believe me, it won't work.

So long,

Thomas

But you agree that we would have s solution for the FORBID case?

Lets look at each case step by step.

Thomas Richter wrote:

For example, in the current multitasking system, operations like       cmp.l (a0),a0   beq.s listisempty   ...       are atomic - and in use by the Os, for example in exec/GetMsg(). It is an atomic check used there whether a list is empty.

Hmm, I fail to see where the ATOMIC part is.
Between the CMP and the BEQ is already a gab.
Can you explain this?

Thomas Richter wrote:

A similar trick:       bset #0,lib(a6)   bne.s isIsUse   ; some critical code goes here   isInUse       will detect whether a certain code-piece is in use by another task simply because the bset is an atomic instruction in a single-core environment - task switching can either interrupt before or after the bset, but not in between.

I understand this.
This should be no probel to support in a multicore environment.

The point is that for a pipelined CPU the above operatio would  actually not ATOMIC. To make it ATOMIC the CPU needs logic to avoid write/read hazards.
The challenge is that the READ is in the pipeline above the WRITE.
This means an instruction write could be "overtaken" by the next instruction doing a read on this address.
A good CPU has logic to take care of this.
If done properly this logic works like this:
For each instruction doing a WRITE the address is remembered for all following instructions in the pipe that do a READ the address will be compared and if matches the instructions will either stall or the results will be forwarded inside the pipe.

I think what you ask for is simply to share this logic between two or multiple cores. This means if CPU CORE 1 is doing a write or read/write operation on a certain address it will block other cores from accessing this address simultaniously.

Sharing this logic between all cores should do what you want.
It should also make ALL read/write instruction ATOMIC from a SMP/CPU perspective.

Cheers