5 ms·

Mjs – An interpreter for ECMAScript 1st edition written in C++17

82 points by eatonphil 8y ago

SlowRobotAhead 8y ago
Edit: Apparently this project is a JS interpreter for C++ ... while mJS that I wrote about is a JS interpreter for... C and C++ The one I was talking about is https://github.com/cesanta/mjs https://github.com/cesanta/mjs ... yea, two JS interpreters for C++ with the same name. How could that be confusing?
- eatonphil 8y ago
  Not sure this is the same project? This is MIT licensed and says it's a hobby implementation. I don't see anything about a company or about ARM support.
  - tiles 8y ago
    Looks like it's similarly named: https://github.com/cesanta/mjs https://github.com/cesanta/mjs
    - SlowRobotAhead 8y ago
      Exact same name, nearly the same purpose except that Cesanta’s is not limited to C++ only. My mistake.
- mras0 8y ago
  Sorry for the confusion. I just chose something short when starting the project and since it's just a hobby project I didn't bother checking for name clashes.
austincheney 8y ago
Pretty ambitious for a simple educational project. I suspect the hardest part is getting garbage collection correct around lexical scope. The browsers struggled with this for years.
- chrisseaton 8y ago
  > The browsers struggled with this for years. Multiple browsers had bugs with garbage collection of a basic part of JavaScript for years? What was the problem? I wonder what made them specific to lexical scopes, because a lexical scope is either just more entries on the stack, which is scanned for local variables in the same way, or objects on the heap, which is scanned for fields in the same way.
  - jhallenworld 8y ago
    I've found that remembering to add items to the root set in C (or C++) causes most gc difficulties. In my pet language Ivy, I ended up doing this: new allocations are automatically protected from collection until the interpreter executes the next branch (this limits the work of removing items from the protected list, vs. doing it on every instruction). This limits the number of accidental collection cases you have to think about considerably. There are still a few cases to worry about. For example, during function activation: if you allocate anything between the time you switched to a new lexical scope, but before saving the old one somewhere in the root set you are in trouble. This is easy to do, because you want to just save it in a local C variable until you have allocated the thing where you are ultimately going to save it. https://github.com/jhallen/ivy-lang https://github.com/jhallen/ivy-lang In general gc bugs (like all allocation related bugs) are a nightmare because the effect is always delayed from the bug.
    - mras0 8y ago
      Yeah, I've had my share of interesting bugs (see the article I linked in another post). All pointers are tracked automatically (except for specially optimized classes), so that part isn't so bad, but it's still (too) easy to accidentally use a stale pointer value. At the moment I can safely collect after every statement, but there is still work to be done before I can claim to support collecting after every expression (like I'd ideally be able to - so I can collect when I run out of heap).
  - gsnedders 8y ago
    My understanding of the things that catch people out are things like: function f(){ let a = {}; return function(){}; } In all (IIRC) major implementations, the object allocated for `a` will be held on to after the function returns because it exists in the lexical scope of the function returned (even though it isn't—and never can be—reached, as static analysis can prove). Basically all the other bugs I'm aware of are cases of C++ code not treating things as roots when necessary, mostly in DOM code.
snek 8y ago
It's pretty cool to see all the different ways ECMA-262 has been implemented. I've been working on my own implementation[1] and seeing how other implementations like v8, prepack, mongoosejs, and now this one solve things has been super helpful. 1: https://github.com/devsnek/engine262 https://github.com/devsnek/engine262
- mncharity 8y ago
  > pretty cool to see all the different ways ECMA-262 has been implemented My favorite is that the language spec was written as quite regular pseudo-code... so at least as of some years ago, and after some manual massage to clean up irregularities, one could automagically transliterate the text of the spec into code. And if the target language had label gotos (because the spec was full of 'then go to step N'), and permited arbitrary identifiers, then the code could read just like the spec. Making code-review proof reading much easier. That's one of my canaries for detecting when a non-crippling programming language finally exists - someone generates a not-necessarily performant but fully spec-compliant js implementation with some strikingly tiny effort. A few days.
- mras0 8y ago
  Good luck with your project, for now you should trust the other implementations more :) But I've tried to keep the code reasonably small and (hopefully) readable - which is why it's currently targeting ES1997 - rather than having lots of features, so it's probably more understandable than V8.

