Motorola 68060 FPGA replacement module (idea)

[psxphill]

Actually, this may work in parallel. Some very simple instructions are retired early and the longword (only) result made available early. This is not specifically stated but the result is made available early from these types of instructions for change/use stalls and are probably also available early for the other OEP although it's not specifically stated. These early retirement instructions include:
 
lea
move.l #,Rn
moveq
clr.l Dn

The list is unclear, I'm assuming the first 4 are the primary and the last 2 are secondary.
 
"Certain instructions have been optimized to ensure no change/use stall occurs on

subsequent instructions. The destination register of the following instructions is available
for subsequent instructions:
lea
mov.l&imm,Rn
movq
clr.lDn,
any op(An)+
any op–(An)
as a base register for address calculation with no stall, or as an index register for
address calculation with no stall, if Xi.l*{1,4}. If the index register used is Xi.l*2, Xi.l*8,

or Xi.w, then the previously described 3 cycle stall occurs."

It doesn't have to retire it early, the second pipeline could look in the primary pipeline. Mips has a similar handling for lwl/lwr opcodes, it pulls the register value from the pipeline and stops the register being updated at all. The register doesn't actually get updated until you stop executing lwl/lwr opcodes.
 
This one is also vague:
 

"The MC68060 provides another change/use optimization for a commonly encountered
construct—when an address register is loaded from memory and then used in an operand

address calculation, the OEP experiences a one cycle stall.
 

mov.l,An

"
 
I guess they both enter the pipelines at the same time, the primary goes through ea fetch and then on the next clock the secondary goes through ea fetch. I'm assuming that the ea on the second register is literally ea and not adjusted by an immediate or register. It can't advance the pipelines, it must change the state it's in. The primary pipeline might be translated into a move.l immediate once the value is available, to make the short circuiting common.
 

If one start with the instructions and then try to impose the correct architecture.. well it could be messy

With any processor emulation, it's always worth starting small and bringing it up an instruction at a time until you know you're on the right track.
 
[/FONT][/SIZE][/FONT]

[matthey]

The only thing I can find is this:
 

"If the primary OEP instruction is a simple “move long to register” (MOVE.L,Rx) and the destination register Rx is required as either the sOEP.A or sOEP.B input, the MC68060 bypasses the data as required and the test succeeds."

Which says it's only for move.l, although I guess the others could be translated. It doesn't have to retire it early, the second pipeline could look in the primary pipeline. Mips has a similar handling for lwl/lwr opcodes, it pulls the register value from the pipeline and stops the register being updated at all. The register doesn't actually get updated until you stop executing lwl/lwr opcodes.

There are at least 2 different optimizations here. One is the early instruction retirement and register forwarding. The other is more of a MOVE.L+OP.L optimization which is possible because MOVE.L is only half an operation in a register memory architecture that can do both in 1 operation. The Natami processor was planning to use instruction fusing/folding to handle most of these cases. The non-superscaler v4 ColdFire probably does too:

"Last, ColdFire v4 is smart about collapsing commonly used constructs into a single operation. If two instructions will execute in different stages and have no dependencies, they will execute together in a single cycle. This “instruction folding” is ColdFire’s first move toward superscalar dispatch."  -ColdFire Doubles Performance With v4 by Jim Turley

The M68060UM is less than clear about these optimizations, even if understanding how these types of optimizations commonly work. Editors usually make this stuff worse than what the engineers started with too. I can say I don't fully understand and I have better knowledge than most people and experience with coding the 68060. By looking at code compiled for the 68060, it looks like many compiler programmers didn't understand either. Most 68060 optimized code doesn't do much except replace some trapped instructions, if that.

[freqmax]

That's a big part of why "they" moved away from hardwired control units in favor of microcoded control units. My own education thus far was about hardwired style, which is very dependent on the instruction set. I was hopin gto take the advanced followup course now, but it wasn't on the schedule. I'm trying to go through the Coursera one now, which is pretty advanced. Not sure if they explain microcoding or if that assumes you already know it. Going to try and find some time to read up on it more regardless.

Microcode adds more clock cycles per instruction. Or at minimum latency.
(which will then impede clock increases)

[ChaosLord]

I think you mean Bcc.L and BSR.L. Branches up to 16 bit were supported on the 68000. The longword branches are big savers but only on fairly large programs. Not too many assembler programmers create programs >65k.

It's signed so plus or minus ~32k.

I need to make some kind of rule not to write msgs after my beddy bye time

Either that or this is what happens when u don't write any asm code for 4 years... ur brainz turn 2 mush.

The thing is I used to spend many many many hours trying to optimize my code to replace all bcc.w with bcc.b so you would think I would remember that.  For some years (back in early 1990s) I was like Phil, all hardcore 030, 256 bytes of L1 instruction cache optimizing and I would code separate routines for 000.

[ChaosLord]

By looking at code compiled for the 68060, it looks like many compiler programmers didn't understand either. Most 68060 optimized code doesn't do much except replace some trapped instructions, if that.

Which compilers even have an 060 option?

I can't remember SASC even having such an option.   Or maybe it does and I just don't use it...

[ChaosLord]

How common are the bitfield instructions in real code? I never use them.

Every time I ever wanted to use Bitfield instructions I would consult the timing charts and it was always faster to just do things the RISCy way and not use bitfield instructions.  So I have never used them.  I just use good ol' ANDing and ORing.

Phil published some results of bitfield usage years ago on Natami.net.  It turns out that bitfield instructions are used a surprisingly large amount in certain softwares.  Dungeon Master was one.  And various other games that were ported from other systems.

