playX

We need faster and easier to use calling convention. For this purpose we have to know function stack size ahead of time (done in 0f5d078e1399c7ef41e45ecb298fcffd57d4571c) and allocate memory on the...

Variables broken

1

```js let x = 0; function f() { let x = 1; g(); print(x); } function g() { print(x); x = 2; } ``` ``` Code block 'f' at 0x7f4e715d3718:...

Support for "unsafe" cases of `finally`

1

Starlight needs support for code like this: ```js function foo() { try { return 1; } finally { return 2; } } ``` Right now it returns `1` but should...

It would be nice if using CI we could provide daily builds of starlight. We might build them per commit or once a day (if it is possible).

When #93 will be merged we should implement `$262` object: https://github.com/tc39/test262/blob/main/INTERPRETING.md#host-defined-functions

Compressed pointers

1

With the new heap layout, we can implement compressed GC pointers. I'll work on it.

This should allow running JS code in the specific realm much easier. Also we probably want to define `pub type JsGlobalObject = TypedJsObject`. Inside JsGlobal we have to add `RuntimRef`...

Deprecate shadow stack

1

Since GC now can find pointers to the heap on the stack shadow stack is almost useless now. Depends on #73 so we can find JS values on the stack.

Add codegen support for builtin calls in self-hosted builtins.

3

We could make all calls to all functions prefixed with `__` transform into bytecode sequences rather than real calls to builtins. This should be done ***only*** when compiling self-hosted builtins.

Start prototyping JIT compiler

1

Since Starlight aims to be a fast JS engine JIT compiler is necessary but there are still unresolved questions: - What JIT technique to use? Tracing JIT or Method JIT?...