passing custom structs around on the stack about lljs HOT 8 CLOSED

It looks like it's not copying arguments that are multiple bytes long correctly. Here's the first part of the generated code for add:

  function add(vec1, vec2) {
    const $I4 = $M.I4, $U4 = $M.U4;
    var _, _$1;
    const $SP = $U4[1] -= 8;
    $I4[$SP] = vec1;
    $I4[($SP) + 2] = vec2;

It just copies the first byte of vec1 and vec2, instead of copying all the bytes like this:

    $I4[$SP] = vec1;
    $I4[($SP) + 1] = vec1 + 1;
    $I4[($SP) + 2] = vec2;
    $I4[($SP) + 3] = vec2 + 1;

from lljs.

It's very helpful to see these bugs, please keep filing them. We don't support passing structs by value and we should do a better job with displaying the errors. You can rewrite the function to take pointers instead and pass the arguments by reference using the "&" operator.

function add(Vec2d *vec1, Vec2d *vec2, Vec2d *res) {
    res->x = vec1->x + vec2->x;
    res->y = vec1->y + vec2->y;
    console.log(res->x, res->y);
}

let Vec2d vec1;
vec1.x = 10;
vec1.y = 11;

let Vec2d vec2;
vec2.x = 20;
vec2.y = 21;

let Vec2d vec3;

add(&vec1, &vec2, &vec3);

from lljs.

Ok, thanks. That's too bad because something like a 2d vector will be used a lot in a game engine, but maybe I can come up with a style that avoids having to create them too much (you always pass a position and size for each object, but I could just pass 4 ints instead of 2 vecs).

Are there any plans to support this?

I'll continue to file bugs as I see them. Really looking forward to getting something running and benchmarking the difference this makes for a 2d game.

from lljs.

The problem with passing structs by-value is that it can be quite slow if it's not optimized away by the compiler. Passing a reference to a stack allocated struct is much faster but it's kinda hard to work with. I think passing by-value is something people will want and we should probably support it.

We haven't had much code written in LLJS, and I'd love to see how it compares with regular JS code as well. Are you hosting your code somewhere on github?

from lljs.

What we really should do is get sweet.js to work with LLJS. Damn, that would be awesome. I could then write macros to abstract away the syntax for constructing type instances (which is mainly where I'll hit this).

Yep, my code will be here: https://github.com/jlongster/game-off-2012

I'm attempting to quickly write a simple engine to power a game for github's game off. I'm hoping the benchmarks will be positive and allow me to do more complex things. I'll start committing soon.

from lljs.

Yah, that would be sweet indeed. Good luck with the game, let me know as you're running into issues so I can fix them.

from lljs.

I can look at how to integrate sweet.js with LLJS. It shouldn't be too hard in theory, but I'm not sure how deep the reader hooks into esprima. It might be a bit time consuming to, say, rewrite LLJS as a set of macros at the moment, but if we diff the two esprima forks...

from lljs.

That would be awesome, and a huge reason to use this over going the full emscripten route. (that could be appealing even from scratch since I think LLVM optimizes it further). Closing this issue though, feel free to open a new one for sweet.js support.

from lljs.