Die space for m68k on FPGA?

[ChaosLord]

DosBox with 68k Dynamic Recompilation should be able to achieve 386 emulation speeds on a fast 68060 or fpga 68k CPU. The bonus is that the Amiga can multitask at the same time kind of like the advantage of ShapeShifter over a real 68k Macintosh.

+9999

An enhanced fpga 68k CPU could support faster emulation of x86 by providing some useful instructions and addressing modes that the x86 has but the 68k does not.

Adding new instructions is easy.  Adding new addressing modes.... uhmm... you would just have to say that certain instructions are hardwired for this new addressing mode that you want?

[matthey]

The M68060 dispatches, decodes, executes, completes and writes the results of 2 instructions at the same time.

This applies to most of the common simple simple instructions.

It does not apply to gigantic complicated instructions or rare instructions.

You have been studying . It's not all done in parallel but more is than not. Code is sequential (in series) by nature so there are some limitations to parallel operation but the 68060 shows the proper way to do a Superscaler CPU.

Furthermore, it does 3 instructions at the same time, as long as 1 of the instructions is a correctly predicted branch.   Loops are common structures of computer programming.  The branch at the bottom of the loop will be correctly predicted the 2nd thru the nth times it is executed.

I don't know if it will correctly predict the LOOP branch the 1st time it is encountered.  But if you have a loop from 1 to 1000 then it will be correctly predicted 999 times out of 1000 which is a fairly good rate.

The 68060 has 4 execution units (2xinteger, fpu and branch) that operate at least partially in parallel. I believe you are correct with the 3 instruction per cycle max though. As far as loops go, there can be a slow down on the first loop iteration if the branch is not in the branch cache. There is a very costly misprediction on the last loop iteration as the branch falls through which can't be avoided. It would be possible to avoid sometimes with hardware help but not on tight loops.

68060 can dispatch two instructions at the same time, I don't think it decodes them at the same time.
 
...
 
I don't believe it can sustain 2 instructions per cycle for long before the fetch pipeline runs dry & that is if you can even find worthwhile work to do in instructions that can run in parallel.

See TCL's answer above and the 68060 documentation. The 68060 can sustain 2 instructions per cycle but it's impractical in most cases. Complex code is going to use some instructions that do not operate in parallel. The 68060 instruction fetch is 32 bits/cycle which is low but enough for 2 small instructions. Exceeding 32 bits of instructions per cycle usually does not cause a slowdown unless it's common. The 68060 is already a great CPU but it would have been a monster if they would have:

made MULS.W, MULU.W and SWAP as 1 cycle pOEP|sOEP (easy)
added MVS, MVZ and small longword immediate to word compression (see 68kF)
added a link stack

I would expect those moves alone would have been good for 1.5+ instructions per cycle in compiled code because they greatly reduce 68060 bottlenecks.

It's pipelined, while it can dispatch an instruction in 1 clock cycle and execute an instruction in 1 clock cycle. They aren't the same instruction that it's doing, you don't notice that from the point of view of the program until you get a mis-predicted branch.

I thought what TCL described was pipelined processing and correct. I didn't assume that the same 2 instructions were processed in all the pipelined steps at once. I don't understand his English as specifying this information.

Adding new instructions is easy.  Adding new instructions modes.... uhmm... you would just have to say that certain instructions are hardwired for this new addressing mode that you want?

No. I want to add the new addressing modes for all 68k effective addresses (EAs). The addressing mode in question and used in DosBox is base register update which the 68k does not have. I represent it in the 68kF docs as (bd,An,Rn*Scale)! with the explanation point at the end specifying to update the base register An with the calculated value. The EA is already calculated so there is little additional overhead. ARM also has this addressing mode and probably some other processors making emulation easier. The 68k addressing mode would be much more flexible and usable than the x86 addressing mode because the 68k has general purpose registers and more of them.

[Mrs Beanbag]

How would you encode it in the instruction?

[ChaosLord]

No. I want to add the new addressing modes for all 68k effective addresses (EAs).

Its been such a long time since I studied the addressing mode bits... I thought they were all used up?  How will u encode a new universal addressing mode?

The addressing mode in question and used in DosBox is base register update which the 68k does not have. I represent it in the 68kF docs as (bd,An,Rn*Scale)! with the explanation point at the end specifying to update the base register An with the calculated value. The EA is already calculated so there is little additional overhead.

"The EA is already calculated so there is little additional overhead."
hmmm.. maybe...
Due to the pipelined structure... it could be troublesome to code that in.  I am sure it can be done... with some trickery.  

 ARM also has this addressing mode and probably some other processors making emulation easier. The 68k addressing mode would be much more flexible and usable than the x86 addressing mode because the 68k has general purpose registers and more of them.

You have convinced me that it is a good thing to add in.

But the devil is in the details

The first thing Jens is going to say is "it messes up the pipeline structure and adds more complexity to the processing and I have to add another secret internal register to hold and forward the results and..."

[Mrs Beanbag]

move -(An),Dn
for instance, already updates the address register with the calculated value. So it shouldn't be too much trouble. It's the encoding that worries me, however I have the Motorola reference manual in front of me and it states that IS-I/IS values of 0100 and 1100-1111 are "reserved".

[ChaosLord]

move -(An),Dn
for instance, already updates the address register with the calculated value. So it shouldn't be too much trouble.

Good point!

They already forward results from the EA unit into an Address register after the instruction is complete.

There may be a limitation of requiring it to be an Address register in order not to stall the pipeline.  But no problems.

 It's the encoding that worries me, however I have the Motorola reference manual in front of me and it states that IS-I/IS values of 0100 and 1100-1111 are "reserved".

I seem to have forgotten what IS-I/IS means?

In any case: "Reserved" means "Reserved so we can use them".

