No. There is no interrupt for MOVE16. It works much like the FPU or MMU coprocessors where the instruction fetch and pipeline are shared with the main processor but at a certain point the work is turned over to the coprocessor to finish. The main processor may or may not be able to do some work in parallel before the coprocessor returns with a result. A coprocessor in this sense is not much different than an executing/functional unit (i.e. integer unit, branch unit). I don't know the technical difference but a coprocessor can consist of several executing units. This method of starting and stopping the coprocessor is simpler and faster for short memory copies. Using the blitter would become much more interesting for large memory copies if fast memory could be accessed also as recently talked about in another thread you started ;).

Keeping as much in the 16bit instruction space as possible has a advantage to the fetch of those instructions.

Note: The CpID of 110 and 111 should remain open for user-defined coprocessors.

I hope think enforcement is possible. I would like to see agreement by the leaders who help create the ISA and first implementations and then followers will want to be compatible. As for FPU, it's pretty much already set as 68060 FPU compatible with coprocessor ID 001. I think it would be good to add 1/2 IEEE FP and at least unsigned longword <-> FP but, besides that, the 68060 FPU is pretty good. I could document the FP instructions for the ISA if or when someone becomes interested :/. More advanced single precision FP processing could be done in a SIMD eventually. The first SIMD would probably be much simpler (integer only and small sizes). I don't know enough about SIMD to design an SIMD coprocessor for the ISA. An SIMD unit would be tricky to design as they evolve as they get bigger. A small SIMD doing byte color component calculations is very much different than a big SIMD doing 3D vectors with FP. Even the instructions used changes. They are more specialized than the CPU or FPU. It might be best not to include an SIMD specification in the ISA at first.

Marcel Verdaasdonk wrote:

If the CPU is designed in a manner that handles them external they can be outside the main pipeline, and thus asynchrone to the CPU itself.(Read DMA)

That is true. The main CPU pipeline is shared at first but then the coprocessor instructions can execute asynchronously (in parallel). There can be a change/use delay when results are brought back to the CPU pipeline in some cases.

Marcel Verdaasdonk wrote:

Keeping as much in the 16bit instruction space as possible has a advantage to the fetch of those instructions.

I think it's more about having 16 bit encodings for the commonly used instructions. There is not enough encoding space to have 16 bit instructions in all cases.

Marcel Verdaasdonk wrote:

Note: The CpID of 110 and 111 should remain open for user-defined coprocessors.

000 MMU
001 FPU
011 68040-68060 MOVE16 instruction
100 CPU32 table instructions
110 ???
111 ???

Why should those coprocessor codes be reserved?

And matt your right about SIMD, but this should not be visible in the ISA itself but should be left to the implementer of that unit all we should give them is a interface to exchange information between the coprocessor and the CPU efficiently without too much of a hassle and overhead on both ends.(this is the tricky part)

a summing up, IMHO CpID is something the ISA designer should give very little thought to.
Because there is too much possible coprocessors we should not care what is on what CpID this is a worry for someone writing the software.(I am sure this comment is going to byte me in the future)
Wat we should care about more is that all co processors use the same uniform interface to communicate to the CPU no matter what they actually do.

The CpID is not a coprocessor ID it's an address, we should use identifier keywords to know what specific Coprocessor is located on what slot.(This should be done by software)

I don't think a separate DSP coprocessor would be necessary. It's easier to add DSP like functionality into the integer (main) processor. We tried to do that with instructions like ABS, PERM, SBcc, SELcc, SATS, SATU, MULADD, MULSUB. These are often used for codecs and gfx/sound processing as well which most of us like ;). An SIMD would add even more capabilities in this realm.

I think a way to query processor (including coprocessor) capabilities should probably be defined in the ISA. Most modern processors have this now. Perhaps it should be accessible (read only) without going into supervisor mode. I'm open to suggestions as I have not planned such an implementation.

You could add a identifier field on the general instruction type.

F-line
  1111

CpID
  000 - MMU, no external cycle!!!
  001 - Assemblers by default would use 001 for the FPU, could in/external cycle
  010/101 - free to assign
  110/111 - user defined

Instruction Type
  000 - Coprocessor General Instruction
  Coprocessor Conditional Instructions, handled by the CPU most of the times.
  010 - Branch on Coprocessor Condition Instruction cpBcc
  001 - Set on Coprocessor Condition Instruction cpScc, cpDBcc, cpTRAPcc
  100 - Coprocessor Context Save Instruction Format cpSAVE
  101 - Coprocessor Context Restore Instruction Format cpRESTORE

