4 ms·

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 c

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 FFI, what's the benefit vs. e.g. C++11? The latter has nice language features too but compiles to much smaller native code!

jononor 10y ago
Nice thing about pain-free FFI is that you can move functionality between the scripting-layer and engine-layer as you see fit. Start in JS, perhaps move pieces down to compiled-lang as they solidify or perf becomes an issue. Maybe only the high-level logic is JS. Or maybe you have JS as "plugin" extension points. Or one could design a domain-specialized "framework", and use JS as the embedding language for an embedded DSL. Acheivable performance would depend a lot on such architectural decisions. With C++ one would unfortunately have to create C-wrappers, but with say something with easier C interop like Nim or Rust.
hackcasual 10y ago
I'd wager a large amount of that is handling symbol lookup for calling through the FFI.
- nneonneo 10y ago
  I quote the mJS readme from the repo: > In order to make FFI work, mJS must be able to get the address of a C function by its name. On POSIX systems, dlsym() API can do that. On Windows, GetProcAddress(). On embedded systems, a system resolver should be either manually written, or be implemented with some aid from a firmware linker script. So I guess they don't provide any implementation for their FFI linking on embedded platforms? It's not clear if the 25k size figure includes any dlsym support, but if it requires instrumenting your firmware image on-disk then the size costs could balloon significantly.
  - drozd 10y ago
    Currently we use mJS in our Mongoose OS firmware framework. There, a symbol resolver is generated automatically from the configuration file which tells which symbols you'd like to use. https://github.com/cesanta/mongoose-os/blob/master/fw/examples/mjs_hello/mos.yml https://github.com/cesanta/mongoose-os/blob/master/fw/exampl...
swiley 10y ago
Will it run it in real time is the important thing.
TazeTSchnitzel 10y ago
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.
- phire 10y ago
  If you want to support eval, then the whole parser/compiler needs to be on the device. But do you really need eval?
- nneonneo 10y ago
  mJS appears to include the parser and compiler, as it seems capable of running code dynamically.
kbumsik 10y ago
1kb RAM and 25k of flash is impressively low for Javascript engines for embedded system. I know it is still heavy for MCUs. Other JS engine implementations like Ducktape [1] and Jerryscript [2] takes more than 10kb of RAM and 150 of FLASH. Javascript is simply much heavier you might think. But I personally don't see any benefits neither. [1] http://duktape.org/ http://duktape.org/ [2] http://jerryscript.net/ http://jerryscript.net/

jononor 10y ago

Nice thing about pain-free FFI is that you can move functionality between the scripting-layer and engine-layer as you see fit. Start in JS, perhaps move pieces down to compiled-lang as they solidify or perf becomes an issue. Maybe only the high-level logic is JS. Or maybe you have JS as "plugin" extension points. Or one could design a domain-specialized "framework", and use JS as the embedding language for an embedded DSL. Acheivable performance would depend a lot on such architectural decisions. With C++ one would unfortunately have to create C-wrappers, but with say something with easier C interop like Nim or Rust.

hackcasual 10y ago

I'd wager a large amount of that is handling symbol lookup for calling through the FFI.

nneonneo 10y ago
I quote the mJS readme from the repo: > In order to make FFI work, mJS must be able to get the address of a C function by its name. On POSIX systems, dlsym() API can do that. On Windows, GetProcAddress(). On embedded systems, a system resolver should be either manually written, or be implemented with some aid from a firmware linker script. So I guess they don't provide any implementation for their FFI linking on embedded platforms? It's not clear if the 25k size figure includes any dlsym support, but if it requires instrumenting your firmware image on-disk then the size costs could balloon significantly.
- drozd 10y ago
  Currently we use mJS in our Mongoose OS firmware framework. There, a symbol resolver is generated automatically from the configuration file which tells which symbols you'd like to use. https://github.com/cesanta/mongoose-os/blob/master/fw/examples/mjs_hello/mos.yml https://github.com/cesanta/mongoose-os/blob/master/fw/exampl...

swiley 10y ago

Will it run it in real time is the important thing.

TazeTSchnitzel 10y ago

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.

phire 10y ago
If you want to support eval, then the whole parser/compiler needs to be on the device. But do you really need eval?
nneonneo 10y ago
mJS appears to include the parser and compiler, as it seems capable of running code dynamically.

kbumsik 10y ago

1kb RAM and 25k of flash is impressively low for Javascript engines for embedded system. I know it is still heavy for MCUs. Other JS engine implementations like Ducktape [1] and Jerryscript [2] takes more than 10kb of RAM and 150 of FLASH. Javascript is simply much heavier you might think. But I personally don't see any benefits neither. [1] http://duktape.org/ http://duktape.org/ [2] http://jerryscript.net/ http://jerryscript.net/