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
Afficher les réponses par date
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
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
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
On 2010-06-08, at 9:30 PM, chevalma@iro.umontreal.ca wrote:
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.
Yes that's what I have in mind. Something like:
var code = new CodeBlock();
code.x86_movl(x86_mem(esp,4), eax); code.x86_addl(eax, eax); code.x86_ret();
code.assemble();
print(code.execute(11)); // prints 22
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.
Sure, you can both study/translate the Scheme code to JS. I can give a short presentation on the general format of x86 code. The code is general purpose (i.e. no dependencies with other stuff and easy to adapt to any back-end).
Marc
Sure, you can both study/translate the Scheme code to JS. I can give a short presentation on the general format of x86 code. The code is general purpose (i.e. no dependencies with other stuff and easy to adapt to any back-end).
We'd both like to see that. Perhaps you could present it during the group meeting on Friday, if you have time to prepare something by then. Otherwise, maybe next week.
But please tell me what you think about my proposal regarding namespaces ;)
- Maxime
On 2010-06-08, at 11:36 PM, chevalma@iro.umontreal.ca wrote:
Sure, you can both study/translate the Scheme code to JS. I can give a short presentation on the general format of x86 code. The code is general purpose (i.e. no dependencies with other stuff and easy to adapt to any back-end).
We'd both like to see that. Perhaps you could present it during the group meeting on Friday, if you have time to prepare something by then. Otherwise, maybe next week.
Next week is better for me.
But please tell me what you think about my proposal regarding namespaces ;)
As I said the abc_xyz style has advantages over the abc.xyz style, and we can migrate from one to the other as the need arises. A quick test with v8 using this code:
var mem = { f: function (x) { return (x<2) ? 1 : mem.f(x-1)+mem.f(x-2); } };
function f(x) { return (x<2) ? 1 : f(x-1)+f(x-2); }
print(mem.f(40));
shows that the abc_xyz style is about twice as fast as the abc.xyz style. And v8 is not exactly a naive compiler...
Marc
var mem = { f: function (x) { return (x<2) ? 1 : mem.f(x-1)+mem.f(x-2); } };
This is not what I proposed in my last e-mail. I also showed that inlining of mem.foo() can be 100% guaranteed for our compiler using mechanisms provided by ECMAScript 5. I further gave arguments relating to documentation with JsDoc and advantages of namespace separation.
Please comment on what I proposed in the e-mail titled "Namespaces?".
- Maxime
-
chevalma＠iro.umontreal.ca -
Marc Feeley