The 68050/070 will be incredibly powerful with any 2 cycle to 1 cycle gain, I mean, that's a 100% performance boost!

Also, we will have the FASTEST Amiga, and Atari ST and Falcon TT, as well as the fastest Macintosh that was ever made, too! And, we all know that some SW on the Mac was better than Amiga's only because they had a bigger market share than Amiga and their customers bought that expensive SW.

The NatAmi is going to be simply amazing!

No, the mac was nowhere near as popular as the amiga. The difference is that the Amiga was complete failure in the country where good productivity software comes from, and the mac was only slight failure.

But it is true that extra registers might be a problem as they would have to be saved in a context change and old software is not aware of it ... so might be that we have to use known registers for that.

We will run into similar problems for selected SIMD instructions as we will need vector registers for this, and that will be a lot of data so save on context switches; any ideas?

You mean a MAX instruction?
Like: MAX.L D0,D1  (D1 will hold the bigger of D0 and D1 ?) 
How important is this in your opinion?

Denis Markovic wrote:

We will run into similar problems for selected SIMD instructions as we will need vector registers for this, and that will be a lot of data so save on context switches; any ideas?

How about overlaying FPU and SIMD registers?

Lets say we use the "A"-Line as extention code.
This gives us 12bit extention which we coul add to any existing instruction.
With this extension it would be possible to:
1) make every instruction conditional
2) add a 3rd parameter in the same time
3) Extent the existing parameters by 1 bit.

This means we could either have every instruction be able to use all Registers equally. This means all instructions could update Address registers and all Addressmodes could use Data-Registers as pointers.
Another option for using this extra bit would be to double the number of registers. 16 Data + 16 Address.

I know these ideas where proposed here before.
Using the A range would allow to do all of them at the same time.

Crazy?

Tempting for what it would add but a big fat NO for compatibility, simplicity and code bloat. You have already touted the virtues of the 68k operating in memory without registers and your code fusion eliminates the need for 3 operand instructions. Leave the 3 operand and conditional instructions as internal representations only please. Save the register expansion and semi-SIMD 3 operand instructions for the FPU.

I find more useful a "SHUFFLE" instruction that let you permute the data in several ways, replacing also the SWAP, ROL.W #8, and other instructions mix to place datas in the place you want them to be.

ORC    Or with Complement

I don't see a use case.

I find more useful a "MASK"/ANDC which calculates negated AND, in order to apply data masking, which is much more useful.

It will also be more backward compatible with software which was already written.

It'll be perfect for such purpose, giving a clear and flexible design.

Also, I think it'll be much more useful than an ABS instruction.

With the Cortex family a brand new, and independent, SIMD unit (NEON) was introduced, to solve the same problems in a much more convenient and elegant way.

So why we want to make the same mistake?

Why should this be a mistake - its clever!
And others like ARM did it also just recently.

INTEL had different problems.
INTEL real problem was that you could not mix MMX and FPU code.

Anyway, I don't like opcode prefixes. It sounds like an x86.

Also, doubling the registers isn't so much useful, and introduces problems such as providing the necessary extension bits to instruction which uses more than 2 registers (long multiplication, bit fields) and the register indirect addressing modes which uses 2 registers.

For me it's a wast of useful opcode space. Also, it resembles a new ISA to my eyes, which doesn't look very well comparing to the 68000 family tradition.

A 64 bits SIMD unit is anachronistic right now.

And others like ARM did it also just recently.

On the contrary: ARM introduced a brand new SIMD unit, NEON, which brings its independent register set.

INTEL had different problems.   INTEL real problem was that you could not mix MMX and FPU code

Yes, it was another problem. But not the only one.

I was not thinking of 64 bit.
From the programming view FPU register behave already like being 96 bit wide.  But as mentioned before extending the FPU to 128 bit would make good sense. 128 bit would also improve the performance of saving / restoring the FPU as they could then be better bursted out.

What happened to the single precision only fpu idea for speed? You went from 32 bits to 128 bits now for the fpu register? Realistically, at least 64 bits is needed for compatibility and the C double and a few extra bits are needed beyond that for rounding. That's what the 68k FPU did but 96 bits isn't so great for alignment. It would be nice to support the new quad precision (binary 128) IEEE format even if the least precise bits were set to 0. The 15 bit biased exponent is already the same as for extended precision. It would make compiler support for the long double easier. Adding the half precision would reduce code size and be good for some gfx applications. The word format isn't a problem for CISC. Full support for IEEE binary formats is good for marketing as well.