Hacker Newsnew | past | comments | ask | show | jobs | submit | thlorenz's commentslogin

I agree that this is unexpected for most of us, but if you read this section in my v8-perf repo (https://github.com/thlorenz/v8-perf/blob/master/data-types.m...) you'll understand better why that is.

However it doesn't necessarily cause a large slowdown, just makes your function polymorphic and the resulting optimized code larger and a bit slower.

To avoid this entirely I recommend using a JavaScript `class` when passing objects to a function that has to run at peak speed.


A factory function will also give the objects it returns the same hidden class, resulting in monomorphic code that can be optimized.

    function vec3 (x, y, z) { return {x, y, z} }


Why does it have to be that the order of members matters? shouldn't both {x,y,z} and {z,x,y} compile down to {x,y,z}?


In JS for-in loop enumerates keys in the insert order. So {x,y,z} is different from {z,x,y}


AFAIK, that's not true; the spec doesn't guarantee that it iterates in insertion order, it's just how it's commonly implemented in browsers.


Nope, they should be iterated in their defined order: https://tc39.github.io/ecma262/#sec-ordinaryownpropertykeys

I think they added this with ES2015.


As promised flags are now visualized.


It's back up, it is a github page and it seemed github had problems recently.


More interesting snippets are coming once I can emulate more instructions. These are the ones it currently can do: https://github.com/thlorenz/visulator/tree/master/test/fixtu...

I agree though that a more interesting example would be nice and I'll try to come up with one even with what it can do now.


As I pointed out this project is in it's infancy. I merely tweeted about progress and it ended up here ;)

See [status](https://github.com/thlorenz/visulator#status) -- indicating in experimental stage.

I'm planning to allow loading binaries and also editing assembly (assembling it in the browser so the CPU emulator can run the opcodes).


That's nice, thanks for the link!

Seems to serve a different purpose tough. visulator is supposed to help you learn how a CPU processes opcodes (at an abstract level) instead of looking at actual hardware wiring.

I'll link to it from the visulator readme though.


> I think it would be very helpful to put some corresponding C (or pseudo-C) code

That's not the point. All this is trying to show is how assembly and a CPU works. Understanding the program is secondary.

Additionally there is no C code for this as the assembly was written directly.


Please file an issue on github, so I can track these problems and fix them. As I mentioned I'm color blind and could use some styling help via a pull request :)


I addressed the styling issues you pointed out @strommen. If you still have problems reading things please supply a fix via a pull request.


Could you file an issue on github please? This is meant to be used on a Desktop only. You may try to enlarge your fonts via Cmd-+ or Ctrl-+.

Also I do accept pull requests that fix some styling issues (I myself am color blind). Just update the CSS [here](https://github.com/thlorenz/visulator/blob/bad27bc164c1ba173...)


It will emulate as much of x86 as makes sense for it's purpose , to visualize assembly execution and how a CPU works.

It currently already contains a memory unit and supports push/pop instructions. More memory related instructions will be added.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: