Welcome, Guest. Please login or register.

Author Topic: FPGA Amiga Possibilities ?  (Read 806 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: FPGA Amiga Possibilities ?
« Reply #14 from previous page: November 14, 2015, 11:06:48 PM »
Quote from: psxphill;799182
All emulators cheat to some extent, but it is possible to write a JIT that is as accurate as an interpreter.

I believe you are correct. However, the whole point of JIT is to maximize performance so short cuts are usually considered advantages if they don't cause too many problems. JIT code is usually executed in an isolated sandbox where problems don't kill the system. Also, JIT is error prone because of complexity.

Quote from: johnklos;799192
While you've made your point, a nearly twenty year old CPU certainly doesn't destroy a Raspberry Pi 2 in single core performance. Being generous, by the end of 1997 the fastest x86 you could get was a 300 MHz Pentium II, and the fastest PowerPC was a 266 MHz PowerPC 750.

I may have exaggerated the "almost" 20 year age of my free PC a little to make my point. There are 20 year old CPU designs which have stronger single core performance than the RPi2 though. Put a Pentium 2 or even PPC G3 design in the same size die at the same clock speed as the RPi2 and it should beat it in single core performance. The PPC P1022 (Tabor) design is a good example of a recycled G3 design in a modern die size and it is some 26% better at single core performance than the RPi2. CISC is even stronger and the Pentium 2 had a long enough pipeline to allow clocking it up even if Intel had not figured out all the complexity of the x86 ISA yet (they were already designing the Pentium 3 which had it figured out before they became side tracked marketing high clocked Pentium 4 room heaters). Clock the 68060 design up to RPi2 speeds and I bet it will have stronger real world single core performance also. I wouldn't be surprised if the Apollo core in FPGA has stronger single core integer performance. Actually, it can handle 3 complex integer instructions per cycle (equal up to 12 integer RISC instructions/cycle) with no load/store bubbles while the P1022 is limited to 2 simple integer instructions per cycle. It is also much stronger at multiplication than the P1022 which is as bad at multiplication as the old G3. This is with a weakened Apollo core in an FPGA which could be considerably stronger in an ASIC. Of course these RISC cores are low power consumption minimal logic embedded processor designs.
« Last Edit: November 14, 2015, 11:09:23 PM by matthey »
 

Offline psxphill

Re: FPGA Amiga Possibilities ?
« Reply #15 on: November 14, 2015, 11:38:00 PM »
Quote from: matthey;799195
However, the whole point of JIT is to maximize performance so short cuts are usually considered advantages if they don't cause too many problems.

That could also describe "enhancements" made to 68060 when implementing in an FPGA as well. You can take shortcuts in a pure interpreting emulator as well (almost all of them do).

Quote from: matthey;799195
JIT code is usually executed in an isolated sandbox where problems don't kill the system.

No they aren't. JIT is used to implement a sandbox for Java/C#, but that is because the JIT adds code to do range checks, null checks, etc. The generated code just runs.

Quote from: matthey;799195
Also, JIT is error prone because of complexity.

Unit testing and other forms of automated testing are important if you are writing something as complex as a 68000 cpu core anyway. But things like self modifying code are always going to be a little bit of a problem with a JIT, there are multiple strategies for this which each have their own overheads. I would be interested in how well a 68060 JIT would work, if it only kept generated code that fit into the instruction cache. Code that runs fast on a real 68060 would run fast on the emulator & the same for slow code.
« Last Edit: November 14, 2015, 11:43:40 PM by psxphill »
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: FPGA Amiga Possibilities ?
« Reply #16 on: November 15, 2015, 01:17:32 AM »
Quote from: psxphill;799196
That could also describe "enhancements" made to 68060 when implementing in an FPGA as well. You can take shortcuts in a pure interpreting emulator as well (almost all of them do).

In the case of the classic Amiga, CPU "enhancements" which aren't 68000 or 68020 ISA compatible will break.

Quote from: psxphill;799196
No they aren't. JIT is used to implement a sandbox for Java/C#, but that is because the JIT adds code to do range checks, null checks, etc. The generated code just runs.

Most other OSs have memory protection for process protection at least.

Quote from: psxphill;799196
Unit testing and other forms of automated testing are important if you are writing something as complex as a 68000 cpu core anyway. But things like self modifying code are always going to be a little bit of a problem with a JIT, there are multiple strategies for this which each have their own overheads. I would be interested in how well a 68060 JIT would work, if it only kept generated code that fit into the instruction cache. Code that runs fast on a real 68060 would run fast on the emulator & the same for slow code.

Self modifying code is a performance limitation on real processors also. A real CPU can have hardware help to snoop out the writes but flushing and reloading the ICache still has overhead, especially if the code has been fetched by the CPU. I suppose the JIT could use the MMU but often changing the way pages are marked and interrupts from responding to page violations may be more overhead than it is worth.
« Last Edit: November 15, 2015, 01:20:26 AM by matthey »
 

Offline psxphill

Re: FPGA Amiga Possibilities ?
« Reply #17 on: November 15, 2015, 12:46:53 PM »
Quote from: matthey;799199
Most other OSs have memory protection for process protection at least.


Sure, but that affects normal programs too. JIT compiled code doesn't normally run under a further level of protection, which is what your statement implied.

Quote from: matthey;799199
Self modifying code is a performance limitation on real processors also. A real CPU can have hardware help to snoop out the writes but flushing and reloading the ICache still has overhead, especially if the code has been fetched by the CPU. I suppose the JIT could use the MMU but often changing the way pages are marked and interrupts from responding to page violations may be more overhead than it is worth.


That is why I suggested implementing the code cache so that it mirrors the 68060 instruction cache. Code that works on a 68060 would automatically work on the JIT. You don't have to snoop as the 68060 didn't, just flush the JIT cache when the program clears the cache. The reason to implement it with the same size as the 68060 is in case something is modifying code that would have been automatically retired from the 68060 cache.

Code that fits in the cache would run fast in the JIT, the same as the 68060. Code that doesn't fit in the cache would run slow in the JIT, the same as the 68060.

The problem comes when you want to accelerate code that was slow to begin with, because this is likely to slow down code that was fast to begin with.