Refactor SLJIT's documentation #292
Conversation
|
|
||
| ## 🚀 Quickstart | ||
|
|
||
| Copy the `sljit_src` directory into your project's source directory and include [`sljitLir.h`](./sljit_src/sljitLir.h): |
There was a problem hiding this comment.
I would not add code examples to readme. A comment could be added to a file which contains a basic example.
|
|
||
| --- | ||
|
|
||
| ## 👉 Purpose |
There was a problem hiding this comment.
I usually don't prefer the colorful characters. Please remove them.
There was a problem hiding this comment.
Yes, I forgot to ask about them. I was already pretty sure that the clean look without emojis would be preferred :-D
| The CPU has: | ||
| - integer registers, which can store either an `int32_t` (4 byte) or `intptr_t` (4 or 8 byte) value | ||
| - floating point registers, which can store either a single (4 byte) or double (8 byte) precision value | ||
| - boolean status flags |
There was a problem hiding this comment.
Some cpus have vector registers as well. On others vector registers also contain the floating point values.
| @@ -0,0 +1,8 @@ | |||
| { | |||
There was a problem hiding this comment.
Is this file used by some generator?
There was a problem hiding this comment.
Yes, it is used by Docusaurus to add some metadata to a category / subfolder in the documentation, see here.
| | `MIPS` | ✅[^3] | ✅[^3] | | ||
|
|
||
| [^1]: only on certain platforms | ||
| [^2]: ARM-v5, ARM-v7 and Thumb2 instruction sets |
There was a problem hiding this comment.
ARM-v6 now is the minimum. ARM-v5 is 25 years old, and probably not used by high performance use cases anymore.
|
|
||
| # Bytecode Interpreters | ||
|
|
||
| SLJIT's approach is very effective for bytecode interpreters, since their machine-independent bytecode (middle-level representation) typically contains instructions which either can be easly translated to machine code, or which are not worth to translate to machine code in the first place. |
There was a problem hiding this comment.
When I wrote that part, I just added some words, but never be happy about it. If you have a better idea about explaining this, it could be better. Or perhaps we could delete the whole thing.
|
|
||
| SLJIT tries to strike a good balance between performance and maintainability. | ||
| The LIR code can be compiled to many CPU architectures, and the performance of the generated code is very close to code written in native assembly languages. | ||
| Although SLJIT does not support higher level features such as automatic register allocation, it can be a code generation backend for other JIT compiler libraries. |
There was a problem hiding this comment.
We could mention that there are simple register allocation algorithms, such as linear scan, which is not difficult to implement.
For me it would be easier to let this fly under a single PR, though if multiple PRs are easier for you to review that would be fine as well. Alternatively, I could rework the commit history of the branch to consist of fewer but more concise commits.
According to the official npm documentation, it is best practice to commit |
|
I think the doc -> docs renaming could go as one PR, should be easy to review. Another for the documentation updates, and another for the generator. Usually it is easier to discuss things in separate PRs. |
Yes you are absolutely right. For some reason I assumed you wanted very fine granular PRs... I will split up the PR in the next couple of days. |
This is the first part of the changes discussed in #285. This PR pretty much only covers refactoring the existing stuff for now.
An overview of the changes:
docfolder todocs, which I though was more canonical. Can be easily changed back todocthough if you want to keep it.README,doc/overview.txtand the website and compiled it into markdown files indocs.docs/website. The generator will use the markdown files indocs. You can preview the website by following the instructions indocs/website/README.md.Still to do:
Open questions: