Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add experimental support for mapping bytecode to an external data area #1409

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

svaarala
Copy link
Owner

@svaarala svaarala commented Mar 17, 2017

Add DUK_USE_EXTBC_CHECK() which allows an application to map the bytecode of a function to an external data area. This allows Ecmascript function bytecode to be e.g. copied to memory-mapped flash which reduces actual RAM usage; usefulness depends on the target architecture.

This is a very early experimental version: DUK_USE_EXTBC_CHECK() is called and if it returns a non-NULL pointer the bytecode is used from the pointer provided. There's no GC integration: the application must ensure that the external pointer remains valid for the lifetime of the Ecmascript function (without having any hook to know that).

Tasks:

  • Working prototype
  • duk_hcompfunc.h review; conditional fields? size fields?
  • Documentation
  • Ajduk example
  • Releases entry

@svaarala svaarala added this to the v2.1.0 milestone Mar 17, 2017
* Add config option DUK_USE_EXTBC_CHECK.

* Update low memory example with DUK_USE_EXTBC_CHECK (commented out).
Initial experimental external bytecode support:

* Add a hook into the compiler: when the final function template is being
  created, create the fixed buffer and then offer the bytecode opcode part
  to a used provided DUK_USE_EXTBC_CHECK() macro to see if it should be
  mapped to a user supplied data area.

* For now there's no release mechanism: user code can free the mapped data
  area when it's 100% Duktape cannot be referencing it any longer.  Ideally
  there would be a lifecycle notification.

* Change duk_hbuffer pointer typing to duk_uint8_t: use "duk_uint8_t *"
  instead of "void *".
@svaarala svaarala force-pushed the external-bytecode-buffer-initial branch from dd2a84b to b9fbcad Compare April 8, 2017 02:36
@svaarala svaarala modified the milestones: v2.2.0, v2.1.0 Apr 8, 2017
@svaarala svaarala modified the milestones: v2.3.0, v2.2.0 Sep 6, 2017
@svaarala svaarala removed this from the v2.3.0 milestone May 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant