Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

Offline psxphill

Re: FPGA Amiga Possibilities ?
« on: November 14, 2015, 11:48:06 AM »
Quote from: matthey;799178
Also, JIT cheats and is less accurate emulation.


All emulators cheat to some extent, but it is possible to write a JIT that is as accurate as an interpreter.
 

Offline psxphill

Re: FPGA Amiga Possibilities ?
« Reply #1 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 psxphill

Re: FPGA Amiga Possibilities ?
« Reply #2 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.