Gunnar von Boehn wrote:

I have some information for you. The 68K CPU development is going to be separated out from the Natami into its own project. The goal of the CPU team is to bring the core to market now. The CPU team is relative small but focused. We are 3 HW developers. I would like to also get 2 good software views into the boat  - to be able to discuss features and ideas from a wider angle.

I started to document a new 68k ISA with ideas that our Apollo Team came up with on the Apollo Forum that Gunnar created. We never planned to keep all the ideas but the documentation allows us to better evaluate ideas. Gunnar stopped posting to the Apollo Forum several weeks ago leaving the team in limbo. I believed that I was helping create a new 68k ISA unaware that the whole fpga softcore team and development had not split off from the Natami. I think our team came up with some good ideas that would be useful. I think we need a new 68k ISA to standardize enhancements made to 68k fpga softcores (not just N68k or Apollo) for compatibility and ease of development. Maybe a future ASIC could be burned as well.

I hope to have some discussion about the new ISA. Nothing is set in stone yet. The first question is what name to use. I have come up with 68koolFusion (68kF for short) but it can easily be changed if someone comes up with a better name. Cool spelled starting with a k is not uncommon here in the U.S. and has the same slang meaning (fun, neat, interesting, hip, good, excellent, elegant, sophisticated). The small case k represent 1000 of course as in 68000. Fusion is for the fusing of ColdFire instructions and other new ideas ;). I didn't find any other use of the name so copyright or trademark infringement is unlikely. The different versions could be 68kF1, 68kF2, etc. and they could be specified to a compiler or assembler in that way.

I have put a copyright on the ISA and documentation because we can't have people modifying a standard (beyond what is permitted) as it would defeat it's purpose. It would be better for some standards organization to hold the copyright and I would be willing to turn it over if an appropriate one was ever created. The documentation would of course be free to distribute and add notes and the ISA free to implement. The documentation is in OpenOffice Writer format. I have created html and PDF formats from this which are quite large and some formatting is lost.

OpenOffice Writer
EXTERNAL LINK 

PDF
EXTERNAL LINK 

html
EXTERNAL LINK 

One of the changes is allowing for immediate 16 bit extended to 32 bit values almost everywhere and would be done automatically where a size for the immediate is not specified. This can improve the speed, code density and/or register utilization (no more trash register with moveq+op). The 68kF2 ISA has OPI.L instructions with 16 bit immediates extended to longs but it replaces the instructions CMP2, CHK2, CAS.B, CAS.W and CAS2.W. These instructions would not be added to a modern processor (CAS.L would and CAS2.L might but they could be reimplemented later), are good candidates to delete (most already trapped on 68060) and are very rare on the Amiga. These old instructions would no long be trappable and would limit maximum 68020+ compatibility so they are not implemented in 68kF1. Any other modifications that could allow 68kF1 to be adopted by the likes of the TG68 or other retro cores will be considered.

There isn't much encoding space for 16 bit instructions. Many of the 32 bit instructions have been split from existing ones. I hope this doesn't cause muxes or other slowdowns. I would like to hear performance considerations or enhancement encodings for any ideas. Some instructions are not documented but would still be supported of course. I can add any missing instructions that should be in the ISA.

Address registers are opened up and allowed where possible. This does create some questions about setting the CC. I currently have the CC documented as not being set with a destination address register except for Bxxx, BF, MUL and DIV instructions. Read the descriptions of these instructions before telling me that all destination address registers should not set the CC. Operations to an address register would probably have to be longword operations which I don't have documented. It might be better not to allow some operations if they are more trouble than they are worth. I'm open to ideas.

The SATS/SATU instructions would need some additional logic to make happen with MUL and DIV which don't set the overflow on the ColdFire. Setting some (hidden?) CC bits when the overflow CCR[V] bit is set that represent signed/unsigned underflow may be necessary. The other option is using an unused bit in MUL and DIV to turn on saturation. There is no free bits in ADD or SUB and there multiple variations. New saturated ADD and SUB instructions could be created is the other option. I created the MULADD/MULSUB as 32*32=32 only because that is the only MUL that can overflow and would require 2 saturations yet is common. This needs evaluating.

The new shift and rotate instructions could be handled like:

1) Add the new 68k shift/rotate instructions with a new name (currently I and R forms).
    a) Allow the old form of shift/rotate to be upgraded to the new form when there is a limitation that would normally generate an error.
    b) Make the programmer specify the exact instruction wanted with no promotion/aliases.
2) Put the old and new shift/rotate instructions together using the same name and document the 2 different encodings. This is how the 2 different forms of shift/rotate work currently using the same name (i.e. LSR #<1-8>,Dn and LSR #1,<ea>) but only 1 encoding is possible for any given syntax unlike the new shift/rotate instructions.
3) Rename the existing 68k shift/rotate instructions with a q (for quick) on the end (i.e. LSR -> LSRQ). Add the new shift/rotate instructions with the old names but optimize to the old "quick" versions where possible (if no Q suffix on the instruction, count<=8 and destination Dn).

I don't like option 2 and I'm starting to like option 3 more as it's the way the 68k might have been done if it was created today. It would be possible to simplify this with rotate in 1 direction and combine lsl and asl. Large shifts are the biggest gain and moving while shifting is nice.

SBcc and SELcc were added because a CMOVcc (conditional move) type instruction and branch predication do not work well when the base register is updated. I think they are a good fit.

