request super turbo copro

[BigEd]

Now that a real Beeb can have a 250MHz 6502 coprocessor (by hooking up a cheap Raspberry Pi Zero) can we have a super speed copro on JSBeeb? Or, is there a tweak I could perform in the developer console to remove or adjust the Turbo Copro speed limiter?

[mattgodbolt]

Haha cool :) Sadly the fastest jsbeeb wants to run is about ~8-9MHz due to the (relatively!) insanely slow javascript emulation :) There's some precedent for making things faster than "reality", the cpuMultiplier URL param (See the readme), but that speeds up only the main CPU.

I'll have a think! Good excuse to optimize the emulation too :)

[mattgodbolt]

For a quick hack check https://github.com/mattgodbolt/jsbeeb/blob/master/6502.js#L325 - the cycles * 2 there is the "how many tube cycles to do per 6502 cycle`...

[mattgodbolt]

My browser:
> benchmarkCpu() Took 777ms to execute 10000000 cycles main-7be90e0….js [sm]:1024 Virtual 12.87MHz

[BigEd]

Thanks - my Chromebook only manages
Virtual 3.29MHz
so that's not a very hopeful sign! Maybe I need to adjust my expectations.

[BigEd]

Am I right in thinking that interrupts don't need to be nearly so exact on a copro? I'd like to think JS offers some way to write one cpu emulator which can elaborate into either a fast or an accurate model, but I don't know how that might be done - it might not be possible. I would guess that the care and attention which has made the front-end model very cycle accurate is a hindrance to the speed (efficiency) of the copro model.

[mattgodbolt]

Right! There's a load of shortcuts that can be taken on the copro: as you
say, cycle-perfection is not needed. Can probably adjust the code generator
to drop a load of the work there (luckily, the correctness is something
that can be adjusted in code!). Also, there's fewer hardware peripherals
etc, so the copro probably already runs much faster than the normal CPU.
It should be pretty straightforward...thanks for the thoughts!

On Fri, Oct 28, 2016 at 10:05 AM BigEd [email protected] wrote:

Am I right in thinking that interrupts don't need to be nearly so exact on
a copro? I'd like to think JS offers some way to write one cpu emulator
which can elaborate into either a fast or an accurate model, but I don't
know how that might be done - it might not be possible. I would guess that
the care and attention which has made the front-end model very cycle
accurate is a hindrance to the speed (efficiency) of the copro model.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#134 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmsdfAtYyED6dyvt_FQNZxRD3fcJFK8ks5q4g9UgaJpZM4Kjgl_
.

[BigEd]

More from my half-baked book of premature optimisation:
Are you already using byte arrays for the memory model? Any tricks from asm.js which could be used to make things easier on the JS engine? Do all the trivial functions like the flag-setting get inlined automatically?

[mattgodbolt]

Yup indeed. I use a lot of the asm.js trickery, though I can't go the whole
hog without a huge refactor (and making the code unreadable): true asm.js
code is so restricted. I am toying with changing the flags to an actual
byte with ors and ands as I suspect the flag setting isn't actually as
cheap as I'd like...

On Fri, Oct 28, 2016 at 10:14 AM BigEd [email protected] wrote:

More from my half-baked book of premature optimisation:
Are you already using byte arrays for the memory model? Any tricks from
asm.js which could be used to make things easier on the JS engine? Do all
the trivial functions like the flag-setting get inlined automatically?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#134 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmsdSqsguAnqHQEX9F9XB9MIork4Yqoks5q4hFWgaJpZM4Kjgl_
.