82 points by eatonphil 8y ago

Edit: Apparently this project is a JS interpreter for C++ ... while mJS that I wrote about is a JS interpreter for... C and C++ The one I was talking about is https://github.com/cesanta/mjs https://github.com/cesanta/mjs ... yea, two JS interpreters for C++ with the same name. How could that be confusing?

eatonphil 8y ago
Not sure this is the same project? This is MIT licensed and says it's a hobby implementation. I don't see anything about a company or about ARM support.
- tiles 8y ago
  Looks like it's similarly named: https://github.com/cesanta/mjs https://github.com/cesanta/mjs
  - SlowRobotAhead 8y ago
    Exact same name, nearly the same purpose except that Cesanta’s is not limited to C++ only. My mistake.
mras0 8y ago
Sorry for the confusion. I just chose something short when starting the project and since it's just a hobby project I didn't bother checking for name clashes.

austincheney 8y ago

Pretty ambitious for a simple educational project. I suspect the hardest part is getting garbage collection correct around lexical scope. The browsers struggled with this for years.

chrisseaton 8y ago
> The browsers struggled with this for years. Multiple browsers had bugs with garbage collection of a basic part of JavaScript for years? What was the problem? I wonder what made them specific to lexical scopes, because a lexical scope is either just more entries on the stack, which is scanned for local variables in the same way, or objects on the heap, which is scanned for fields in the same way.
- jhallenworld 8y ago
  I've found that remembering to add items to the root set in C (or C++) causes most gc difficulties. In my pet language Ivy, I ended up doing this: new allocations are automatically protected from collection until the interpreter executes the next branch (this limits the work of removing items from the protected list, vs. doing it on every instruction). This limits the number of accidental collection cases you have to think about considerably. There are still a few cases to worry about. For example, during function activation: if you allocate anything between the time you switched to a new lexical scope, but before saving the old one somewhere in the root set you are in trouble. This is easy to do, because you want to just save it in a local C variable until you have allocated the thing where you are ultimately going to save it. https://github.com/jhallen/ivy-lang https://github.com/jhallen/ivy-lang In general gc bugs (like all allocation related bugs) are a nightmare because the effect is always delayed from the bug.
  - mras0 8y ago
    Yeah, I've had my share of interesting bugs (see the article I linked in another post). All pointers are tracked automatically (except for specially optimized classes), so that part isn't so bad, but it's still (too) easy to accidentally use a stale pointer value. At the moment I can safely collect after every statement, but there is still work to be done before I can claim to support collecting after every expression (like I'd ideally be able to - so I can collect when I run out of heap).
- gsnedders 8y ago
  My understanding of the things that catch people out are things like: function f(){ let a = {}; return function(){}; } In all (IIRC) major implementations, the object allocated for `a` will be held on to after the function returns because it exists in the lexical scope of the function returned (even though it isn't—and never can be—reached, as static analysis can prove). Basically all the other bugs I'm aware of are cases of C++ code not treating things as roots when necessary, mostly in DOM code.

snek 8y ago

It's pretty cool to see all the different ways ECMA-262 has been implemented. I've been working on my own implementation[1] and seeing how other implementations like v8, prepack, mongoosejs, and now this one solve things has been super helpful. 1: https://github.com/devsnek/engine262 https://github.com/devsnek/engine262

mncharity 8y ago
> pretty cool to see all the different ways ECMA-262 has been implemented My favorite is that the language spec was written as quite regular pseudo-code... so at least as of some years ago, and after some manual massage to clean up irregularities, one could automagically transliterate the text of the spec into code. And if the target language had label gotos (because the spec was full of 'then go to step N'), and permited arbitrary identifiers, then the code could read just like the spec. Making code-review proof reading much easier. That's one of my canaries for detecting when a non-crippling programming language finally exists - someone generates a not-necessarily performant but fully spec-compliant js implementation with some strikingly tiny effort. A few days.
mras0 8y ago
Good luck with your project, for now you should trust the other implementations more :) But I've tried to keep the code reasonably small and (hopefully) readable - which is why it's currently targeting ES1997 - rather than having lots of features, so it's probably more understandable than V8.