Live data from Hacker News

Show HN: My x86 emulator written in JavaScript

copy.sh

161–170 of 194 posts

Re: Show HN: My x86 emulator written in JavaScript

#161
post #84
post #58

Earlier quoted context omitted.

I'm getting here > speed 1640kIPS on the old Nexus 7, don't you mean 8kkIPS? (This value was the average while booting Linux)

psst, the SI prefix for 10^6 is M

You mean to say, 10^7 isn't KKK?

Re: Show HN: My x86 emulator written in JavaScript

#162
post #68

Earlier quoted context omitted.

Thanks, it's under the error tab: ReferenceError: requestAnimationFrame is not defined http://copy.sh/v24/v86_all.js Line: 239

Update to a newer Firefox. Your FF is dead old and doesnt support the new HTML5 methods... and @author, maybe add a polyfill?

FF 24.0 ESR on FreeBSD is getting there but still some issues:

http://freebsd.1045724.n5.nabble.com/Problem-with-FireFox-24...

Re: Show HN: My x86 emulator written in JavaScript

#163

Earlier quoted context omitted.

FF 24 is the latest stable. FF's docs say they added this function in FF 4.0, which was several years ago. So it's a bit more complicated than you make it out to be. EDIT: I thought FF24 wasn't working, turns out I was confused between my Linux desktop's and Mac laptop's FF versions. Sorry!

It's actually not all that complicated. Firefox 4 added mozRequestAnimationFrame. Firefox 23 added the unprefixed version. It's documented in the browser compatibility table at https://developer.mozilla.org/en-US/docs/Web/API/window.requ... (note that "moz" next to the 4.0).

That must have done the trick, it starts now, thank you for your help.

Re: Show HN: My x86 emulator written in JavaScript

#164
post #30
post #22

Wow, very impressive! What are your plans for this? Any plans to open source?

It will be open-source. I don't know how to deal with licensing yet.

1. Pick a license. You'll probably want something compatible with Qemu (GPL2+).

2. Ship a COPYING file, add a header to your files: https://github.com/osterman/copyright-header

Re: Show HN: My x86 emulator written in JavaScript

#165
post #116
post #19

Earlier quoted context omitted.

Networking is on the todo list. I couldn't host the traffic, though.

i suppose you could try adding something to do the networking part via webrtc as the channel?

Nothing in the web platform lets you use raw (or TCP/UDP/etc) sockets. At most you could do VPN-style networking and use a bridge to talk to the rest of the internet; that bridge needs someone to host it.

Re: Show HN: My x86 emulator written in JavaScript

#166

Earlier quoted context omitted.

Have you consider reporting strange deoptimization behaviour to V8 team? Performance issues are better investigated than worked around. V8 has special support for uint32 values in optimized frames to avoid converting them to doubles when they flow into truncating operations. If that support somehow became broken that would be unfortunate. (and it's actually only >>> 0 that is problematic from the optimization point o…

The problem is that I can't really explain it. I can hardly say: Hey, if I change this line (from 3000 lines) from A to B I get a 80% reduced chance that my program is deoptimized after 30 seconds and slows down by a factor of five. No one will take the time to look at it. What I want is information. They have to provide a tool that let me see what happens. Especially if a variable or operation is treated as double o…

> No one will take the time to look at it.

No, I think you are making a wrong assumption here. A bug report like that, that pinpoints a line in question and provides observable metrics is the best kind of performance issue that you can file against V8.

Back when I was on the V8 team I would immediately set aside some time to investigate and triage/fix/explain it because stable performance is as important for any VM as correctness.

So don't hesitate to file bugs like that against JavaScript VMs be it V8 or SpiderMonkey. You might be surprised with VM engineers' eagerness to investigate and address performance problems.

> What I want is information.

There are ways to trace optimizations and deoptimizations in V8. Unfortunately nothing as simple to use as JIT-inspector. Most of what V8 has right now is geared towards VM engineers.

I have a tool called IRHydra[1] that can display some information that V8 dumps in a more or less digestible form. It's most useful for performance investigations in the console but to a certain degree works for browser as well (biggest problem for it "multithreading": because V8 dumps part of the information into stdout and as a result it can arrive arbitrary mixed if you have many workers).

[1] http://web.irhydra.googlecode.com/git/hydra.html

Re: Show HN: My x86 emulator written in JavaScript

#167
post #122
post #111

Earlier quoted context omitted.

great to hear you are opensourcing this! I had a quick look at the minified source. its pretty hard to decipher (method names have been renamed too), unlike traditional minification which you can recover by just reformatting.

AFAIK most of minificators also shortened variable / function names - are there any that don't do this? (take a look at minified jquery.js for instance)

minification can't (usually) happen on the public side of the API - that could explain jQuery, as a very large amount of it is public.

Otherwise yeah, you can just run it through a whitespace-remover. There are also often options on e.g. the YUI compressor: http://refresh-sf.com/yui/ and Google's: http://closure-compiler.appspot.com/home

Re: Show HN: My x86 emulator written in JavaScript

#168
post #155
post #52

Earlier quoted context omitted.

The soul-crushing bugs are the ones where you run a program, and nothing actually goes actively wrong, but the program overall just doesn't behave quite like it does on the real hardware. Simple defects where a key is being ignored on certain systems are usually quite easy to fix ;)

Whoosh

Would you like me to explain my response more clearly? :)

Re: Show HN: My x86 emulator written in JavaScript

#170

Earlier quoted context omitted.

Luckily, he was able to come up with a workaround. Here's a soul-crushing situation that doesn't have a workaround, as far as I can tell. You can play the original Deus Ex on OnLive. By default, it sets the fov to a very low number. It's only possible to change it in the console (there is no UI for it). But the console is disabled. However, you can get around that by pressing T, which creates a mini console with "say…

OnLive runs on OSX. gdb (i think) also runs on OSX. It should be possible to isolate the callback used to handle keyboard input and call it with c=10. This would take anywhere from hours to weeks of debugging though.

No, that won't work. Nothing you do client-side will help.

OnLive Client OnLive Servers Deus Ex instance in a VM.

The enter key is filtered out on their servers. Unless you hack into their servers and change that, there is nothing you can do on the client-side. That's what makes you completely helpless.

Post reply on HN