bloodline wrote:
FrenchShark wrote:
Hello,
concerning the 68040V : you need more I/Os to interface it : 32 address lines + 32 data lines instead of 24 + 16.
One solution is to use the multiplexed bus mode of the 040.
I have been working on a RISC to emulate the 68k. I have the instruction fetch, decode and ALU working. To have a decent emulation speed the CCR/SR must behave EXACTLY like the 68k's. The instructions that are difficult to do in a RISC are the ROXL and ROXR, especially when B, W and L sizes are supported. To limit the resource usage, my barrel shifter only supports LSR, LSL, ASR, ASL, ROR and ROL with the L size (now I understand why Freescale has created the coldfire). Strangely, in an FPGA, the best way to create a fast and small barrel shifter is to use the multipliers :crazy:
Regards,
Frederic
Now this is the sort of thing that I'm talking about... I spent an hour yesterday thinking about how to do this... Are you able to give more details? I will post my thoughts when I have a chance to formalise them.
Hmmm... I have spent a bit of time running it over on paper now...
My idea is to have a simple big endian, fixed instruction width, 32bit Load-Store CPU, with 32 General purpose registers (the last three of which are special purpose, PC, SP and CC/Status). The idea that only the Load and Store instructions would worry about operand size (obviously the three sizes supported by the 68k), and all logic/arithmetic instructions would operate only on registers and with a 32bit operand size. At the moment I won't think about a supervisor mode and certainly no interrupts or exceptions (though 3 bits of the Status register would be wired as interrupt request flags, the CPU would have manually poll them). I though this would give a nice simple basis for a CPU that could run a 68k emulator and wouldn't use up too much space on an FPGA (though I know nothing about FPGA programming, this might be the most inefficent design possible on an FPGA).
With that in mind, the first 20 registers would map directly to the architectural registers of the 68k. Which less the special purpose registers, would leave 9 registers for internal emulator working.
What becomes immediately obvious is the amount of code required just to emulate the CC flags of each 68k instruction... and that's before worrying about the 68k decode stage, addressing mode emulation and exceptions/interrupts etc... One 68k instruction would require something like 10 of my "RISC" instructions... this "RISC" CPU would have to run at a very high speed (and a decent cache would help) in order to work well... I will have to bow to Alex's intuition/experience that this idea isn't really doable, certainly not with current FPGA technology... :-)
Things could be improved with a JIT, but that would require my RISC CPU trapping illegal instructions, which means interrupts etc... which starts to get complex...
I did think I could have 3 CC registers, one for each of the 68k operand sizes (each one setting the result as if the the operation was 8bit, 16bit or 32bit.. despite all operations actually being 32bit)... then the emulator would not need to work out the correct CC for the operand size but simply check the correct CC register... that might work...
It certainly was fun working it through though :-) I doubt my solution was the best, anybody got a better idea? Perhaps some kind of hardware decoder (my assumption was based on using a large jump table for the emulator to match the 68k Opcode to the correct function), but then we are moving into Vertical microcode territory...