[matthey]

How would you encode it in the instruction?

Preliminary 68koolFusion ISA:

  OpenOffice Writer
  http://www.heywheel.com/matthey/Amiga/68kF_PRM.odt
 
 
  PDF
  http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf
 
 
  html
  http://www.heywheel.com/matthey/Amiga/68kF_PRM.html

The addressing modes are at the top.

Its been such a long time since I studied the addressing mode bits... I thought they were all used up?  How will u encode a new universal addressing mode?

Nope. There is 1 free bit in the full format extension and then available I/IS encodings that were reserved. All new addressing modes are fully backward compatible. There is room to add addressing modes with scale > *8 or even (bd,An*Rn) which would be powerful but they would cause a slowdown, especially on an fpga. They might be fine in silicon if a longer pipeline was chosen although I don't like very long pipelines.

The first thing Jens is going to say is "it messes up the pipeline structure and adds more complexity to the processing and I have to add another secret internal register to hold and forward the results and..."

Only a wee bit more complexity and no secret internal registers (that's needed for LEA EA,Dn which would help x86 emulation also :/ ).

move -(An),Dn
for instance, already updates the address register with the calculated value. So it shouldn't be too much trouble.

Bingo. It does require 2 register writes but that is already needed on the 68k.

It's the encoding that worries me, however I have the Motorola reference manual in front of me and it states that IS-I/IS values of 0100 and 1100-1111 are "reserved".

Reserved is reserved for future ISA changes .

[psxphill]

In any case: "Reserved" means "Reserved so we can use them".

No, reserved means you can't use them. Especially for ones that raise invalid instruction exceptions that programs trap. There is software that uses the reserved line-a exceptions for example.
 
http://forums.sonicretro.org/index.php?showtopic=24409
 
If you don't care about compatibility then go ahead and add instructions that will make it not work properly, but then why do you want 680x0?

[ChaosLord]

There is room to add addressing modes with scale > *8

Ah yes!  I remember that.  I still want my *32 scalefactors!
Seriously I do want them.

[Mrs Beanbag]

I didn't spot bit #3 of extension word... in the docs it is simply '0'!

"Reserved" means Motorola might use them for something later... I guess they might come back and make a 68080 and then we'd be in trouble!

Although personally I think we're getting ahead of ourselves here... make a fully pipelined 680x0 + accelerator first, and worry about extending the ISA later.

[matthey]

No, reserved means you can't use them. Especially for ones that raise invalid instruction exceptions that programs trap. There is software that uses the reserved line-a exceptions for example.
 
http://forums.sonicretro.org/index.php?showtopic=24409
 
If you don't care about compatibility then go ahead and add instructions that will make it not work properly, but then why do you want 680x0?

There is some 68k software that uses a missing or invalid instruction to trap but they are very few and supporting them means no enhancements are possible. The 68020 ISA broke a fair amount of 68000 code but it was a very good enhancement. The 68kF1 ISA would break way less software than 68000->68020. Even 68kF2 would break less. If 99.999% of code runs then I'm happy. The rest can be patched.

A-line is not currently used by either ISA. The MacOS, Atari ST and others used A-line for system call traps. I don't know of any Amiga software that makes use of A-line except emulators.

Ah yes!  I remember that.  I still want my *32 scalefactors!
Seriously I do want them.

There is room for future enhancements. I want to be sure we don't slow down the EA unit before adding more CPU intensive EA processing. The most power would come from a multiply+add in each EA unit but it is also the most costly in CPU processing although fairly easy to encode. Scale factors greater than *8 are not too CPU intensive in silicon but are challenging to encode. It's doable but may require giving up some options of (bd,An,Rn) like sign extended Rn word sizes and/or not allowing some suppression. The encoding wouldn't be pretty and 68k EA consistency would be ruined or the instruction size would grow. Add to that that the EA unit would be slower in fpga and I'd rather skip it until someone smarter than me tells how and if it should be done.

I didn't spot bit #3 of extension word... in the docs it is simply '0'!

It takes a little studying to figure that out . I'm glad that you were able to understand my documentation. The 68000PRM was a little confusing in regards to addressing modes. The powerful addressing modes of the 68k are what gives her so much power.

"Reserved" means Motorola might use them for something later... I guess they might come back and make a 68080 and then we'd be in trouble!

Motorola/Freescale killed the 68k so that it wouldn't compete with PPC and created the low end ColdFire for microcontrollers and simple embedded uses. In the mean time, ARM Holdings created the less powerful, less programmer friendly, less code dense than 68020 variable length instruction ARM with Thumb 2 and it now sells at least 8 billion ARM processors per year and is used in 95% of smartphones, 90% of hard disk drives, 40% of digital televisions and set-top boxes, 15% of microcontrollers and 20% of mobile computers. Oh, Freescale pays license fees to ARM too. Maybe they were a little smarter than C= after all, they aren't bankrupt yet. Tech companies that stop innovating start dying. Freescale, Microsoft, Sony and Amiga Inc. are dying. Apple, Intel, IBM and ARM Holdings keep innovating.

Although personally I think we're getting ahead of ourselves here... make a fully pipelined 680x0 + accelerator first, and worry about extending the ISA later.

Compatible standards need to be in place before there are incompatible products. It also takes time to develop good standards and ISAs. Yes, making a fast 68k CPU is a higher priority but there are already several fpga processors that are quite capable. More than 1 means there is a possibility for incompatible enhancements.

I also try to have fun and innovate with the 68k communities help. There has to be some good ideas that are different than x86 and ARM.

[freqmax]

The Amiga and 68k platform is dead until someone provides a pathway to ASIC with high volume and low price for consumers. Because m68k on mobile phones would be cool and perhaps way nicer to program.