Full 68060 implementation?

[bloodline]

May I just remind everyone that the 68070 was a licenced clone of the 68k by Philips, with a few extra bits of hardware on the silicon.

[ChaosLord]

Can one skip out-of-order execution, super scalar, etc.. and still run 68060 code?

What are the minimum feature set that has to be implemented? (albeit slow..)

u can run normal 68060 code on 68020.
Or 68020+68881 FPU

And there is no Out-of-order execution in 68060.

[matthey]

Calling it 68050 was never cool.

It had new instructions (addressing modes) so if I wrote code for it things would get really messed up!

I could say "This game requires 68050+" but that would be a lie because it would not work on 060.

There can be multiple CPU lines by multiple manufacturers. You could say it requires N68050+ (The Motorola line was M68k). Another option would be to specify the ISA like "68kF1+". That is usually what happens with ARM where there are *many* manufacturers and processor names.

Adding new instructions or addressing modes is not cool. We need something that implements an 060, fpu & mmu in an fpga. I don't care if it's super scalar or supports out of order execution.

Why is it not cool to add new instructions and addressing modes? What if it can be done in a 99.999% compatible way and offer 5-15% speed and code density improvements at the same clock speed? The 68060 is missing some new features that modern processors have and some that would very much improved it. Also, it could be made to run ColdFire code with only minor changes. I can see focusing on making a compatible and tested 68020+ CPU first but there is good reason to modernize the 68k and we need ISA standards to do it. Do you think ARM or x86 would be where they are today if they had not changed? Were the 68020+ ISA changes a waste to you? Do you understand enough to have an educated opinion?

Can one skip out-of-order execution, super scalar, etc.. and still run 68060 code?

What are the minimum feature set that has to be implemented? (albeit slow..)

The code on a 68060 is generally not awhere of the superscaler execution. The 68060 resets with superscaler execution turned off and a bit in the PCR register (requires supervisor mode) must be turned on to enable it.

Out-of-Order (OoO) execution is a completely different concept to superscaler for parallel execution of the same code using units. Most modern processors use this but there are some very powerful exceptions. It generally makes better use of the executing units at the cost of complexity and size. No 68k or ColdFire CPU has ever been OoO that I'm aware of. There was talk of partial OoO execution for division on the N68k. This would allow non-depending instructions to execute while the costly division is calculated. I believe IBM has done something similar before.

[psxphill]

u can run normal 68060 code on 68020.
Or 68020+68881 FPU
 
And there is no Out-of-order execution in 68060.

I know, but
 
a) I'd rather actually see something that can run 68060 code, the extra effort to adding 68020+68882 instructions isn't a big deal to me. Time better spent on a 68060 compatible mmu.
 
b) Out of order execution is something that 68070 was going to have, but again taking time on things that aren't necessarily needed just means it never comes out.
 
Oh yeah, 68060 compatible cache would be good to.
 

Why is it not cool to add new instructions and addressing modes? What if it can be done in a 99.999% compatible way and offer 5-15% speed and code density improvements at the same clock speed?

It's just ego masturbation. The speed improvement isn't worth the effort and definitely not worth fragmenting the user base. Plus it wouldn't be so bad if it could actually run all 68060 code, but as they never implemented an mmu it can't.
 
The sane choice is 100% 68060 compatibility and nothing more.

[ChaosLord]

There can be multiple CPU lines by multiple manufacturers. You could say it requires N68050+ (The Motorola line was M68k).

That would be very confusing to many "regular Joes".
I don't want to spend time answering emails explaining the cpu naming system.

 Another option would be to specify the ISA like "68kF1+". That is usually what happens with ARM where there are *many* manufacturers and processor names.

That is better than calling it N68050.

Or we could just all it N68070 and be done with it

Altho the FPGAReplay guys will have theirs out first so it will be F68070 or R68070

[matthey]

a) I'd rather actually see something that can run 68060 code, the extra effort to adding 68020+68882 instructions isn't a big deal to me. Time better spent on a 68060 compatible mmu.

There were few user mode additions to the 68060 that made it incompatible to the 68020/68030. The only user mode instruction that I can think of is MOVE16 and it's not used by any compiler that I have seen. You can take 68060 optimized compiler code and run it on a 68020-68040 in almost every case, it just won't be quite as fast.

b) Out of order execution is something that 68070 was going to have, but again taking time on things that aren't necessarily needed just means it never comes out.

It was to be superscaler and not OoO except for possibly divide. It would not be considered OoO because of the divide although you could, maybe in the loosest sense, get away with calling a superscaler OoO hybrid.

Oh yeah, 68060 compatible cache would be good to.

Most code knows nothing of the cache nor does anything with it except to flush it for DMA or loading/modifying code. The main thing for Amiga compatibility is to have a selectable cache size if copyback caching is used, especially if the cache size grows as is likely for a new CPU. The 68060 had a 1/2 cache size setting that made it's caches the same size as the 68040 (which already broke many things compared to the tiny cache in the 020/030). The N68k was going to have writethrough caching only with bus snooping and auto invalidation of instruction cache writes (self modifying code) which would have given maximum compatibility for self modifying code.

It's just ego masturbation. The speed improvement isn't worth the effort and definitely not worth fragmenting the user base. Plus it wouldn't be so bad if it could actually run all 68060 code, but as they never implemented an mmu it can't.

The 5-15% speed increase would be the "average" of a program optimized for the 68kF ISA. It's not only possible, but likely IMO, that you could see a 25-50% speed up of some codecs including picture and video processing. The 68060 is missing (predates) a lot of speedups for this type of code.

A lack of MMU will not affect very much code. Most code that can use the MMU has an option for turning it off. The FPU is more important for user mode compatibility although an MMU may be needed for Amiga system reliability using the 68060. I would like to see an fpga MMU but the benefit on the Amiga is small as the AmigaOS doesn't use it.

That is better than calling it N68050.

Or we could just call it N68070 and be done with it

Altho the FPGAReplay guys will have theirs out first so it will be F68070 or R68070

The fpga Arcade CPU is already called the TG68. You better ask before changing the name on them . The N68k naming conventions probably don't matter anymore as the Natami is likely dead or the name (where the 'N' comes from) will be renamed by Thomas Hirsch :/.