porffor 0.2.0-50b82f8 → 0.2.0-525c695

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (53) hide show
  1. package/CONTRIBUTING.md +246 -0
  2. package/LICENSE +20 -20
  3. package/README.md +159 -83
  4. package/asur/README.md +2 -0
  5. package/asur/index.js +1262 -0
  6. package/byg/index.js +237 -0
  7. package/compiler/2c.js +317 -72
  8. package/compiler/{sections.js → assemble.js} +64 -16
  9. package/compiler/builtins/annexb_string.js +72 -0
  10. package/compiler/builtins/annexb_string.ts +18 -0
  11. package/compiler/builtins/array.ts +145 -0
  12. package/compiler/builtins/base64.ts +151 -0
  13. package/compiler/builtins/crypto.ts +120 -0
  14. package/compiler/builtins/date.ts +2071 -0
  15. package/compiler/builtins/escape.ts +141 -0
  16. package/compiler/builtins/int.ts +147 -0
  17. package/compiler/builtins/number.ts +527 -0
  18. package/compiler/builtins/porffor.d.ts +59 -0
  19. package/compiler/builtins/string.ts +1055 -0
  20. package/compiler/builtins/tostring.ts +45 -0
  21. package/compiler/builtins.js +580 -272
  22. package/compiler/{codeGen.js → codegen.js} +1257 -408
  23. package/compiler/decompile.js +3 -4
  24. package/compiler/embedding.js +22 -22
  25. package/compiler/encoding.js +108 -10
  26. package/compiler/generated_builtins.js +1481 -0
  27. package/compiler/index.js +36 -34
  28. package/compiler/log.js +6 -3
  29. package/compiler/opt.js +56 -30
  30. package/compiler/parse.js +33 -23
  31. package/compiler/precompile.js +128 -0
  32. package/compiler/prefs.js +27 -0
  33. package/compiler/prototype.js +177 -37
  34. package/compiler/types.js +37 -0
  35. package/compiler/wasmSpec.js +31 -7
  36. package/compiler/wrap.js +141 -43
  37. package/package.json +9 -5
  38. package/porf +4 -0
  39. package/rhemyn/compile.js +46 -27
  40. package/rhemyn/parse.js +322 -320
  41. package/rhemyn/test/parse.js +58 -58
  42. package/runner/compare.js +34 -34
  43. package/runner/debug.js +122 -0
  44. package/runner/index.js +91 -11
  45. package/runner/profiler.js +102 -0
  46. package/runner/repl.js +42 -9
  47. package/runner/sizes.js +37 -37
  48. package/compiler/builtins/base64.js +0 -92
  49. package/runner/info.js +0 -89
  50. package/runner/profile.js +0 -46
  51. package/runner/results.json +0 -1
  52. package/runner/transform.js +0 -15
  53. package/util/enum.js +0 -20
