Motorola 68060 FPGA replacement module (idea)

[psxphill]

(we don't even know how the 68060 deals with these very long encodings).

What do you mean? AFAIK the longest instruction is 10 bytes and that is what gets transferred from the FIFO in the decode stage.
 

Right, simplifying the decoding stage wasn't the idea so much. But if you can split a problem into two parts, it is usually easier to solve. I'm trying to make the developer's job easier really.

I think you'd either have to put up with it being slower, or making the rest of it much more complex to compensate. It's a juggling act.

[matthey]

The advantages are that each part can be developed, tested and optimised separately, and indeed the RISC core could conceivably be useful on its own (and an assembler could be modified to compile 68k asm to run on it). It would be easier to add new instructions, much in the same way that microcode does, but the "microcode" in this case is more readily understandable, being 68k-like itself.

Hmm. Why not just use JIT in UAE then? The 68k code does make a nice compressed cross platform intermediate language (it's much better than Android or Java byte code). If the time is taken to optimize the RISC JIT emulation, then it will probably perform almost as well as native RISC code that is not optimized. Optimizing compilers for RISC were supposed to give it the advantage but that failed. I remember reading 15 years ago how the PPC processors of the future would have compilers to add all necessary cache hints, align all data, schedule all instructions properly and optimize most branches. Funny thing is, a PPC assembly language programmer can still beat PPC compiled code in most cases. The not so funny thing is, most computer scientists and engineers stay with this same failed philosophy .

What do you mean? AFAIK the longest instruction is 10 bytes and that is what gets transferred from the FIFO in the decode stage.

   move.l ([xxx.L,a0],xxx.L),([xxx.L,a1],xxx.L])  ;move.l , 2x double memory indirect

1 word for move.l
2x1 word for full extension word
2x2 words for inner longword displacement
2x2 words for outer longword displacement
----
11 words total = 22 bytes

The 68kF ISA would do away with the outer displacement option which reduces the maximum instruction length to 7 words or 14 bytes. Do you see any mistakes?

[Mrs Beanbag]

I don't think so... the Dn,Dn instructions are fairly trivial to translate, ,Dn and Dn, instructions need to wrap an instruction with a load and/or a store, I don't think that would be hard. I think it would be simple to get something to work (minus the nastier addressing modes mentioned above), maybe difficult to properly master to get the most out of it. It's perhaps a bit like Arm + Thumb, which seems to work well enough.

I'm thinking of using 32 bit instruction words, which encode either a single move/lea operation, or a pair of register-only operations that can run in parallel. I call this "explicit superscalar". To give you an idea of how that might work, for example an "exg D0,D1" operation can be synthesised as

move.l D0,D1 ; move.l D1,D0

So kind of like VLIW but not "very long". Finding operations to pair would be the job of the instruction translator, that part might be tricky but the RISC core itself would be simple.

One could also do other tricks, like if you have

add D0,D1
move D1,D2

usually this would have to take (at least) two cycles, but one could use a right-hand side instruction that simply writes the result of the left instruction elsewhere, like this:

add D0,D1; write D2

The other thing that occurs to me is you could translate the code into the cache upon reading, so that it would function as a JIT.

[Mrs Beanbag]

Hmm. Why not just use JIT in UAE then? The 68k code does make a nice compressed cross platform intermediate language

I guess that's not too far from my idea, now I think about it, but with a CPU core specifically designed to emulate 68k. Sort of a hardware emulator, I guess.

I don't like such things as out-of-order execution, I can't see how it can save you very much compared to optimising the code properly, at least for the massive amount of extra logic required. My favourite CPU is still the UltraSparc T1.

[psxphill]

Do you see any mistakes?

Whats the encoding for the move.l with that addressing mode? I can't see anything that matches that in the 68020 user manual.
 

I guess that's not too far from my idea, now I think about it, but with a CPU core specifically designed to emulate 68k. Sort of a hardware emulator, I guess.

If a 1 cycle 68060 instruction translates to 2 of your instructions, then you'd have to clock at double the speed to achieve the same throughput. So each of those would have to be a 1:1 mapping or you've already failed.

[Mrs Beanbag]

If a 1 cycle 68060 instruction translates to 2 of your instructions, then you'd have to clock at double the speed to achieve the same throughput. So each of those would have to be a 1:1 mapping or you've already failed.

I've got the instruction execution timings in front of me here. Instructions with indirect addressing modes or immediate data can take longer than 1 cycle on 68060. Move (An),(An) for instance takes two cycles. All the Register-Register instructions take 1 cycle. These could be mapped 1:1, or better. So the answer is it probably depends on the program. But it might be possible to process some combinations of two 32 bit instructions simultaneously as well. (Add some degree of implicit superscalar operation, probably move ,Dn with ALU Dn,Dn operations, with some pipeline trickery.) Also how well the cache performs will have a lot to do with it.

If I don't beat a 68060 clock for clock on my first attempt, I won't be too disheartened, anyway. If I can beat a 68040 it would be a nice start.

[matthey]

Whats the encoding for the move.l with that addressing mode? I can't see anything that matches that in the 68020 user manual.

   move.l ([$12345678,a0],$12345678),([$12345678,a1],$12345678)

The hexadecimal encoding for above is:

23b0 0173 1234 5678 1234 5678 0173 1234 5678 1234 5678

We can see the flaw of the 68k here. Both of the full extension format words would be better at the start followed by their data like this:

23b0 xxxx xxxx 1234 5678 1234 5678 1234 5678 1234 5678

As is, we may have to examine up to 16 bytes to determine the instruction length. If we remove the outer displacement, the max instruction length would be:

23b0 xxxx 1234 5678 xxxx 1234 5678

We need to examine 10 bytes to find the instruction length now. The maximum instruction length would become 14 bytes which is fewer than the x86 15 byte maximum instruction length .

[psxphill]

move.l ([$12345678,a0],$12345678),([$12345678,a1],$12345678)
 
The hexadecimal encoding for above is:
 
23b0 0173 1234 5678 1234 5678 0173 1234 5678 1234 5678
 

Hmm, for me that disassembles as:
 
001000: 23B0 0173 1234 5678 0173 1234 5678                  move.l  ([$12345678,A0],$1234), ($78,A1,D5.w*
00100E: 1234 5678                                           move.b  ($78,A4,D5.w*, D1

[matthey]

Hmm, for me that disassembles as:
 
001000: 23B0 0173 1234 5678 0173 1234 5678                  move.l  ([$12345678,A0],$1234), ($78,A1,D5.w*
00100E: 1234 5678                                           move.b  ($78,A4,D5.w*, D1

It's not uncommon to see bugs in assemblers, disassemblers and debuggers using these advanced and seldom used addressing modes. I used vasm typing in:

Code: [Select]

  MC68060

   move.l ([$12345678,a0],$12345678),([$12345678,a1],$12345678)
   rts

I assembled it from test.asm to test. It disassembled just as I typed it with my modified version of ADis from here:

http://www.heywheel.com/matthey/Amiga/ADis.lha

Disassembling with:

ADis -m6 -a test

The old version of ADis would have had problems. IRA 2.04 fails to disassemble the destination correctly. D68k v2.0.8 is very close but oddly gets the address register in the destination wrong.

BDebug from the Barfly package gets it right. CPR from SAS/C gets it right (although doesn't display the $ for hex numbers on instructions).

I thought you might have been using D68k at first but apparently not. What disassembler did you use?

Edit:
I also found this excellent article about decoding the x86 to RISC:

http://abinstein.blogspot.com/2007/05/decoding-x86-from-p6-to-core-2-and.html

If x86 can do it, we can do it better and easier without a longer pipeline hurting branch performance .

[billt]

For those saying that Altera is the better fpga for this task, what exactly makes it better, and what are you comparing it to on the Xilinx side?

[mikej]

For those saying that Altera is the better fpga for this task, what exactly makes it better, and what are you comparing it to on the Xilinx side?

Altera and Xilinx devices made on the same process are roughly the same in terms of delay and logic size. The IP available, hardmacs and IO capabilities do differentiate them for some applications. For what we are doing here there is not much in it, it's down to logic area per $.
Even in the Spartan3 I believe I can get the software CPU to 100MHz+.

/MikeJ

[psxphill]

It's not uncommon to see bugs in assemblers, disassemblers and debuggers using these advanced and seldom used addressing modes. I used vasm typing in:
 

Code: [Select]

  MC68060
 
   move.l ([$12345678,a0],$12345678),([$12345678,a1],$12345678)
   rts

I assembled it from test.asm to test. It disassembled just as I typed it with my modified version of ADis from here:
 
http://www.heywheel.com/matthey/Amiga/ADis.lha
 
Disassembling with:
 
ADis -m6 -a test
 
The old version of ADis would have had problems. IRA 2.04 fails to disassemble the destination correctly. D68k v2.0.8 is very close but oddly gets the address register in the destination wrong.
 
BDebug from the Barfly package gets it right. CPR from SAS/C gets it right (although doesn't display the $ for hex numbers on instructions).
 
I thought you might have been using D68k at first but apparently not. What disassembler did you use?

I used mame (arcade game emulator), typed the hex into memory and then disassembled and executed it. It's not just the disassembler, the emulation consumed the same number of bytes. So that needs looking at, can you post the exe you assembled?
 
There is mention in the manual about some instructions being split over two pipelines, it might do that by splitting it into two FIFO entries. With the result of the ea fetch from the primary pipeline getting forwarded to the secondary pipeline so it can get stored.
 
Have you tried running this encoding on a real 68060?

[mrgreedy98]

I did not read all the comments but would using a fcpga/clpd in conjunction with a coldfire cpu and a paralell bus off from the fcpga/clpd not do the job ?

The coldfire chipset does not have all the cpu instructions of the 68k it could be emulated just those instructions in the fcpga/clpd and off load known/ simular instructions to the cold fire nativly.
there is the issue with the fpu 64 vrs 40 i think, address lengths and some of the data format entry and adressing modes not to mention the purged instructions.

The modern cold fire chipsets have 75-90% of the original 68k chipset instructions any way last time I looked.

freescale are pushing the arm archeture and have semi dumped coldfire also of note the Altera Cyclone-III FPGA's have a coldfire core engine simplifying clpd design half the work is already done you just need to apply for liscence to use it and it is free?

some one with some skills could jump on this if they so desired an fcpga engine could be done.

[Mrs Beanbag]

Bare in mind that these complex, base displacement addressing modes do not exist on 68000, only from 68020 onwards.

@mrgreedy98: as has been pointed out already, ColdFire core can be licensed and used, but it cannot be modified because it is encrypted (and no doubt obfuscated as well, I know Xilinx obfuscate their cores before encrypting them). Without modification, ColdFire is not much use, sadly. I have investigated this. The differences might be subtle but that doesn't make them easy to work around.

[bloodline]

Quick question, sorry if it has already been asked/answered... Has anyone profiled Amiga programmes in general to find out common case? What instructions are really popular?

[Mrs Beanbag]

There is this information from the Megadrive:
http://emu-docs.org/CPU%2068k/68kstat.txt

although it might be more instructive to see which are the most common addressing modes for these instructions, too.
For instance, rate of "add Dx,Dy" vs "add (Ax),Dy" and "add Dx,(Ay)".