Type Dependent
  XXXXXX - Depends on the instruction type

There is plenty of room still, yet i wonder what 011 in the type field would mean.

I remember you guys talking about DSP but then 68k helper cores... whats the thinking on SIMD.. perhaps that is also beyond the scope of FPGA ?

Most 64 bit operations are fast enough even for a FPGA softcore. Shifts, multiplication and division requires more effort though. The real problem is making 32 bit operations as fast as possible...

Hm, Let's use a knife on the 68K addressing modes.
Make BCD optional.
and remove TAS and CAS instructions.
and maybe remove the F-Line codes too.

Pre and post indexed memory indirect could be removed from the ISA but the encoding reserved for compatibility. They could be trapped or implemented in hardware only where 68k compatibility is needed. For the complexity, they rarely save cycles or code size. They are useful when low on registers, especially address registers. Many of the ISA changes allow for better register utilization already. Allowing a single prefix to add 3 op instructions similar to Megol's idea could also save registers. On the other hand, the 68060 did implement these address modes but maybe because Unix/Linux used them so much. It's really easy to delete the lines for these address modes in the documentation but not as easy to add them back. All the other addressing modes I think are useful enough. Addressing modes are very powerful as they make most of the instructions more powerful. I don't think we need to "cut" much here. We do need to be careful that new addressing modes don't slow down the effective address calculation.

Marcel Verdaasdonk wrote:

Make BCD optional.

That's a good point. The BCD instructions are pretty weak and need not be in hardware. Again, the encoding space could be reserved for compatibility whether trapped or implemented in hardware.

Marcel Verdaasdonk wrote:

and remove TAS and CAS instructions.

I didn't document either of these instructions in the ISA but it would be good to reserve CAS.L, CAS2.L, and TAS for future use. They could be made optional as well.

Marcel Verdaasdonk wrote:

and maybe remove the F-Line codes too.

I didn't document anything in F-line or A-line. It could be argued that something like MOVE16 should be up to the implementation and it's requirements.

I'm thinking we should limit address register destinations to a longword size. This would simplify address register forwarding (no combining the old register with new) and effective address calculation without hurting the code density much with our word extended to long immediates. This would remove EXT.W An (extend byte to a word) at least.

There are several new instructions that need to be evaluated for usefulness. Some would not be common but are powerful or remove branches which is good.

Predecrement and postincrement have their uses like user space stacks.
But basically what i mean with this is that some of these could stall a pipeline which is a performance hit.

My personal goal for something like the 68kF1 would be speed and being a lightweight implementation of the 68K ISA.

I am gonna do some foul proposals here.
Remove memory to memory operations in favor of memory to register or register to memory operations to reduce bus load.

IMHO, MOVEP has a reduced usage outside the 6800 Compatibility area.
And i think i shall continue on a later time.

Marcel Verdaasdonk wrote:

IMHO, MOVEP has a reduced usage outside the 6800 Compatibility area.

Some drivers used it, actually.

So long,
Thomas

Okay let me explain myself on my eagerness to disallow mem to mem instructions. (Move is the only thing i would allow in this way to save registers)
It is very simple and easy, Memory access latency is a nightmare!!!
I hope that would clear that part up.
Seriously a destination address in mem requires a read and a write cache help elevate this problem to some extend by hiding it.
This is not a real solution, thus I rather see something cheaper on the gate count.

My personal goal for this would be speed and simplicity if neither is available dump it.
And no I am not giving advice this for use in the Natami, hm At best a Maid core perhaps.

However, from a pure pragmatic point of view, this is just not possible. At least mem to mem and movem are too popular to be removed. And I'm at this point not entirely sure about double indirection. Though rarely used, I believe they *might* be used even down in the mot FPSP and ISP codes, so the system emulation itself might depend on them.

If the goal would be to build an entirely new system that does not need to depend on an existing software library, that might work. But then using any other microprocessor would also work, and there are a lot more powerful processors on the market for a cheaper price than an FPGA, so I probably don't see the point.

Greetings from Bilbao,

Thoma

For the 68kF1 should follow that what i would say use the 68000 instructions and remove stuff like MOVEP, TAS, ABCD, NBCD, SBCD and then some more.
No new instructions, spartan like the word implies.

This should be the most simple implementation of the 68K just above coldfire perhaps.

No coprocessor support, so there should be no cc codes no F-line etc.