Motorola 68060 FPGA replacement module (idea)

[Mrs Beanbag]

2 is added to the value of A0 and swapped.  This is no different than how we do it with software emulation.  An FPGA can certainly do anything that can be done in software.  Instead of the FPGA handling the entire CPU core, it would be handling the memory bus accesses and off-loading the CPU emulation itself to the primary (x86) CPU.

But then instead of getting "cdef" as the data, it gets "bahg" interpreted as "ghab" - completely wrong!

[Mrs Beanbag]

What exactly are we trying to connect to what, in any case? I got lost somewhere along the line.

[Mrs Beanbag]

Forgive me if this sounds terribly stupid, but surely an Arm chip (for instance) has data and address buses that we could connect to the trapdoor slot via some relatively simple FPGA glue logic, just as we would a 68060?

[Mrs Beanbag]

MicroBlaze softcore achieves 1.38 DMips/MHz:
http://www.xilinx.com/tools/microblaze.htm

With 500MHz FPGA, if such core could be matched by a 68k soft core, this would probably beat software emulation on 1GHz Arm.

[Mrs Beanbag]

I'm not suggesting to use MicroBlaze soft core, I'm citing it as example of performance that can be achieved by a soft core.

[Mrs Beanbag]

I have a friend of a friend who was talking about creating a 68k  softcore for his own project, I should see if I can get involved. I'd  really like to get into this sort of thing.

CPU cores can take  less space of an FPGA than you'd think, from what I can tell. Speed is  more of a problem than space. Then again 68k is a bit more complex than  MIPS et al.

[Mrs Beanbag]

Personally I'd be inclined to start with something like a RISC core with 68k-like programming model, and optimise for speed first, then work in a compatibility layer. Starting with 68k compatibility and then trying to work in pipelines etc, seems like the difficult way around.

[Mrs Beanbag]

You might be able to license the core and use it but you won't be able to modify it, commercial cores are typically encrypted so you can't get at the source code.

[Mrs Beanbag]

Regardless of whether adding new instructions is a good idea or not, we should get one to work without new instructions FIRST, then think about what we can add to it later if it still seems a good idea.

[Mrs Beanbag]

If people use the added instructions, the code won't work on other accelerators. So everyone has to have the new accelerator to run the new code, which would be sad.

And what if two different developers add two different sets of ISA extensions? Then there is real trouble.

I don't personally think there is much call for new instructions. Maybe common combinations of existing instructions can be optimised specially.

[Mrs Beanbag]

68060 has some performance factors:
# 10 stage pipeline.

That's rather longer than I expected.

[Mrs Beanbag]

Motorola removed some of the instructions added to the 020 and some of the FPU instructions to save space, that could be used for making it run quicker.

The only 68020 features I ever used are longword multiplies and divides, and scale factors on indexed addressing modes.

[Mrs Beanbag]

68000 can do 16-bit branches, it's 32-bit branches that are 68020+

[Mrs Beanbag]

No EXTB.L or TST.W/L An? No misaligned reads or writes?

Ah, you got me. I do use EXTB.L, on occasion. Although I could easily do without.

I can't honestly say if I use TST.L An or not, off the top of my head. Pretty sure I never do TST.W An though, can't think of much use for that.

I'm actually pretty careful not to do misaligned access, it just seems wrong, somehow. Just because you can, doesn't mean you should!

[Mrs Beanbag]

I do such things like:

move.l myptr(PC),D0
beq .nullptr
move.l D0,A0

in the 2nd example could always use tst.l D0 anyway.

flags are set for free when moving to an address register. Also note the first line, I always write relocatable code.

In other news, I've been thinking about a RISC instruction set for internal use in a 68k core for some time. I think we can identify a few obvious simplifications:
1. tread An and Dn identically (use extra instructions if different behaviour is required)
2. only MOVE can use as either source or destination operand (load/store architecture)
3. all other instructions register-register, or "quick" short-constant source operands
4. spare "temporary" registers for internal use.
we could map 68k instructions to short sequences of internal instructions, and design those instructions to give the shortest sequences.

[Mrs Beanbag]

Mind swap on the address register .

Oops I meant data register.

That's nice for simplification but not good for code density. Are you looking at a fixed 16 bit or 32 bit RISC encoding?

Code density doesn't matter here as it would only used internally, external 68k code translated into internal code in some kind of buffer. Fixed length but the number of bits could be anything, it's not actually stored in the RAM so it doesn't even need to be 16 or 32.

I have heard a rumor that as much as 1/3 of the 68060 is microcode. It's generally slower though. The 68060 bit field instructions are a good example. They can be done in 1-3 cycles (data in cache) on an fgga but they take 2x-3x that long on the 68060.

I would rather optimise for 68000 instructions and provide the rest just for compatibility. How common are the bitfield instructions in real code? I never use them.

Of course see what fits on an FPGA first and maybe we can add more bits in later.