Motorola 68060 FPGA replacement module (idea)

[bloodline]

It's not a time sink if people are working together in parallel which is the way it was suppose to be when I started documenting the new 68k ISA. It's not a time sink if the new ISA attracts interest from outside of the retro crowd. It's not a time sink if the ISA is implemented and found to be a substantial improvement in power, code density, compiler support and ease of programming. You give up very little with the possibility to gain much more. There is a market for retro computing but a bigger market for a processor that can handle today's processing needs quickly with compact code as well as being compatible with old code. That's what ARM and x86 did. They evolved and now they are successful. Building a 68020 compatible CPU comes first, but even then it's smart to plan ahead to make future enhancements easier.



Yes, but they were using predication (unusual for a CPU) that only offers a small advantage in some specific hardware. The smaller the block of predicated instructions and the simpler the instructions the better. Most original ARM ISA instructions could be conditional which worked ok but was dropped with the Thumbs because it was not good for code density which they were going after. The ARM block predication instruction was for multiple instruction predication but ARM went to OoO processors where it didn't work as well. The conditional instructions proposed in the 68kF ISA should work nicely while being a small simplification improvement over a more generic CMOV like x86. They would work well on a Superscaler CPU with a short pipeline and a cheap branch predictor (or no branch predictor) which the 68k is likely to have. There would still be some optimized code that would not want to use them at times. This includes highly predictable branches that are executed often and very tight loops where a highly predictable branch could be used instead. Note that some instructions like ABS (absolute value) have no drawbacks yet remove a branch that can be difficult to predict and SELcc can remove 2 branches in some cases. I would like to do some testing in an implementation before finalizing the ISA.

Sounds interesting, you might want to start a new thread about optimising and evolving the 68k ISA... As any discussion here might get confused with talk about FPGA implementations

[bloodline]

Sorry if I'm dense, are we agreeing?

I thought you implied that no matter what, fragmentation would happen.

My point was that it wouldn't fragment us unless someone added or removed 680x0 instructions.

I guess I am dense.  I can't take yes for an answer

Adding/removing instructions isn't going to fragment, added instructions can be ignored (see the 68020) and removed instructions can be trapped (see the 68060)... Fragmentation would occur if instruction behaviour is altered...

Reusing a previously assigned opcode cold cause problems, unless it wasn't commonly used on the Amiga... If it has potential to improve compiler code generation, or speed execution... then I say go for it!!

[bloodline]

How about some Amiga Chip Pinouts

http://megaburken.net/~patrik/pinout_temp/

[bloodline]

That issue is solved with a simple mechanical adapter, as already mentioned. The 060 socket has signals that 030 socket doesn't. So you can go down, but not up.

True...
From the datasheets it looks like the 680x0 busses aren't really that different (excepting the larger address size 020 onwards), the extra signals on the later chips just offer more clues the the hardware about cashing and protection

[bloodline]

I have been reading matthey's 68kF2 ISA proposal, and it reminded me how complex the 68k instruction encoding is,

I have included a link here for others to learn about Instruction encoding (in this case, nice simple MIPS):
http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Overall/instruction.html

[bloodline]

Complex? Take a look at a decoder for x86 . Yea, the 68k does need more logic in the decoder but the improved code density allows more instructions to be piped into the processor. Most RISC instructions use a consistent 32 bit fixed length encoding which is great for decoding. The 68k needs several separate decoding tables (lacking a better name) for different encoding areas. Some encoding holes are even divided into a separate table of instructions. This part of the 68k could have been a little better but it's not too much of a problem. The 68k does compress a lot of data with sign extended values which works very well and can be improved on. The overall slowdown from the decoder is minimal on the 68k and can be made up for with powerful instructions and addressing modes which it has and can be improved on. ARM with Thumb 2 works well because of the code density plus powerful instructions for RISC. This was a good tradeoff even though they now have a little more complex decoder. MIPS and PPC have also experimented with code compression (MIPS16E and CodePack respectively) but it never caught on or fit as well for them:

http://www.embedded.com/electronics-blogs/significant-bits/4024933/Code-compression-under-the-microscope

I rather like Mrs Beanbag's idea of a nice simple RISC core tailored to executing instructions that have been decoded from 68k instructions, it could simplify the decode stage maybe

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

[bloodline]

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)".

Brilliant!! I kinda figured the branch, move and compare instructions would be the more popular

[bloodline]

I've had a bit more of a think about this... Would it make sense to design a RISC CPU for the FPGA with the same condition codes/flags as the 68k (where instructions would set the flags as expected), but limit all the exotic addressing modes to the load/store instructions?

A simple MMU could be added to mark memory block, to assist a JIT... That way we could have an FPGA CPU that could execute code really fast, allow for easy mapping of 68k instructions to the native instructions and move the 68k->native decoding to a software JIT

[bloodline]

This is quite a neat trick, I've been looking into it for my own 68K core.
The Replay PS2 keyboard/mouse controller uses a picoblaze softcore as it is smaller than the logic used otherwise - and you can to a lot more.

http://www.roman-jones.com/PB8051Microcontroller.htm
Here they are using it as a 8031...
/MikeJ

I've actually spent a few days trying to design my own 68K emulator, to work out how to modify the MIPS ISA to make it super efficient at 68k emulation... I used a three jump table design, with first using the first 4bits of the instruction, the next jump table using not the next three bits, but the three bits after them and then finally the upper three bits below the top nibble... At this point I got fed up... There seems to be about 504 unique instructions, but little organisation... I prefer RISC here

[bloodline]

This is quite a neat trick, I've been looking into it for my own 68K core.
The Replay PS2 keyboard/mouse controller uses a picoblaze softcore as it is smaller than the logic used otherwise - and you can to a lot more.

http://www.roman-jones.com/PB8051Microcontroller.htm
Here they are using it as a 8031...
/MikeJ

Thanks for the PicoBlaze hint, that lead me to the microBlase which lead me to the DLX... A sort of stripped back MIPS