Here's some feedback of what I know about Javascript and speed. I may be wrong, and would invite further comment if so.
sPhilMainwaring wrote:
1. Most emulators use a massive SWITCH/CASE statement that must be parsed in its entirity for every CPU instruction. My emulator uses 256 pointers to very compact, pre-compiled and stored, one-liner functions which it simply, and instantly, indexes from the instruction value (0..255)
A switch/case would run faster than a function call, since it doesn't have to enter a new stack frame. Since the dispatch is on a "small" range of integers, it's easily generated from good compilers as a _jump_ table dispatch instead of a _function call_ table dispatch.
Quote:
2. All variables and functions have names which are only 3 characters long (similar to the 6502 mnemonics)
Parsing only happens once, and there shouldn't be runtime lookup of function names as strings, so there's no speed benefit to shorter names. The gain during initial parsing would be indistinguishable.
Quote:
3. There are no IF statements used in the instruction code functions. All functions are "one-liner" JavaScript functions written as compactly and efficiently as possible using trinary operators
Trinary operations are exactly as fast/slow as explicit 'if' statements.
Quote:
4. Even these trinary functions are avoided wherever possible; e.g in your ADC example above the function handling this operation does not check each time if Decimal Mode is selected. Only when Decimal Mode IS selected or deselected (via SED and CLD) the ADC function pointer (ADD) is changed to DAD or BAD for Decimal ADd and Binary ADd respectively
That's a valid speedup, but does rely on a function call for every instruction. I would suspect that doing a test inside a single inline block that handles ADC would end up faster overall. You'd need to try it and test.
Quote:
5. Each addressing mode calculation also has it's own function and this is then passed as a variable giving function indexs such as ADC(ZPX)
You might want to run tests to determine the cost of a function call. The fastest would be to run ZPX code etc inline; I'd use a preprocessor to insert those into the code.
Quote:
Most modern JavaScript engines can be forced to use true integers (as opposed to the "String" type real numbers it usually uses) by changing paramater passing from, e.g.:
fn(a,b,c)
to:
fn(a|0,b|0,c|0)
That's interesting, though as you say, the compiler should hopefully be smart enough by now. Doing type inference in static analysis is something that a lot of dynamic languages do now, and I'd expect with all the weight thrown behind Javascript it'd include such tech by now in the major implementations.
Quote:
To be fair the other reason I was curious about a top speed was a kind of friendly banter retort to Michael Steil when he asks in his lecture "If you want to make an emulator run slower what do you do? You emulate it in JavaScript". It got a huge laugh when he asked this (and deservedly so) as it was a great, funny line. I'm very grateful to Michael for inviting me to his forum to share my software developments thus far; untidy and half ready as the code is!
Javascript is a decent language; the browser environment sucks, though, and JS itself gets a lot of flak for that.
Quote:
White Flame wrote:
Here's an insane idea: Since you can build up Javascript at runtime, you could make a 6502->JS dynarec to go even faster.
If I understand you correctly White Flame I'm already doing this as described above
No. If you've written a dynarec, then executing emulated 6502 code would just run Javascript and not fetch opcode bytes from memory to figure out which instruction to execute. It'd actually turn 4000: A9 00 80 00 C0 into something like { a = 0; z = 1; cycles += 2; mem[c000] = a; cycles += 4; } which is directly executed as Javascript whenever the PC hit $4000. Game console emulators do this a lot to gain speed, usually directly recompiling foreign cpu code into native x86 code to run on the emulating PC's processor directly. This sort of compilation is run lazily, and obviously needs to monitor for self-modifying code.
Login
Register
FAQ
Search
