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

What if Nova was a Typescript engine? #427

Open
aurium opened this issue Oct 4, 2024 · 1 comment
Open

What if Nova was a Typescript engine? #427

aurium opened this issue Oct 4, 2024 · 1 comment

Comments

@aurium
Copy link

aurium commented Oct 4, 2024

Typescript is no longer a niche language. Large projects and small solutions are written directly in Typescript.

Node, Deno and Bun support TS as something to be converted (lost) on the fly, not as something that can enable important optimizations at runtime. Nova is just another one doing the same.

Just as an engine can be more performant manipulating numbers in a Float64Array than in a generic Array, some runtime benefit can be gained by arr: number = []

When a function is called with incompatible arguments, the engine will not allow the fate to decide application result... In this case the execution will stop and an exception should be thrown. With this approach other optimizations can be achieved, for example: (a:number, b:number)=> a + b, where the + operator will always be an arithmetic operator (no string concatenation will be possible) and no elaborate conversion should be expected.

I've already seen that @load1n9 is moving in this direction, especially working on enums support.

I think Nova should to be a TS first engine to achieve this goal, and JS code will need to receive generic typing (any everywhere) to run. I believe this is positive, so that any project will benefit when at least one module provides typing.

@aapoalas
Copy link
Collaborator

aapoalas commented Oct 5, 2024

Porffor actually does this, so we wouldn't be the first :)

But: This is somewhat the plan for the typescript flag, or at least for some typescript-strict flag perhaps? The problem with this as it stands is that the VM isn't built to take advantage of these sorts of optimisations. We have only one instruction for doing + and it handles both string concatenation and arithmetic (number and bigint) sum together.

One of the reasons why the instruction set is so limited is because the instructions are 8 bit numbers: This is much too limited a number range to really have specialised instructions. (The main reason is lack of time and effort, though.) If we eventually move to 16 bit integer instructions though, then we can much more readily add optimised instruction variants. And if optimised variants become the norm then the VM design itself may deserve a change to better reflect that with eg. separate stacks for Value types, references, and stack values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants