Neat. Although languages which are "almost, but not quite " are, I would say, harder for people who know to learn than languages that are entirely different from .
mJS – A new approach to embedded scripting
31–40 of 61 posts
Re: mJS – A new approach to embedded scripting
#32Earlier quoted context omitted.
None of which are particularly appropriate for embedded programming.
Agreed that on-a-whole JS is not appropriate for embedded devices. However allowing scripting may be useful in particular pieces of the code, to allow easy extension / customization.
I recall that very much the same opinions were expressed about the JS and backend programming, until node.js appeared. Now the reality is different.
To be honest, we do not think that JS is a good language for embedded. Like any other existing popular scripting language. Perhaps scripted Go would be a better choice.
The point is that in many, many cases scripting brings a lot of benefits to the embedded environment. It all depends on a specific tasks - for some tasks, scripting will never be appropriate.
Re: mJS – A new approach to embedded scripting
#33As 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.
Re: mJS – A new approach to embedded scripting
#34This 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.
Re: mJS – A new approach to embedded scripting
#35Espruino's had an FFI interface for the last 3 years! Nice to see they did their research :)
Re: mJS – A new approach to embedded scripting
#36Seems a little crazy that there's no support for closures.
Re: mJS – A new approach to embedded scripting
#37Earlier quoted context omitted.
i wonder if the size could be reduced by replacing the yacc code with a hand-written parser.
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?
Re: mJS – A new approach to embedded scripting
#3825k 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…
Will it run it in real time is the important thing.
Re: mJS – A new approach to embedded scripting
#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".
Re: mJS – A new approach to embedded scripting
#40> 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.