@@ -0,0 +1,246 @@
1
+ # Contributing to Porffor
2
+
3
+ Hello! Thanks for your potential interest in contributing to Porffor :)
4
+
5
+ This document hopes to help you understand Porffor-specific TS, specifically for writing built-ins (inside `compiler/builtins/*.ts` eg `btoa`, `String.prototype.trim`, ...). This guide isn't really meant for modifying the compiler itself yet (eg `compiler/codegen.js`), as built-ins are ~easier to implement and more useful at the moment.
6
+
7
+ I mostly presume decent JS knowledge, with some basic TS too but nothing complicated. Knowing low-level stuff generally (pointers, etc) and/or Wasm (bytecode) is also a plus but hopefully not required.
8
+
9
+ If you have any questions you can ask in [the Porffor Discord](https://discord.gg/6crs9Znx9R), please feel free to ask anything if you get stuck :)
10
+
11
+ Please read this entire document before beginning as there are important things throughout.
12
+
13
+ <br>
14
+
15
+ ## Setup
16
+
17
+ 1. Clone the repo and enter the repo (`git clone https://github.com/CanadaHonk/porffor.git`)
18
+ 2. `npm install`
19
+
20
+ ### Precompile
21
+
22
+ **If you update any file inside `compiler/builtins` you will need to do this for it to update inside Porffor otherwise your changes will have no effect.** Run `node compiler/precompile.js` to precompile. It may error during this, if so, you might have an error in your code or there could be a compiler error with Porffor (feel free to ask for help as soon as you encounter any errors with it).
23
+
24
+ <br>
25
+
26
+ ## Types
27
+
28
+ Porffor has usual JS types (or at least the ones it supports), but also internal types for various reasons.
29
+
30
+ ### ByteString
31
+
32
+ The most important and widely used internal type is ByteString (also called `bytestring` or `_bytestring` in code). Regular strings in Porffor are UTF-16 encoded, so each character uses 2 bytes. ByteStrings are special strings which are used when the characters in a string only use ASCII/LATIN-1 characters, so the lower byte of the UTF-16 characters are unused. Instead of wasting memory with all the unused memory, ByteStrings instead use 1 byte per character. This halves memory usage of such strings and also makes operating on them faster. The downside is that many Porffor built-ins have to be written twice, slightly different, for both `String` and `ByteString` types.
33
+
34
+ ### i32
35
+
36
+ This is complicated internally but essentially, only use it for pointers. (This is not signed or unsigned, instead it is the Wasm valtype `i32` so the signage is ~instruction dependant).
37
+
38
+ <br>
39
+
40
+ ## Pointers
41
+
42
+ Pointers are the main (and most difficult) unique feature you ~need to understand when dealing with objects (arrays, strings, ...).
43
+
44
+ We'll explain things per common usage you will likely need to know:
45
+
46
+ ## Commonly used Wasm code
47
+
48
+ ### Get a pointer
49
+
50
+ ```js
51
+ Porffor.wasm`local.get ${foobar}`
52
+ ```
53
+
54
+ Gets the pointer to the variable `foobar`. You don't really need to worry about how it works in detail, but essentially it gets the pointer as a number (type) instead of as the object it is.
55
+
56
+ ### Store a character in a ByteString
57
+
58
+ ```js
59
+ Porffor.wasm.i32.store8(pointer, characterCode, 0, 4)
60
+ ```
61
+
62
+ Stores the character code `characterCode` at the pointer `pointer` **for a ByteString**.[^1]
63
+
64
+ ### Store a character in a String
65
+
66
+ ```js
67
+ Porffor.wasm.i32.store16(pointer, characterCode, 0, 4)
68
+ ```
69
+
70
+ Stores the character code `characterCode` at the pointer `pointer` **for a String**.[^1]
71
+
72
+ ### Load a character from a ByteString
73
+
74
+ ```js
75
+ Porffor.wasm.i32.load8_u(pointer, 0, 4)
76
+ ```
77
+
78
+ Loads the character code at the pointer `pointer` **for a ByteString**.[^1]
79
+
80
+ ### Load a character from a String
81
+
82
+ ```js
83
+ Porffor.wasm.i32.load16_u(pointer, 0, 4)
84
+ ```
85
+
86
+ Loads the character code at the pointer `pointer` **for a String**.[^1]
87
+
88
+ ### Manually store the length of an object
89
+
90
+ ```js
91
+ Porffor.wasm.i32.store(pointer, length, 0, 0)
92
+ ```
93
+
94
+ Stores the length `length` at pointer `pointer`, setting the length of an object. This is mostly unneeded today as you can just do `obj.length = length`. [^2]
95
+
96
+ <br>
97
+
98
+ ## Example
99
+
100
+ Here is the code for `ByteString.prototype.toUpperCase()`:
101
+
102
+ ```ts
103
+ export const ___bytestring_prototype_toUpperCase = (_this: bytestring) => {
104
+ const len: i32 = _this.length;
105
+
106
+ let out: bytestring = '';
107
+ Porffor.wasm.i32.store(out, len, 0, 0);
108
+
109
+ let i: i32 = Porffor.wasm`local.get ${_this}`,
110
+ j: i32 = Porffor.wasm`local.get ${out}`;
111
+
112
+ const endPtr: i32 = i + len;
113
+ while (i < endPtr) {
114
+ let chr: i32 = Porffor.wasm.i32.load8_u(i++, 0, 4);
115
+
116
+ if (chr >= 97) if (chr <= 122) chr -= 32;
117
+
118
+ Porffor.wasm.i32.store8(j++, chr, 0, 4);
119
+ }
120
+
121
+ return out;
122
+ };
123
+ ```
124
+
125
+ Now let's go through it section by section:
126
+
127
+ ```ts
128
+ export const ___bytestring_prototype_toUpperCase = (_this: bytestring) => {
129
+ ```
130
+
131
+ Here we define a built-in for Porffor. Notably:
132
+ - We do not use `a.b.c`, instead we use `__a_b_c`
133
+ - The ByteString type is actually `_bytestring`, as internal types have an extra `_` at the beginning (this is due to be fixed/simplified soon(tm))
134
+ - We use a `_this` argument, as `this` does not exist in Porffor yet
135
+ - We use an arrow function
136
+
137
+ ---
138
+
139
+ ```ts
140
+ const len: i32 = _this.length;
141
+
142
+ let out: bytestring = '';
143
+ Porffor.wasm.i32.store(out, len, 0, 0);
144
+ ```
145
+
146
+ This sets up the `out` variable we are going to write to for the output of this function. We set the length in advance to be the same as `_this`, as `foo.length == foo.toLowerCase().length`, because we will later be manually writing to it using Wasm instrinsics, which will not update the length themselves.
147
+
148
+ ---
149
+
150
+ ```ts
151
+ let i: i32 = Porffor.wasm`local.get ${_this}`,
152
+ j: i32 = Porffor.wasm`local.get ${out}`;
153
+ ```
154
+
155
+ Get the pointers for `_this` and `out` as `i32`s (~`number`s).
156
+
157
+ ---
158
+
159
+ ```ts
160
+ const endPtr: i32 = i + len;
161
+ while (i < endPtr) {
162
+ ```
163
+
164
+ Set up an end target pointer as the pointer variable for `_this` plus the length of it. Loop below until that pointer reaches the end target, so we iterate through the entire string.
165
+
166
+ ---
167
+
168
+ ```ts
169
+ let chr: i32 = Porffor.wasm.i32.load8_u(i++, 0, 4);
170
+ ```
171
+
172
+ Read the character (code) from the current `_this` pointer variable, and increment it so next iteration it reads the next character, etc.
173
+
174
+ ---
175
+
176
+ ```ts
177
+ if (chr >= 97) if (chr <= 122) chr -= 32;
178
+ ```
179
+
180
+ If the character code is >= 97 (`a`) and <= 122 (`z`), decrease it by 32, making it an upper case character. eg: 97 (`a`) - 32 = 65 (`A`).
181
+
182
+ ---
183
+
184
+ ```ts
185
+ Porffor.wasm.i32.store8(j++, chr, 0, 4);
186
+ ```
187
+
188
+ Store the character code into the `out` pointer variable, and increment it.
189
+
190
+ <br>
191
+
192
+ ## Porffor-specific TS notes
193
+
194
+ - For declaring variables, you must use explicit type annotations currently (eg `let a: number = 1`, not `let a = 1`)
195
+ - You might spot `Porffor.fastOr`/`Porffor.fastAnd`, these are non-short circuiting versions of `||`/`&&`, taking any number of conditions as arguments. You shouldn't don't need to use or worry about these.
196
+
197
+ <br>
198
+
199
+ ## Formatting/linting
200
+
201
+ There is 0 setup for this (right now). You can try looking through the other built-ins files but do not worry about it a lot, I honestly do not mind going through and cleaning up after a PR as long as the code itself is good :^)
202
+
203
+ <br>
204
+
205
+ ## Commit (message) style
206
+
207
+ You should ideally have one commit per notable change (using amend/force push). Commit messages should be like `${file}: ${description}`. Don't be afraid to use long titles if needed, but try and be short if possible. Bonus points for detail in commit description. ~~Gold star for jokes in description too.~~
208
+
209
+ Examples:
210
+ ```
211
+ builtins/date: impl toJSON
212
+ builtins/date: fix ToIntegerOrInfinity returning -0
213
+ codegen: fix inline wasm for unreachable
214
+ builtins/array: wip toReversed
215
+ builtins/tostring_number: impl radix
216
+ ```
217
+
218
+ <br>
219
+
220
+ ## Test262
221
+
222
+ Make sure you have Test262 cloned already **inside of `test262/`** (`git clone https://github.com/tc39/test262.git test262/test262`).
223
+
224
+ Run `node test262` to run all the tests and get an output of total overall test results. The main thing you want to pay attention to is the emoji summary (lol):
225
+ ```
226
+ 🧪 50005 | 🤠 7007 (-89) | ❌ 1914 (-32) | 💀 13904 (-61) | 📝 23477 (-120) | ⏰ 2 | 🏗 2073 (+302) | 💥 1628
227
+ ```
228
+
229
+ To break this down:
230
+ 🧪 total 🤠 pass ❌ fail 💀 runtime error 📝 todo (error) ⏰ timeout 🏗️ wasm compile error 💥 compile error
231
+
232
+ The diff compared to the last commit (with test262 data) is shown in brackets. Basically, you can passes 🤠 up, and errors 💀📝🏗💥 down. It is fine if some errors change balance/etc, as long as they are not new failures.
233
+
234
+ It will also log new passes/fails. Be careful as sometimes the overall passes can increase, but other files have also regressed into failures which you might miss. Also keep in mind some tests may have been false positives before, but we can investigate the diff together :)
235
+
236
+ ### Debugging tips
237
+
238
+ - Use `node test262 path/to/tests` to run specific test262 dirs/files (eg `node test262 built-ins/Date`).
239
+ - Use `--log-errors` to log the errors of individual tests.
240
+ - Use `--debug-asserts` to log expected/actual of assertion failures (experimental).
241
+
242
+ <br>
243
+
244
+ [^1]: The `0, 4` args are necessary for the Wasm instruction, but you don't need to worry about them (`0` alignment, `4` byte offset for length).
245
+
246
+ [^2]: The `0, 4` args are necessary for the Wasm instruction, but you don't need to worry about them (`0` alignment, `0` byte offset).
package/LICENSE CHANGED
@@ -1,21 +1,21 @@
1
- MIT License
2
-
3
- Copyright (c) 2023 CanadaHonk
4
-
5
- Permission is hereby granted, free of charge, to any person obtaining a copy
6
- of this software and associated documentation files (the "Software"), to deal
7
- in the Software without restriction, including without limitation the rights
8
- to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
- copies of the Software, and to permit persons to whom the Software is
10
- furnished to do so, subject to the following conditions:
11
-
12
- The above copyright notice and this permission notice shall be included in all
13
- copies or substantial portions of the Software.
14
-
15
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
- IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
- FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
- AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
- LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
- OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
1
+ MIT License
2
+
3
+ Copyright (c) 2023 CanadaHonk
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
21
  SOFTWARE.