[psxphill]

There are at least 2 different optimizations here. One is the early instruction retirement and register forwarding. The other is more of a MOVE.L+OP.L optimization which is possible because MOVE.L is only half an operation in a register memory architecture that can do both in 1 operation.

Passing register results pass between pipelines is a pretty standard concept, what I don't get is if it's going to introduce a one cycle delay when running these two at the same time:
 

mov.l,An

"

Then why wouldn't you just run both operations sequentially on the primary pipeline?

[RobertB]

I know some people are using OS2.04 on this device (well, at least they claim they are!)

Heh, that's what I asked our MCC-216 expert Matt B. the other night... if he could get OS 2.04 working on it.  

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
Southern California Commodore & Amiga Network
http://www.sccaners.org

[freqmax]

Which compilers even have an 060 option?

gcc version 3.3.3 has these options:
-m68000 -m68020 -m68020-40 -m68030 -m68040 -m68881 -mbitfield -mc68000 -mc68020 -mfpa -mnobitfield -mrtd -mshort -msoft-float

But perhaps SAS C has something more specific?

[matthey]

Which compilers even have an 060 option?

GCC, vbbc and SAS/C have 060 options. That should cover 90%+ of Amiga compiling.

I can't remember SASC even having such an option.   Or maybe it does and I just don't use it...

Check your SCoptions. It's there or you are using an old version of SAS/C.

Every time I ever wanted to use Bitfield instructions I would consult the timing charts and it was always faster to just do things the RISCy way and not use bitfield instructions.  So I have never used them.  I just use good ol' ANDing and ORing.

If you are looking at the 68060 timings then yes, they are slow compared to the shifting and logic instructions. BFFFO is an exception to keep in mind. It replaces a loop with the last iteration costing 7 cycles on fall through. If there was enough encoding space and a logical place to put them, I would have done a BFPOPCNT/BFCNTO and possibly a BFFind (find a binary sequence in a BF which could also be used as a BFCMP) for 68kF which would also replace loops/branches. These are a little bit more difficult to use by a compiler but good for specialized code like codecs and decompression. BFCHG, BFCLR, BFEXTS, BFEXTU, BFINS, BFSET and BFTST are simpler but very easy for a compiler. They would be a compiler writers dream come true if they were fast.

[psxphill]

gcc version 3.3.3 has these options:
-m68000 -m68020 -m68020-40 -m68030 -m68040 -m68881 -mbitfield -mc68000 -mc68020 -mfpa -mnobitfield -mrtd -mshort -msoft-float
 
But perhaps SAS C has something more specific?

I'm pretty sure the latest SAS/C does, but it's not good. I found gcc 2.95 with -mc68000 was faster on the projects I tried.
 

BFCHG, BFCLR, BFEXTS, BFEXTU, BFINS, BFSET and BFTST are simpler but very easy for a compiler. They would be a compiler writers dream come true if they were fast.

Probably, but with so little code using them they wouldn't be my first choice for optimising.

[freqmax]

I'm pretty sure the latest SAS/C does,

I would like to know what options SAS-C has

Anyway I checked out gcc v4.2.1 (slightly unsure on version) which has the options:
-m68000  -m68020  -m68020-40   -m68020-60  -m68030
      -m68040 -m68060  -mcpu32  -m5200  -mcfv4e -m68881  -mbitfield
      -mc68000  -mc68020 -mnobitfield  -mrtd  -mshort  -msoft-float
      -mpcrel -malign-int   -mstrict-align   -msep-data  -mno-sep-data
      -mshared-library-id=n  -mid-shared-library  -mno-id-shared-library

-m68060
      This option inhibits the use of 68020 and 68881/68882 instructions
      that have to be emulated by software on the 68060.  Use this option
      if your 68060 does not have code to emulate those instructions.

As the 020, 030, 040 options doesn't mention the omission of any instructions. It seems the 060 is the only m68k CPU to have less instructions than it's predecessors.

[psxphill]

As the 020, 030, 040 options doesn't mention the omission of any instructions. It seems the 060 is the only m68k CPU to have less instructions than it's predecessors.

The 040 has less FPU instructions, the 060 is the first to drop integer instructions.
 
"-m68040 Generate output for a 68040. This is the default when the compiler is configured for 68040-based systems. This option inhibits the use of 68881/68882 instructions that have to be emulated by software on the 68040. Use this option if your 68040 does not have code to emulate those instructions."
 
I don't know whether it's less:
 
"-m68020-40
Generate output for a 68040, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68040.
-m68020-60Generate output for a 68060, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060. "

[matthey]

As the 020, 030, 040 options doesn't mention the omission of any instructions. It seems the 060 is the only m68k CPU to have less instructions than it's predecessors.

If you are talking about integer instructions then yes. The 68040 FPU did remove from hardware most 68881/68882 instructions (which compilers were using and became very slow if used). Most of them are not used often and the 68040 FPU is enough faster than the 68881/68882 for common operations that no slow down will be noticed. The 68060 removed a few more seldom used 68040 FPU instructions but added back the commonly used FINT and FINTRZ. This was a smart move to correct a big mistake in removing them from the 68040 FPU.

[mongo]

The 040 has less FPU instructions, the 060 is the first to drop integer instructions.

The 030 dropped CALLM and RTM that were present in the 020.

[freqmax]

Why were these instructions dropped?

And would be more efficient performance wise to implement a 020, 030, or 040 and then horrendously overclock it?