Some instructions are simplified mnemonics (aliases) as PPC would call them. Some ColdFire instructions are remapped FF1->BFFO, BYTEREV->PERM, BITREV->PERM, etc. Have fun with PERM. It's quite powerful and kool ;).

We never started to discuss addressing modes so I don't have anything there yet. Any questions, ideas or comments (likes or dislikes)?

Gunnar did mention that the memory indirect post and pre indexed modes would likely be trapped because they are difficult to implement in a superscaler environment. The 68060 did manage to get them working in HW though. They would be the least used of course. They might be useful (especially C++ programs) if they were fast enough and if they worked ok with superscaler. At least the Amiga doesn't use them much. I bet some Unix/Linux systems back in the day used them a lot.

When fpga implementations start adding their own extensions it's too late to have a standard. The last thing we want is something like x86 AMD and Intel extensions. I am attempting to create one easier to implement and more 68k compatible 68kF1 ISA with a more powerful, consistent and modern 68kF2 ISA that can continue into the future and maybe even compete with ARM. Developing a good ISA takes time and having one ready when needed would save time for developers using it. Thanks to Gunnar, much of the work is already done too :/.

The ISA is different than the processor name. 68k never made a distinction but ColdFire has ISA_A, ISA_B, ISA_B+ and ISA_C while the processors are mcfxxxx or mxxxx. It also has generations like mcfv1, mcfv2, mcfv3, mcfv4, mcfv4e and mcfv5 which are usually used instead of specifying the ISA. We would have ISAs of 68kF1, 68kF2 with processors names of N68050, N68060, TG68, Apollo etc.
   

As for those addressing modes i shall try and device a clean way to get them super scalar no promises.

btw, matt, a guy is working on netbsd drivers for mediator, which are simultanously ported to aros. in case you are interested in that. as yet mostly 1200 models are supported, but im going to join testing 4k. 

I agree that having a LSLQ and LSL as separate encodings which was plan 3.  That way the old software will still see the LSLQ as a small shift, which was what it always was, and just ignore the new full-width LSL instruction which it shouldn't be aware of unless it's recompiled anyway.

As for the usage of VTables in C++, the Amiga uses a different encoding in its shared libraries anyway.  As you probably know, we get JSR (negativeOffset, A6) to an address which contains an absolute jump instruction.  C++ compilers programmed to use the Amiga ABIs should not need the extended addressing modes.

Implementing multiple inheritance is as easy as putting an additional library handle in the address space of the original library handle and doing a JSR (negativeOffset, A3) to the interface handle and have the library heap still at the positive offsets of A6, and the locals at the positive of A3.  The class library would have to be marked as such so that the implemented interfaces inherited will be obtainable as marked in A3.  I'd suggest using a small hash table in the positive offsets of A6 so that the interfaces can be named.

Samuel D Crow wrote:

I agree that having a LSLQ and LSL as separate encodings which was plan 3.  That way the old software will still see the LSLQ as a small shift, which was what it always was, and just ignore the new full-width LSL instruction which it shouldn't be aware of unless it's recompiled anyway.

Yea, old software wouldn't know about the new instruction and would continue to generate what we would now call LSLQ. New software would use LSL and let the assembler optimize to LSLQ where possible which also works. It works well until a programmer loads an old assembler program into the new assembler environment (new ISA) without optimizations on (vasm default) so the longer LSL would not be converted to LSLQ. One solution is to turn on optimizations for LSL->LSLQ as the default when a 68cF ISA or CPU using it is selected. That might be the best solution. It would be the way it should have been from the beginning (a word shift of 1 in memory was powerful back then 8) and it would simplify the documentation by combining the LSLI and LSLR into LSL. We'll see what others think before I go changing things around though.

Samuel D Crow wrote:

As for the usage of VTables in C++, the Amiga uses a different encoding in its shared libraries anyway.  As you probably know, we get JSR (negativeOffset, A6) to an address which contains an absolute jump instruction.  C++ compilers programmed to use the Amiga ABIs should not need the extended addressing modes.     Implementing multiple inheritance is as easy as putting an additional library handle in the address space of the original library handle and doing a JSR (negativeOffset, A3) to the interface handle and have the library heap still at the positive offsets of A6, and the locals at the positive of A3.  The class library would have to be marked as such so that the implemented interfaces inherited will be obtainable as marked in A3.  I'd suggest using a small hash table in the positive offsets of A6 so that the interfaces can be named.

Going through a jump table is slow. I believe it's possible to use the indirect addressing modes here also:

    jsr ([function+2,A6]) ;6 bytes 8+ cycles

The normal way (jsr+jmp) of going through the jump table looks like it's barely faster on the 68060. Both ways are pretty slow though. I don't think it would be any problem to trap the memory indirect pre and post indexed modes with our CPU library always available in flash memory. If there is never an advantage to them, then it's probably better to get rid of (trap) them.

None of the ISA instructions are in F-line or A-line. We left out the ColdFire MOV3Q and MAC instructions in A-line. 68k MAC software emulation should work with 68kF1 and may work with 68kF2 or may require some patching. Motorola did use F-line (coprocessor) instructions which are more 68k compatible but eat up FPU and SIMD encoding space. MOVE16 is F-Line as are the CPU32 table instructions. I don't like the encoding for MOVE16 and I don't like how the table instructions are implemented. We did look at MOVE16 and possibly a MOVE8 as well. It would be easy to document MOVE16 in F-line as the original. It's probably not a priority but a move that avoids the caches on large copies is probably more important with large caches and more memory. MOVE16 is implemented a lot like a separate coprocessor so maybe that makes it ok?