package/README.md CHANGED
@@ -10,6 +10,80 @@ Porffor is a very unique JS engine, due many wildly different approaches. It is
10
10
 
11
11
  Porffor is primarily built from scratch, the only thing that is not is the parser (using [Acorn](https://github.com/acornjs/acorn)). Binaryen/etc is not used, we make final wasm binaries ourself. You could imagine it as compiling a language which is a sub (some things unsupported) and super (new/custom apis) set of javascript. Not based on any particular spec version, focusing on function/working over spec compliance.
12
12
 
13
+ ## Usage
14
+ Expect nothing to work! Only very limited JS is currently supported. See files in `bench` for examples.
15
+
16
+ ### Setup
17
+ **`npm install -g porffor`**. It's that easy (hopefully) :)
18
+
19
+ ### Trying a REPL
20
+ **`porf`**. Just run it with no script file argument.
21
+
22
+ ### Running a JS file
23
+ **`porf path/to/script.js`**
24
+
25
+ ### Compiling to Wasm
26
+ **`porf wasm path/to/script.js out.wasm`**. Currently it does not use an import standard like WASI, so it is mostly unusable on its own.
27
+
28
+ ### Compiling to native binaries
29
+ > [!WARNING]
30
+ > Compiling to native binaries uses [2c](#2c), Porffor's own Wasm -> C compiler, which is experimental.
31
+
32
+ **`porf native path/to/script.js out(.exe)`**. You can specify the compiler with `--compiler=clang/zig/gcc`, and which opt level to use with `--cO=O3` (`Ofast` by default). Output binaries are also stripped by default.
33
+
34
+ ### Compiling to C
35
+ > [!WARNING]
36
+ > Compiling to C uses [2c](#2c), Porffor's own Wasm -> C compiler, which is experimental.
37
+
38
+ **`porf c path/to/script.js (out.c)`**. When not including an output file, it will be printed to stdout instead.
39
+
40
+ ### Profiling a JS file
41
+ > [!WARNING]
42
+ > Very experimental WIP feature!
43
+
44
+ **`porf profile path/to/script.js`**
45
+
46
+ ### Debugging a JS file
47
+ > [!WARNING]
48
+ > Very experimental WIP feature!
49
+
50
+ **`porf debug path/to/script.js`**
51
+
52
+ ### Profiling the generated Wasm of a JS file
53
+ > [!WARNING]
54
+ > Very experimental WIP feature!
55
+
56
+ **`porf debug-wasm path/to/script.js`**
57
+
58
+
59
+ ### Options
60
+ - `--parser=acorn|@babel/parser|meriyah|hermes-parser` (default: `acorn`) to set which parser to use
61
+ - `--parse-types` to enable parsing type annotations/typescript. if `-parser` is unset, changes default to `@babel/parser`. does not type check
62
+ - `--opt-types` to perform optimizations using type annotations as compiler hints. does not type check
63
+ - `--valtype=i32|i64|f64` (default: `f64`) to set valtype
64
+ - `-O0` to disable opt
65
+ - `-O1` (default) to enable basic opt (simplify insts, treeshake wasm imports)
66
+ - `-O2` to enable advanced opt (inlining). unstable
67
+ - `-O3` to enable advanceder opt (precompute const math). unstable
68
+ - `--no-run` to not run wasm output, just compile
69
+ - `--opt-log` to log some opts
70
+ - `--code-log` to log some codegen (you probably want `-funcs`)
71
+ - `--regex-log` to log some regex
72
+ - `--funcs` to log funcs
73
+ - `--ast-log` to log AST
74
+ - `--opt-funcs` to log funcs after opt
75
+ - `--sections` to log sections as hex
76
+ - `--opt-no-inline` to not inline any funcs
77
+ - `--tail-call` to enable tail calls (experimental + not widely implemented)
78
+ - `--compile-hints` to enable V8 compilation hints (experimental + doesn't seem to do much?)
79
+
80
+ ### Running in the repo
81
+ The repo comes with easy alias files for Unix and Windows, which you can use like so:
82
+ - Unix: `./porf path/to/script.js`
83
+ - Windows: `.\porf path/to/script.js`
84
+
85
+ Please note that further examples below will just use `./porf`, you need to use `.\porf` on Windows. You can also swap out `node` in the alias to use another runtime like Deno (`deno run -A`) or Bun (`bun ...`), or just use it yourself (eg `node runner/index.js ...`, `bun runner/index.js ...`). Node and Bun should work great, Deno support is WIP.
86
+
13
87
  ## Limitations
14
88
  - No full object support yet
15
89
  - Little built-ins/prototype
@@ -18,10 +92,15 @@ Porffor is primarily built from scratch, the only thing that is not is the parse
18
92
  - Literal callees only in calls (eg `print()` works, `a = print; a()` does not)
19
93
  - No `eval()` etc (since it is AOT)
20
94
 
21
- ## Rhemyn
95
+ ## Sub-engines
96
+
97
+ ### Asur
98
+ Asur is Porffor's own Wasm engine; it is an intentionally simple interpreter written in JS. It is very WIP. See [its readme](asur/README.md) for more details.
99
+
100
+ ### Rhemyn
22
101
  Rhemyn is Porffor's own regex engine; it compiles literal regex to Wasm bytecode AOT (remind you of anything?). It is quite basic and WIP. See [its readme](rhemyn/README.md) for more details.
23
102
 
24
- ## 2c
103
+ ### 2c
25
104
  2c is Porffor's own Wasm -> C compiler, using generated Wasm bytecode and internal info to generate specific and efficient/fast C code. Little boilerplate/preluded code or required external files, just for CLI binaries (not like wasm2c very much).
26
105
 
27
106
  ## Supported
@@ -86,20 +165,29 @@ These include some early (stage 1/0) and/or dead (last commit years ago) proposa
86
165
  - `for...of` (arrays and strings)
87
166
  - Array member setting (`arr[0] = 2`, `arr[0] += 2`, etc)
88
167
  - Array constructor (`Array(5)`, `new Array(1, 2, 3)`)
168
+ - Labelled statements (`foo: while (...)`)
169
+ - `do...while` loops
89
170
 
90
171
  ### Built-ins
91
172
 
92
- - `NaN` and `Infinity` (f64 only)
93
- - `isNaN()` and `isFinite()` (f64 only)
94
- - Most of `Number` (`MAX_VALUE`, `MIN_VALUE`, `MAX_SAFE_INTEGER`, `MIN_SAFE_INTEGER`, `POSITIVE_INFINITY`, `NEGATIVE_INFINITY`, `EPSILON`, `NaN`, `isNaN`, `isFinite`, `isInteger`, `isSafeInteger`) (some f64 only)
95
- - Some `Math` funcs (`Math.sqrt`, `Math.abs`, `Math.floor`, `Math.sign`, `Math.round`, `Math.trunc`, `Math.clz32`, `Math.fround`, `Math.random`) (f64 only)
173
+ - `NaN` and `Infinity`
174
+ - `isNaN()` and `isFinite()`
175
+ - Most of `Number` (`MAX_VALUE`, `MIN_VALUE`, `MAX_SAFE_INTEGER`, `MIN_SAFE_INTEGER`, `POSITIVE_INFINITY`, `NEGATIVE_INFINITY`, `EPSILON`, `NaN`, `isNaN`, `isFinite`, `isInteger`, `isSafeInteger`)
176
+ - Some `Math` funcs (`sqrt`, `abs`, `floor`, `sign`, `round`, `trunc`, `clz32`, `fround`, `random`)
96
177
  - Basic `globalThis` support
97
178
  - Basic `Boolean` and `Number`
98
179
  - Basic `eval` for literals
99
180
  - `Math.random()` using self-made xorshift128+ PRNG
100
- - Some of `performance` (`now()`)
101
- - Some of `Array.prototype` (`at`, `push`, `pop`, `shift`, `fill`)
102
- - Some of `String.prototype` (`at`, `charAt`, `charCodeAt`)
181
+ - Some of `performance` (`now()`, `timeOrigin`)
182
+ - Some of `Array.prototype` (`at`, `push`, `pop`, `shift`, `fill`, `slice`, `indexOf`, `lastIndexOf`, `includes`, `with`, `reverse`, `toReversed`)
183
+ - Some of `Array` (`of`, `isArray`)
184
+ - Most of `String.prototype` (`at`, `charAt`, `charCodeAt`, `toUpperCase`, `toLowerCase`, `startsWith`, `endsWith`, `indexOf`, `lastIndexOf`, `includes`, `padStart`, `padEnd`, `substring`, `substr`, `slice`, `trimStart`, `trimEnd`, `trim`, `toString`, `big`, `blink`, `bold`, `fixed`, `italics`, `small`, `strike`, `sub`, `sup`, `trimLeft`, `trimRight`, )
185
+ - Some of `crypto` (`randomUUID`)
186
+ - `escape`
187
+ - `btoa`
188
+ - Most of `Number.prototype` (`toString`, `toFixed`, `toExponential`)
189
+ - `parseInt`
190
+ - Spec-compliant `Date`
103
191
 
104
192
  ### Custom
105
193
 
@@ -108,42 +196,8 @@ These include some early (stage 1/0) and/or dead (last commit years ago) proposa
108
196
  - Intrinsic functions (see below)
109
197
  - Inlining wasm via ``asm`...``\` "macro"
110
198
 
111
- ## Todo
112
- No particular order and no guarentees, just what could happen soon™
113
-
114
- - Arrays
115
- - More of `Array` prototype
116
- - Arrays/strings inside arrays
117
- - Destructuring
118
- - Objects
119
- - Basic object expressions (eg `{}`, `{ a: 0 }`)
120
- - Wasm
121
- - *Basic* Wasm engine (interpreter) in JS
122
- - More math operators (`**`, etc)
123
- - `do { ... } while (...)`
124
- - Rewrite `console.log` to work with strings/arrays
125
- - Exceptions
126
- - Rewrite to use actual strings (optional?)
127
- - `try { } finally { }`
128
- - Rethrowing inside catch
129
- - Optimizations
130
- - Rewrite local indexes per func for smallest local header and remove unused idxs
131
- - Smarter inline selection (snapshots?)
132
- - Remove const ifs (`if (true)`, etc)
133
- - Use type(script) information to remove unneeded typechecker code
134
- - Cool proposals
135
- - [Optional Chaining Assignment](https://github.com/tc39/proposal-optional-chaining-assignment)
136
- - [Modulus and Additional Integer Math](https://github.com/tc39/proposal-integer-and-modulus-math)
137
- - [Array Equality](https://github.com/tc39/proposal-array-equality)
138
- - [Declarations in Conditionals](https://github.com/tc39/proposal-Declarations-in-Conditionals)
139
- - [Seeded Pseudo-Random Numbers](https://github.com/tc39/proposal-seeded-random)
140
- - [`do` expressions](https://github.com/tc39/proposal-do-expressions)
141
- - [String Trim Characters](https://github.com/Kingwl/proposal-string-trim-characters)
142
-
143
199
  ## Performance
144
- *For the things it supports most of the time*, Porffor is blazingly fast compared to most interpreters, and common engines running without JIT. For those with JIT, it is not that much slower like a traditional interpreter would be; mostly the same or a bit faster/slower depending on what.
145
-
146
- ![Screenshot of comparison chart](https://github.com/CanadaHonk/porffor/assets/19228318/76c75264-cc68-4be1-8891-c06dc389d97a)
200
+ *For the features it supports most of the time*, Porffor is *blazingly fast* compared to most interpreters and common engines running without JIT. For those with JIT, it is usually slower by default, but can catch up with compiler arguments and typed input, even more so when compiling to native binaries.
147
201
 
148
202
  ## Optimizations
149
203
  Mostly for reducing size. I do not really care about compiler perf/time as long as it is reasonable. We do not use/rely on external opt tools (`wasm-opt`, etc), instead doing optimization inside the compiler itself creating even smaller code sizes than `wasm-opt` itself can produce as we have more internal information.
@@ -151,7 +205,7 @@ Mostly for reducing size. I do not really care about compiler perf/time as long
151
205
  ### Traditional opts
152
206
  - Inlining functions (WIP, limited)
153
207
  - Inline const math ops
154
- - Tail calls (behind flag `-tail-call`)
208
+ - Tail calls (behind flag `--tail-call`)
155
209
 
156
210
  ### Wasm transforms
157
211
  - `local.set`, `local.get` -> `local.tee`
@@ -165,10 +219,12 @@ Mostly for reducing size. I do not really care about compiler perf/time as long
165
219
  - Remove unneeded blocks (no `br`s inside)
166
220
  - Remove unused imports
167
221
  - Use data segments for initing arrays/strings
222
+ - (Likely more not documented yet, todo)
168
223
 
169
224
  ### Wasm module
170
225
  - Type cache/index (no repeated types)
171
226
  - No main func if empty (and other exports)
227
+ - No tags if unused/optimized out
172
228
 
173
229
  ## Test262
174
230
  Porffor can run Test262 via some hacks/transforms which remove unsupported features whilst still doing the same asserts (eg simpler error messages using literals only). It currently passes >10% (see latest commit desc for latest and details). Use `node test262` to test, it will also show a difference of overall results between the last commit and current results.
@@ -176,7 +232,7 @@ Porffor can run Test262 via some hacks/transforms which remove unsupported featu
176
232
  ## Codebase
177
233
  - `compiler`: contains the compiler itself
178
234
  - `builtins.js`: all built-ins of the engine (spec, custom. vars, funcs)
179
- - `codeGen.js`: code (wasm) generation, ast -> wasm. The bulk of the effort
235
+ - `codegen.js`: code (wasm) generation, ast -> wasm. The bulk of the effort
180
236
  - `decompile.js`: basic wasm decompiler for debug info
181
237
  - `embedding.js`: utils for embedding consts
182
238
  - `encoding.js`: utils for encoding things as bytes as wasm expects
@@ -184,7 +240,7 @@ Porffor can run Test262 via some hacks/transforms which remove unsupported featu
184
240
  - `index.js`: doing all the compiler steps, takes code in, wasm out
185
241
  - `opt.js`: self-made wasm bytecode optimizer
186
242
  - `parse.js`: parser simply wrapping acorn
187
- - `sections.js`: assembles wasm ops and metadata into a wasm module/file
243
+ - `assemble.js`: assembles wasm ops and metadata into a wasm module/file
188
244
  - `wasmSpec.js`: "enums"/info from wasm spec
189
245
  - `wrap.js`: wrapper for compiler which instantiates and produces nice exports
190
246
 
@@ -201,47 +257,67 @@ Porffor can run Test262 via some hacks/transforms which remove unsupported featu
201
257
  - `test262`: test262 runner and utils
202
258
 
203
259
  ## Usecases
204
- Basically none (other than giving people headaches). Potential ideas to come?
260
+ Basically none right now (other than giving people headaches). Potential ideas:
261
+ - Safety. As Porffor is written in JS, a memory-safe language\*, and compiles JS to Wasm, a fully sandboxed environment\*, it is quite safe. (\* These rely on the underlying implementations being secure. You could also run Wasm, or even Porffor itself, with an interpreter instead of a JIT for bonus security points too.)
262
+ - Compiling JS to native binaries. This is still very early!
263
+ - More in future probably?
205
264
 
206
- ## Usage
207
- Basically nothing will work :). See files in `test` for examples.
265
+ ## Todo
266
+ No particular order and no guarentees, just what could happen soon™
208
267
 
209
- 1. Clone repo
210
- 2. `npm install`
211
- 3. `node test` to run tests (some will fail)
212
- 4. `node runner path/to/code.js` to run a file (or `node runner` to use wip repl)
268
+ - Arrays
269
+ - More of `Array` prototype
270
+ - Arrays/strings inside arrays
271
+ - Destructuring
272
+ - Objects
273
+ - Basic object expressions (eg `{}`, `{ a: 0 }`)
274
+ - Asur
275
+ - Support memory
276
+ - Support exceptions
277
+ - More math operators (`**`, etc)
278
+ - Typed export inputs (array)
279
+ - Exceptions
280
+ - Rewrite to use actual strings (optional?)
281
+ - `try { } finally { }`
282
+ - Rethrowing inside catch
283
+ - Optimizations
284
+ - Rewrite local indexes per func for smallest local header and remove unused idxs
285
+ - Smarter inline selection (snapshots?)
286
+ - Remove const ifs (`if (true)`, etc)
287
+ - Memory alignment
288
+ - Add general pref for always using "fast" (non-short circuiting) or/and
289
+ - Runtime
290
+ - WASI target
291
+ - Run precompiled Wasm file if given
292
+ - Docs
293
+ - Update codebase readme section
294
+ - Cool proposals
295
+ - [Optional Chaining Assignment](https://github.com/tc39/proposal-optional-chaining-assignment)
296
+ - [Modulus and Additional Integer Math](https://github.com/tc39/proposal-integer-and-modulus-math)
297
+ - [Array Equality](https://github.com/tc39/proposal-array-equality)
298
+ - [Declarations in Conditionals](https://github.com/tc39/proposal-Declarations-in-Conditionals)
299
+ - [Seeded Pseudo-Random Numbers](https://github.com/tc39/proposal-seeded-random)
300
+ - [`do` expressions](https://github.com/tc39/proposal-do-expressions)
301
+ - [String Trim Characters](https://github.com/Kingwl/proposal-string-trim-characters)
302
+ - Posts
303
+ - Inlining investigation
304
+ - JS -> Native
305
+ - Precompiled TS built-ins
306
+ - Asur
307
+ - `escape()` optimization
308
+ - Self hosted testing?
213
309
 
214
- You can also use Deno (`deno run -A ...` instead of `node ...`), or Bun (`bun ...` instead of `node ...`).
310
+ ## VSCode extension
311
+ There is a vscode extension in `vscode-ext` which tweaks JS syntax highlighting to be nicer with porffor features (eg highlighting wasm inside of inline asm).
215
312
 
216
- ### Options
217
- - `-target=wasm|c|native` (default: `wasm`) to set target output (native compiles c output to binary, see args below)
218
- - `-target=c|native` only:
219
- - `-o=out.c|out.exe|out` to set file to output c or binary
220
- - `-target=native` only:
221
- - `-compiler=clang` to set compiler binary (path/name) to use to compile
222
- - `-cO=O3` to set compiler opt argument
223
- - `-parser=acorn|@babel/parser|meriyah|hermes-parser` (default: `acorn`) to set which parser to use
224
- - `-parse-types` to enable parsing type annotations/typescript. if `-parser` is unset, changes default to `@babel/parser`. does not type check
225
- - `-opt-types` to perform optimizations using type annotations as compiler hints. does not type check
226
- - `-valtype=i32|i64|f64` (default: `f64`) to set valtype
227
- - `-O0` to disable opt
228
- - `-O1` (default) to enable basic opt (simplify insts, treeshake wasm imports)
229
- - `-O2` to enable advanced opt (inlining). unstable
230
- - `-O3` to enable advanceder opt (precompute const math). unstable
231
- - `-no-run` to not run wasm output, just compile
232
- - `-opt-log` to log some opts
233
- - `-code-log` to log some codegen (you probably want `-funcs`)
234
- - `-regex-log` to log some regex
235
- - `-funcs` to log funcs
236
- - `-ast-log` to log AST
237
- - `-opt-funcs` to log funcs after opt
238
- - `-sections` to log sections as hex
239
- - `-opt-no-inline` to not inline any funcs
240
- - `-tail-call` to enable tail calls (experimental + not widely implemented)
241
- - `-compile-hints` to enable V8 compilation hints (experimental + doesn't seem to do much?)
313
+ ## Wasm proposals used
314
+ Porffor intentionally does not use Wasm proposals which are not commonly implemented yet (eg GC) so it can be used in as many places as possible.
242
315
 
243
- ## VSCode extension
244
- There is a vscode extension in `porffor-for-vscode` which tweaks JS syntax highlighting to be nicer with porffor features (eg highlighting wasm inside of inline asm).
316
+ - Multi-value **(required)**
317
+ - Non-trapping float-to-int conversions **(required)**
318
+ - Bulk memory operations (required, but uncommonly used)
319
+ - Exception handling (optional, for errors)
320
+ - Tail calls (opt-in, off by default)
245
321
 
246
322
  ## Isn't this the same as AssemblyScript/other Wasm langs?
247
323
  No. they are not alike at all internally and have very different goals/ideals:
package/asur/README.md ADDED
@@ -0,0 +1,2 @@
1
+ # asur
2
+ a basic experimental wip wasm engine/interpreter in js. wasm engine for porffor. not serious/intended for (real) use