Ok. I'd like to use your Gambit code as a reference, but I also think it would be neat(er) to write the writing of x86 code in JS. I would rather avoid having to call external code to do the x86 code writing. I would ideally have each x86 IR instruction have a JS method that can write its own representation into a heap allocated array of bytes, or something of that sort.
Actually, perhaps we're both thinking of the same thing here. I just want to make sure we don't blindly translate your code. If I want to be able to do on-stack replacement, I will need to have a fairly deep understanding of x86 code. Erick will also want to understand this pretty well in order to really understand how the bootstrapping will work.
- Maxime
When I say "x86 code generator" I actually mean the library that encodes the x86 instructions (for example when you call the function x86_addl(opnd1, opnd2) it generates the bytes that encode an x86 "add long" instruction with those operands). This is a required part and is independent of the IR framework.
I agree that the IR framework is on the critical path. However that's best coded by a single person (with feedback from others of course). The library to encode x86 instructions is also on the critical path (it represents about as much work as a basic IR framework). My guess is that it represents about 3 weeks of work.
Marc
On 2010-06-08, at 8:43 PM, chevalma@iro.umontreal.ca wrote:
Erick and I were saying we'd like to have a basic prototype bootstrapping VM working by the end of the summer. We'd like to discuss the technical choices involved when we return from here.
I would personally like to get the IR framework in place before working on code gen. I see the x86 code generation as being the last phase of the IR translation process. I was thinking we could do a basic job at x86 code gen for now. Translating from the AST to SSA HIR, and then to a lower level IR will make the code gen quite a bit easier, and we can integrate it into the IR framework.
I actually spoke to someone who worked on the Sun JVM, and is now working on the Azul JVM. He told me that this is basically how those systems implemented this. Their VM converts to SSA early on, optimizes, eventually translates the instructions down to x86 code, and runs register coloring on the SSA temps to do both register and stack slot allocation at once at the end, before doing basic block straightening and emitting the actual code stream.
- Maxime
We need to start implementing the x86 code generator and in-memory assembler. Once we have that we can start experimenting with dynamic code generation and start work on the Tachyon back-end. We can use the code I wrote for the Gambit x86 back-end as a starting point. It supports code generation for 32 and 64 bit architectures and most of the instructions and addressing modes we need are implemented. So this work will be in large part a translation effort from Scheme to JS. The in-memory assembler is about 800 lines of Scheme. The x86 code generator is about 1400 lines of Scheme.
Who is interested in working on this?
Marc
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list