Any missing features in 68060?

[matthey]

wawrzon wrote:
@karlos:

3) Allow address registers to be used for normal integer operations. There are times when you only need a few pointers but your code needs extra data registers.

this has been already taken care of in so called 050 core if i recall right what ive red on natami forum

Yep, as well as single instruction conditional branches. The idea is to add instructions that reduce code size without slowing down the processor. Smaller code is faster and one of the reasons why the 68k performs so well with so little. The best instruction set changes would be the same ones that the Natami team is making because if every 68060 softcore/emulator uses the same instruction set then there will be better support for all.

I would recommend against going 64 bit for the 68k. It really doesn't need the extra memory addressing with it's small code and with the byte, word, long modes it presents problems. Amiga data structures like tags (32 bit) could be a problem also. You either go big and fast or stay small and efficient. Optimizing for big and fast would also make existing 68k programs run slower while making small and efficient wouldn't have much of an impact on older programs.

The 68060 is really a very good processor at integer math with some very nice features. It has much of the modern CPU technology but with smaller caches and lower clock speeds which it doesn't need as much as modern RISC processors. If Motorola had made them at least twice as fast, there wouldn't be as many people using Amiga emulators :-).

[matthey]

alexh wrote:

matthey wrote:
Yep, as well as single instruction conditional branches.

Single cycle? Exceptionally difficult / impossible on pipelined processors.

I said single instruction not single cycle. The instruction would take the same number of cycles as an integer instruction and branch but would load faster as the instruction would take only 1-2 words instead of 2-5. It would decode to the same thing in the pipeline. Kind of like the dbra instruction. It only takes 1 cycle more than a branch which is the same as a subq with word (BCC) branch but loads faster and uses the instruction cache more effectively. It would be more useful if there was a short (byte) version of dbra that was 1 word, if it could use a long decrement register, and it stopped at 0 instead of -1. The down side is that the logic is a little more complicated to deal with extra instructions but as long as it doesn't add new levels of logic (decoding) it shouldn't slow things down much. 68k and PPC prove that all out simple single cycle RISC processors don't have as much of an advantage as they do in theory. RISC processors need large and fast caches and memory, and high clock speeds and still don't perform very well in some complex operations. The best processor IMHO is between a RISC and CISC with a simple logical medium sized but powerful command set.

matthey wrote:
The best instruction set changes would be the same ones that the Natami team is making because if every 68060 softcore/emulator uses the same instruction set then there will be better support for all.

Let's see them implement the existing instructions, cache, FPU, MMU etc. before making changes ;-)[/quote]

Agreed. They should have started with a 68020 emulator first and clocked it up with much larger caches and a branch prediction cache like the 68060. Superscaler would be super difficult to implement and might not have any advantage in a FPGA or emulation. Emulating a 68060 is no small task and it would be nice if they could get something out in less than 5 years even if it's not as powerful as a 68060. The time to do software development is often underestimated.