Any missing features in 68060?

[bloodline]

Karlos wrote:
A few suggestions that I think might be fun

1) Expanding the register width to 64-bit. You'd need to devise a new set of opcodes to support operations on them, however.

I'd mode it out like the x86, with a Long Mode. That way the 68k instruction set and architecture could be stripped of all those performance crippling addressing modes and remove all the dead weight instructions... :-)

2) Saturation arithmetic would be an interesting addition, especially for graphics manipulation.

Hmmm... just add an off the shelf SIMD unit, that can be used in "Long Mode"

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.

In Long Mode, all registers are equal, and 64bit ;-)

The problem with all of these is finding an efficient way to implement them that preserves backwards compatibility.

Long Mode... :-D

[bloodline]

Karlos wrote:
@bloodline


You're talking my language, reggie!

*points at sig*

I didn't get where I am today by looking at sigs! ;-)

[bloodline]

An interesting topic would be what this new "Long Mode" would look like... also are there any reserved/unused bits left in the 68k status register that could be used to signal which mode the CPU should be operating in?

-Edit- A quick look at my 68k manual, suggests that bit 11 is free for use in the system bye of the SR... sorted :-)

If I'm really honest, I'd want an ISA/Programming model very similar to the x86-64 as I really like it  :roll:

[bloodline]

Karlos wrote:
I'd actually like an architecture that only has SIMD registers, but still allows "normal" operations on them.

To enable this, each instruction could support a "mask" where a 16-bit word describes which sub elements of the register pair in an operation are to be affected.

Consider this pseudo example (assumes 128bit wide registers):

add.b r0,r1

This would add the "bottom" byte in r0 to the equivalent byte in r1, leaving the rest of d1 unaffected.

Whereas

add.b r0,r1,#FFFF

would add perform the same operation on every byte and

add.l r0,r1,#A

would pefrorm a 32-bit add on the highest and middle words, leaving the rest unaffected.

One obvious complication would be the status flags. You'd probably want up to 16 of them in this instance. However, in every VM I've written for fun, I never bothered implementing condition code flags, relying instead on compare two operands and branch instructions.

Could you not write a Macro Assembler for your shiny new x86-64 that assembles a Pseudo Assembly language (something close to the 68k asm we know and love) into only SSE3 instructions... using the traditional x86 instruction set only when absolutely necessary... it might be a fun proof of concept?

-Edit- Yeah lose the CCs... the Alpha never had them :-P

[bloodline]

Karlos wrote:
I haven't actually gotten into x64 coding yet. I'm still having too much fun with CUDA. Performance wise, PTX makes SIMD look hopeless.

I stay as far away from ASM as possible now, and let XCode and SDL worry about the hardware... but I downloaded the Intel EMT64 docs and read them in detail to ensure I had an understanding of what is going on on a modern x86-64 system... the x86's mmu is a work of genius :-)

[bloodline]

Ok, I did a quick search on google for softcore and what came up was not exactly what I call IT related .. so anyone can explain to me what softcore (the IT type) is?

Regards,
Sim085

p.s. - please don't laugh.

An FPGA description of a CPU core... Which can be used to synthesize a CPU using an FPGA.