Live data from Hacker News

mJS – A new approach to embedded scripting

mongoose-iot.com

41–50 of 61 posts

Re: mJS – A new approach to embedded scripting

#41

25k of flash space sounds like a lot for what is effectively just a JavaScript parser and interpreter. I recall the days when you could fit a whole language's compiler into a few measly KB. 1KB RAM is also quite a lot for certain boards, especially if it has to be stack or SRAM. How's the performance? Will my 72MHz Cortex or 16MHz Arduino be able to run interesting things with mJS? If I have to do everything through…

Ideally none of the flash space is spent on a parser/compiler, that's quite wasteful if you could compile bytecode offline.

I don't know if you can do that with mJS, alas.

Re: mJS – A new approach to embedded scripting

#42
post #40
post #39

> One common thing these projects share is an attempt to implement the whole language specification, together with the more or less complete standard library Not in the case of Lua. Well, the "whole language" part is correct, but Lua is a very tiny language spec. It's "standard library", however, is the opposite of "complete".

> none of the popular scripting languages have been designed for the embedded environment in the first place Also false for Lua. It is designed to be embedded.

Embedded environment in this context means hardware low on resources, e.g. microcontrollers. Your perception of that word is "embedded into the C/C++ program". These are two different things. I agree that Lua (like some other languages) were designed to be embedded into C/C++ apps.

Re: mJS – A new approach to embedded scripting

#43
post #37
post #29

Earlier quoted context omitted.

There is no yacc code in either V7 or mJS. V7 uses hand-written recursive-descent parser. Initially, it was using ordinary C functions, and that created a problem on systems with low stack size. E.g. each '(' starts statement parsing from the top, so 1 + (2 + (3 + (4 + 5))) consumed stack, and sometimes resulted in stack overflow in e.g. interrupt handlers or network callbacks. Therefore we have rewritten recursive d…

So it is API compatible with V7?

Nope. It's similar though, cause some of the concepts, and the code, were reused. mJS does not need an embedding API, really. The intent is that FFI is used.

Re: mJS – A new approach to embedded scripting

#44
post #34

This looks a lot like Lua's FFI interface[0], which is a compliment (but contradicts the statement that this sort of FFI is "the feature that no other engine implemented so far"). Nicely done. [0] http://csl.sublevel3.org/post/luajit-cpp/

Nice! I wasn't aware of lua ffi api, thank you!

Re: mJS – A new approach to embedded scripting

#45
post #33
post #21

As light weight, easily embeddable JS engines go, I'd like to mention Duktape[0]. But the FFI of mJS does look quite a bit nicer.

Duktape is nice, and I've mentioned it in the article. However it's quite fat, and can't be used on some boards like ESP8266. It's flash footprint is Megabytes, whereas mJS flash footprint is ~25k.

Duktape website:

"Embeddable, portable, compact: can run on platforms with 192kB flash and 64kB system RAM"

Re: mJS – A new approach to embedded scripting

#47
post #45
post #33

Earlier quoted context omitted.

Duktape is nice, and I've mentioned it in the article. However it's quite fat, and can't be used on some boards like ESP8266. It's flash footprint is Megabytes, whereas mJS flash footprint is ~25k.

Duktape website: "Embeddable, portable, compact: can run on platforms with 192kB flash and 64kB system RAM"

Also http://www.esp32.com/viewtopic.php?t=497

Re: mJS – A new approach to embedded scripting

#49

25k of flash space sounds like a lot for what is effectively just a JavaScript parser and interpreter. I recall the days when you could fit a whole language's compiler into a few measly KB. 1KB RAM is also quite a lot for certain boards, especially if it has to be stack or SRAM. How's the performance? Will my 72MHz Cortex or 16MHz Arduino be able to run interesting things with mJS? If I have to do everything through…

Ideally none of the flash space is spent on a parser/compiler, that's quite wasteful if you could compile bytecode offline. I don't know if you can do that with mJS, alas.

If you want to support eval, then the whole parser/compiler needs to be on the device.

But do you really need eval?

Re: mJS – A new approach to embedded scripting

#50

25k of flash space sounds like a lot for what is effectively just a JavaScript parser and interpreter. I recall the days when you could fit a whole language's compiler into a few measly KB. 1KB RAM is also quite a lot for certain boards, especially if it has to be stack or SRAM. How's the performance? Will my 72MHz Cortex or 16MHz Arduino be able to run interesting things with mJS? If I have to do everything through…

Ideally none of the flash space is spent on a parser/compiler, that's quite wasteful if you could compile bytecode offline. I don't know if you can do that with mJS, alas.

mJS appears to include the parser and compiler, as it seems capable of running code dynamically.
Post reply on HN