Any missing features in 68060?

[alexh]

bernd_afa wrote:
this help only on fullscreen video and no GUI

Doesn't have to be.

but with GUI, the whole AOS need change to convert the output to the new format.

No more than an RTG gfx card with Y'CbCr overlay.

[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

[Karlos]

@bloodline


You're talking my language, reggie!

*points at sig*

[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! ;-)

[Karlos]

Well, I'm enjoying the benefits of an x64 as I post. I didn't get where I am today without enjoying the benefits of an x64 whilst I post.

But, we're not one of those dreadful organisations that thinks an architecture is obsolete just because it isn't enjoying the benefits of an x64. Goodbye Reggie!

[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:

[Karlos]

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.

[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

[Karlos]

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.

[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 :-)

[wawrzon]

@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

[Karlos]

bloodline wrote:

...and let XCode and SDL worry about the hardware...

Eww. Bloody mac deviant. What's wrong with plain old gcc ? ;-)

[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 :-).

[alexh]

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

Single cycle? Exceptionally difficult / impossible on pipelined processors.

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 ;-)

[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.

[Karlos]

Strictly speaking, is an FPGA implementation of an architecture considered an emulation?