In the FPU thread Gunnar brought up the possibility of using one of the threads of the Robin core as an FPU but I'm not convinced that is a general enough solution.  If the compiler is already capable of trapping FPU calls and rerouting them through a library then that is good enough for most software, assuming that there is good communication between the IEEESingBas.library and the Robin core through some sort of interprocess or intercore communications link.

What should that link be, however?

 
b) If there is no allocated free thread then this could take infinite. It could be that all 4 threads are busy with big jobs. This could make a single FPU instruction have to wait for Robin to become free - which could take forever if Robin is decoding a video.

 
I like the zero latency option much better.
What do you say?

As Gunnar described, allocate a Robin thread like a CIA timer or whatever.  You have claimed it for a certain task and it is claimed until released.  I think this is the best answer for this.

Crow wants an easy and efficient method in hardware of communicating between threads.  I think perhaps this would be helpful to make multi-threaded coding easier, and could be combined with the allocation scheme above.

So if we were using a Robin thread for FPU things within the regular 68k instruction stream, we would allocate a thread for that task.  Then have that communication mechanism send the required operation over to Robin for accelerated emulation.

Or perhaps one thread in Robin is doing some type of physics, and needs to send a flag to the audio mixer thread also in Robin that something has collided and to mix in the appropriate sound. 

So I do not think it is just trying to get a little job picked up by Robin when a thread is free, but to talk between threads that are already running.

I was thinking how this scenario seems like the sprites versus bobs discussion we had earlier.  A thread hardwired to do nothing but floating point costs something for every program while a thread allocated by the IEEESingBas.library would only be allocated if floating point is used by the calling program.  If a Robin thread couldn't be allocated, then IEEESingBas.library would fail to open and the host program would report an error.  This would not cause a deadlock.

@OneThousand

Indeed, I see this as a prerequisite decision to the other FPU issue.  If we can have a channel of communication between the 68050 and each of the threads used by the program mapped into the FPU instruction set of the 68050, then we can make the libraries efficient enough that a hardwired solution wouldn't be necessary.

If we can't figure out a "mailbox" of sorts between threads, then we'll be forced to communicate using main memory as the intermediate step which will be slow.

The main idea is that Robin has multiple Program-counters, one for each thread. These program-counters will sit somewhere in the DFFxxx area. The 68K can read them and write these PC's.

Robin will do its own DMA to fetch data into registers and can do its own DMA to store registers in memory. Robin can also store register in the CHIPSET DFFxxx area. Thereby Robin can poke AUDIO-output, control the Blitter and can control the TAMI.

The are several options on controlling the starting and finishing of a Robin threads.
- To start a ROBIN thread the 68K will need to set the PC to the start of the Robin routine.
- If a Robin thread is finished it could shut down it self by jumping to an illegal address e.g. FFFFFFFF. An ODD PC address will disable ROBIN.
- The 68K could set the PC of Robin pointing to a Robin Routine which saves or restores all Robin registers into memory. When the registers are saved the PC could be set to the new Robin routine.
This way you can in theory even run an infinite number of tasks on Robin.
- I theory a Robin HW-thread could set poke the PC of another Robin-HWthread, this was Robin could start/stop and control itself. ("Its alive Igor!" *evil laugh* muhahahaa)

Each Robin HW-thread has its own set of 64-Registers.
We could slightly change this so that some 1-2 registers are physical the same register for all threads. This way Robin threads could set semaphore to each other using their register set.

I think the above is simple but gives us a lot of freedom i designing complex solutions.

In some ways, Robin works very similar to the Copper.

There is one challenge that I see so far:
The copper did not need a cache, but to get a good performance ROBIN will need an instruction cache.
Currently I'm unsure what the best way of designing the cache or buffer will be.
We talked creating a ZERO-Page local-store with for example 4KB.
Such a zero-page will work fine but it will limit the size of the ROBIN programs - unless ROBIN itself will reload more routines to the Buffer per DMA.
We have to find out what size is enough for most task and if a real dynamic cache would not be better allowing reloading of more instructions. If we have a dynamic cache then the best might be the split it from the beginning into individual cache for each thread. This way we can guarantee that one thread will ot push out the other from the cache.
A simple solution might be to have a direct mapped 1KB Cache per thread. The cache will reload new content automatically per DMA. This way a ROBIN program will have the possibility to have infinity size.

With a small individual cache each Robin thread will behave a little bit like a Super-Powerful 68020 CPU.

Any comments, ideas?

Cheers

And yes 1Kb per thread could suffice, when updated regularly.

But how would we DMA 1 per thread or one for Robinn?

I think a DMA channel per thread would be cool. :P

DMA 4 or 1 channels? (this is important to the addressing bits used)
cache if you have one 4kb one thread could well indeed claim it all pushing the others out of it.
Having it divided between between the threads could solve this.
cache would have to be flushed because selfmodifying code atleast less without a bcc.

well communication between the bus and the unit are more clear but how about between the threads?

Cache snooping might be preferred over a full cache dump but that takes a lot of LU, I think.  Especially with 4 caches separate from each other.

I think a good way to look at this is with the small kernel idea that many GPUs or media processors use.  Load up a kernel or tool, work on it.  Load up another that is needed soon.  Move to that, eject what you are not using.  And so on.

Perhaps there is a good way to encapsulate them as objects where addressing is taken care of more easily.

If that is the case then we'll use a local-store type of idea.  It will be for code only though in this version.  Who needs a data storage area when you have 62 general purpose registers and a program counter addressable by the instruction set?  Not many people!  Especially when there is a way to pull in 4 registers at a time with a burst fetch.  The only time you'd need more than that burst fetch is if you have fully interleaved memory like RAMBus memory.  Other than that?  Hardly ever!

Now the question is:  Will the registers that control the local store be memory mapped or will they be mapped into the registers of the Robin itself?  I think they should be memory mapped so that the local store can be prefetching and then execute the program counter when memory is finished fetching.  Otherwise there would be too many things tying up the bus at once.

Memory mapped control registers sound good to me.

Were there any more thoughts on thread communication?  I guess this could include how to manage "tools"/RobinObjects in a nice and easy fashion. 

In the other thread, it sounded like Gunnar was getting geared up for a go on a small first version, and this is critical stuff.

My only concern with this method is how do we handshake with the '050/060?  A halt instruction in the Robin core would probably be implemented by an ORI #1,PC to set it to an odd address.  Perhaps a better halt would be to set the PC to 0 using an OR R0,R0,PC.  That way the completion of the calculation by the robin core could be indicated to the CPU with a single TST.L to the address of the Program Counter register of the Robin thread.

What do you think of that idea?