3 ms·

Hey all, happy to take questions/feedback/criticism. Funny anecdote: while developing this post, once I got the JIT working I was very excited. I showed a few

Hey all, happy to take questions/feedback/criticism. Funny anecdote: while developing this post, once I got the JIT working I was very excited. I showed a few people in the office. Our CTO walked by and came to take a look. He's worked on numerous VMs in the past. SpiderMonkey's first JIT, TraceMonkey, being his PhD thesis. He took one look and asked "Is it self hosted." I replied, "well...not yet." To which his response was "pffft!" and walked off. I found that pretty funny. Maybe in the next blog post!

vidarh 11y ago
Dr. Gal studied under Prof. Michael Franz as well, who in turn did his PhD studies under Niklaus Wirth. If you haven't yet, you should read Franz' PhD thesis [1]. It was on load time code generation from what's effective a compressed representation of an ast that was designed for re-using generated code-segment by compying and template instantiation. So a JIT, but not generating from bytecode. Consider it somewhat like inserting a serialization/deserialization step right before your code-generation step, sort of, with some added optimizations to cache re-usable fragments. [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1424 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1...
wvenable 11y ago
You could try using C2BF[1] in an attempt to make it self hosting. :) [1] http://esolangs.org/wiki/C2BF http://esolangs.org/wiki/C2BF
- ndesaulniers 11y ago
  Hey! I like the way you think, my friend!
deleted 11y ago
[deleted]
nickpsecurity 11y ago
wvenable's idea is good but a cheat. You referenced Wirth, who simplified assembly (eg P-code). Do something similar: extend BF with a macro language that simplifies it, build macros for BF-like programming constructs, use them to simplify programming the interpreter/compiler, and then host with that. If you want to do real BF, the very act of implementing those macros might help you mentally understand how to... one piece at a time lol... implement the real thing in vanilla BF. Which you can hand-implement in machine code if you want. Choose your level of masochism carefully. :)
- ndesaulniers 11y ago
  The part I'm most curious about would how to make the JIT itself self hosting. If brainfuck's only method of I/O is getchar/putchar, the only way I can think of calling mmap is doing a stack buffer overflow attack based on the misrepresentation of tape. I remember hacking on Rust being a mind bending experience (the Rust compiler has been self hosting for a long time). Thinking in another level of abstraction is hurting my head. I think it would have to be able to output an macho64 executable. Oh man.
  - nickpsecurity 11y ago
    That does sound difficult. Maybe do it bare-metal on a simple, non-MMAP architecture* with basic routines coded in assembler. Both main interpreter and JIT'd code might reference those core functions. I know it's not directly solving the problem but I sneak around the impossible parts wherever possible. * Come to think of it, one of those microcontrollers or Java processors might come in handy here as they supply basic libs or RTOS's with primitive I/O functionality.

vidarh 11y ago

Dr. Gal studied under Prof. Michael Franz as well, who in turn did his PhD studies under Niklaus Wirth. If you haven't yet, you should read Franz' PhD thesis [1]. It was on load time code generation from what's effective a compressed representation of an ast that was designed for re-using generated code-segment by compying and template instantiation. So a JIT, but not generating from bytecode. Consider it somewhat like inserting a serialization/deserialization step right before your code-generation step, sort of, with some added optimizations to cache re-usable fragments. [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1424 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.1...

wvenable 11y ago

You could try using C2BF[1] in an attempt to make it self hosting. :) [1] http://esolangs.org/wiki/C2BF http://esolangs.org/wiki/C2BF

ndesaulniers 11y ago
Hey! I like the way you think, my friend!

deleted 11y ago

[deleted]

nickpsecurity 11y ago

wvenable's idea is good but a cheat. You referenced Wirth, who simplified assembly (eg P-code). Do something similar: extend BF with a macro language that simplifies it, build macros for BF-like programming constructs, use them to simplify programming the interpreter/compiler, and then host with that. If you want to do real BF, the very act of implementing those macros might help you mentally understand how to... one piece at a time lol... implement the real thing in vanilla BF. Which you can hand-implement in machine code if you want. Choose your level of masochism carefully. :)

ndesaulniers 11y ago
The part I'm most curious about would how to make the JIT itself self hosting. If brainfuck's only method of I/O is getchar/putchar, the only way I can think of calling mmap is doing a stack buffer overflow attack based on the misrepresentation of tape. I remember hacking on Rust being a mind bending experience (the Rust compiler has been self hosting for a long time). Thinking in another level of abstraction is hurting my head. I think it would have to be able to output an macho64 executable. Oh man.
- nickpsecurity 11y ago
  That does sound difficult. Maybe do it bare-metal on a simple, non-MMAP architecture* with basic routines coded in assembler. Both main interpreter and JIT'd code might reference those core functions. I know it's not directly solving the problem but I sneak around the impossible parts wherever possible. * Come to think of it, one of those microcontrollers or Java processors might come in handy here as they supply basic libs or RTOS's with primitive I/O functionality.