111–120 of 219 posts
Also, this[1] blog series is a must-read for interested beginners.
0 - https://github.com/stoklund/cretonne/ 1 - https://eli.thegreenplace.net/2017/adventures-in-jit-compila...
$ git clone https://github.com/v8/v8.git $ cd v8 $ find . -name '*.S'
There's still some macro assembler in the built-in's but it's emitted rather than being assembler.
36000 lines of handwritten assembler in v8? Not since the transition to ignition and turbofan... $ git clone https://github.com/v8/v8.git $ cd v8 $ find . -name '*.S' There's still some macro assembler in the built-in's but it's emitted rather than being assembler.
The MacroAssembler, is basically what is used to produce assembly code in both JavaScript engines.
On a similar note, I have been watching this[0] project which provides an IR to target and optional optimizations. But I like the idea that the only difference between a JIT and an AOT compiler is optimization choice (assuming we don't include tracing as part of the JIT features). Also, this[1] blog series is a must-read for interested beginners. 0 - https://github.com/stoklund/cretonne/ 1 - https://eli.thegreenplace…
For the moment it uses dynasm, just to get the prototype working, but I expect to change that in the upcoming months.
(I am the author of HolyJit)
Earlier quoted context omitted.
Government site. There doesn't have to be a reason.
I hope they are paying you very well.
Added: if you think I'm joking or being unfair, just look at the compensation tables for just about any government outfit. They top out around a salary that is considered average for software folks in some places.
Almost reminds me of early on in Servo's history: https://news.ycombinator.com/item?id=6268521
(Although I may just be projecting what I want to hear :) it's exciting hearing about new Rust projects, especially new stuff going into Firefox.)
Earlier quoted context omitted.
I believe the fundamental difference is that instead of hand-writing snippets of assembly which their JIT can append, they are having the Rust compiler generate the assembly snippets from Rust code. This lets them be much more confident that they wrote the snippets correctly, and lets them spend much less time writing the snippets so they can focus on optimizations.
... and the snippets are used for the interpreter, which gives you more confidence that interpreted and JITed code behave the same (if I understood it correctly).
For what it's worth, the name is obviously a pun and a small wink to the Graal VM [1]. Not sure there's any intention to reference TempleOS's HolyC. [1] https://github.com/graalvm/
It could also be a play on the phrase "Holy shit!"
No offense, but the blog post is seriously missing a better (or any?) explanation of what's the new JIT all about. At first I even thought my browser loaded only half the page...
I'm truly sorry that GitHub is blocked where you work. Here's the pitch, taken from the repo's README [1]: 1) holyjit aims to be easy: > As a user, this implies that to inline a function in JIT compiled code, one just need to annotate it with the jit! macro. jit!{ fn eval(script: &Script, args: &[Value]) -> Result = eval_impl in script.as_ref() } fn eval_impl(script: &Script, args: &[Value]) -> Result { // ... // ...…
It's funny that the current tiny non-informative blog post starts with a "tl;dr". Maybe it should be "ts; du" instead!