A hand-coded version of Fibonacci is shown in "test-x86-fibonacci.js". To run a test of fib(40) and show the corresponding listing of the assembly code, run:
./fib.sh
in the codegen directory, assuming the extension made by Marc to d8 has been applied.
I've merged all my changes in the master branch and those are available on the repository. I'll test everything thoroughly for the rest of the day, I've found that it is pretty easy to introduce typo bugs in Javascript ;-).
Erick
Afficher les réponses par date
I just saw your commit, bravo! ;)
Some comments:
1) Perhaps some names could be more concise:
a.assembleToMachineCodeBlock
Is this function only meant to generate an executable byte stream from already encoded instructions? What's the difference between it and assemble? Its name should perhaps reflect its purpose more directly.
2) Some things could perhaps be made more OOP:
execMachineCodeBlock(block) ==> block.exec() freeMachineCodeBlock(block) ==> block.free()
3) In the spirit of keeping names short and simple, perhaps a.immediateValue could become a.imm, and a.label(a.codeBlock.label('string')) could simply be a.label('string').
4) I wish you had more JSDoc-style comments to document what your functions do
- Maxime
Erick Lavoie wrote:
A hand-coded version of Fibonacci is shown in "test-x86-fibonacci.js". To run a test of fib(40) and show the corresponding listing of the assembly code, run:
./fib.sh
in the codegen directory, assuming the extension made by Marc to d8 has been applied.
I've merged all my changes in the master branch and those are available on the repository. I'll test everything thoroughly for the rest of the day, I've found that it is pretty easy to introduce typo bugs in Javascript ;-).
Erick _______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
execMachineCodeBlock(block) ==> block.exec() freeMachineCodeBlock(block) ==> block.free()
Totally agree to more meaningful, shorter and OOP names. Those are preliminary "hacks" made by Marc to test the system. The final system and exact syntax are completely open for discussion.
- In the spirit of keeping names short and simple, perhaps
a.immediateValue could become a.imm, and a.label(a.codeBlock.label('string')) could simply be a.label('string').
Agreed. I am waiting to get a little more experience with the system before committing to a syntax.
- I wish you had more JSDoc-style comments to document what your
functions do
I'll test and document the system for the rest of the day ;-)
- Maxime
Erick
On 2010-07-13, at 3:33 PM, Erick Lavoie wrote:
execMachineCodeBlock(block) ==> block.exec() freeMachineCodeBlock(block) ==> block.free()
Totally agree to more meaningful, shorter and OOP names. Those are preliminary "hacks" made by Marc to test the system. The final system and exact syntax are completely open for discussion.
OOP names... what's that?
Those names were chosen because they are foreign functions (written in C) and it is in this style that D8 exports foreign functions to JavaScript. Here "block" is an internal array of bytes (I'm not sure it can have properties).
Of course these foreign functions could be wrapped in objects. But given that these are temporary, I don't think we should spend too many brain cycles on it.
- In the spirit of keeping names short and simple, perhaps
a.immediateValue could become a.imm, and a.label(a.codeBlock.label('string')) could simply be a.label('string').
Agreed. I am waiting to get a little more experience with the system before committing to a syntax.
Sounds good. Except it should be a.label("string"). ;-)
Marc
Marc, I don't really get the comment you added in ast-passes:
// TODO: the computation of clos_vars should be done elsewhere as it is not related to the semantics
Where else would you do this computation? It seems to me that it's logically related to the resolution of variable scopes. It's simply a more restricted free_vars set which doesn't include globals.
- Maxime
I played a bit more with D8, and it's possible that the way variable resolution is now done for the catch statement is still not quite right.
In our system, all variables and functions declared inside the catch part are shown as belonging to the catch part. However, in D8, it seems that only the exception variable belongs to the scope of the catch part, while other declarations found in there are only locals.
Furthermore, when one inserts a function declaration inside a catch part, in D8, this function declaration will not capture the exception variable. It's as if all function declarations inside a function or the global scope are directly at the beginning of the said function or program (their closure is created once). However, function expressions can capture the exception variable, because a new closure is created each time the expression is evaluated.
I suspect that this is conformant to the standard, but we should look to make sure. If this is the correct behavior, Mark, do you want to take another look at variable resolution?
- Maxime
On 2010-07-14, at 22:35, Maxime Chevalier-Boisvert wrote:
I played a bit more with D8, and it's possible that the way variable resolution is now done for the catch statement is still not quite right.
In our system, all variables and functions declared inside the catch part are shown as belonging to the catch part. However, in D8, it seems that only the exception variable belongs to the scope of the catch part, while other declarations found in there are only locals.
Sorry. My intention was to do it like you say. I forgot to change resolve_variable to implement that semantics.
Furthermore, when one inserts a function declaration inside a catch part, in D8, this function declaration will not capture the exception variable. It's as if all function declarations inside a function or the global scope are directly at the beginning of the said function or program (their closure is created once). However, function expressions can capture the exception variable, because a new closure is created each time the expression is evaluated.
OK... some more JS weirdness to contend with.
I suspect that this is conformant to the standard, but we should look to make sure. If this is the correct behavior, Mark, do you want to take another look at variable resolution?
Yes.
Marc
On 2010-07-14, at 8:40 PM, Maxime Chevalier-Boisvert wrote:
Marc, I don't really get the comment you added in ast-passes:
// TODO: the computation of clos_vars should be done elsewhere as it is not related to the semantics
Where else would you do this computation? It seems to me that it's logically related to the resolution of variable scopes. It's simply a more restricted free_vars set which doesn't include globals.
Exactly. The reason you don't include globals is because we will implement the global variables in a special way in the first version of the compiler (we have discussed this before). It is a modularity issue. You are putting in ast-passes.js (an early pass of the compiler) some knowledge of the runtime system (the way globals are accessed). But clearly clos_vars (which you need later on) can be computed from free_vars by removing the global variables. The benefits are: more modular code and less space usage (no duplication of information in free_vars and clos_vars).
Marc
You are putting in ast-passes.js (an early pass of the compiler)
some knowledge of the runtime system (the way globals are accessed).
It makes sense to me that globals shouldn't be captured as closure variables, no matter how we implement them. Seems like something we know will hold true, no matter how we implement the system.
- Maxime
On 2010-07-15, at 8:21 AM, Maxime Chevalier-Boisvert wrote:
You are putting in ast-passes.js (an early pass of the compiler)
some knowledge of the runtime system (the way globals are accessed).
It makes sense to me that globals shouldn't be captured as closure variables, no matter how we implement them. Seems like something we know will hold true, no matter how we implement the system.
In a previous meeting I explained that a JavaScript system may need to support more than one top-level environment. For example, browsers have one top-level environment per window. It is conceivable that a closure created in one top-level environment will be "sent" or shared with code running in a different top-level environment. This might be useful for one browser window to interact with another window. I don't want to argue whether this is a good thing or not. I don't know at this point. However, we should structure the compiler so that this is an option if we want to try it out. Given that this is a runtime system issue (how top-level environments are implemented), the decision to exclude global variables should be made in the middle or back-end of the compiler.
And as I said, even if we ignore the modularity issue, we don't want to waste space in two tables (free_vars and clos_vars) that duplicates the information.
Having the global variables in the free variables is also useful for generating linking information. The free variables of the "Program" node are the global variables that the module imports/exports.
Marc
In a previous meeting I explained that a JavaScript system may need
to support more than one top-level environment.
In previous discussions, I suggested that we will want multiple global objects to separate our environment from executing programs. The way I plan on implementing this is to have a global object constant, which is different depending on what code is being compiled. For the Tachyon code, it will refer to our private global object, with JavaScript extensions included. For the code we compile, there can be separate global objects that will be specified at compile time. A function/source file compiled with a given global object will always refer to that same global object to access its globals.
Given that this is a runtime system issue (how top-level
environments are implemented), the decision to exclude global variables should be made in the middle or back-end of the compiler.
The way I have it conforms to the JS semantics, I find. The top-level environment is the global object. It's semantically an object, and it's where non-local variables are to be found. It makes little sense for individual global variables to be captured by a closure, because they are semantically different from local variables. You can delete global variables and access them using strings as names, for example, which you can't do with local/closure variables.
In terms of modularity, it makes perfect sense to keep all code related to variable resolution together, and as far as wasting space goes, at the moment, I have no need for free_vars. I'd rather still have clos_vars and esc_vars be computed in an AST pass at this time. Otherwise it forces me to include extra AST traversal code in the IR translation (particularly for esc_vars). If this somehow needs to be changed later, it's a pretty minor change to make.
Do you think you will have the updated variable resolution ready soon, and will you keep the computations of esc_vars and clos_vars in there?
- Maxime
Marc, are we having a group meeting on Monday the 26th? If so, I'm only available during the morning.
- Maxime
I can only meet starting at 11:45. When do you have to leave the University?
Marc
On 2010-07-23, at 12:29 PM, chevalma@iro.umontreal.ca wrote:
Marc, are we having a group meeting on Monday the 26th? If so, I'm only available during the morning.
- Maxime
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
I have to leave at 13:15 at the latest.
Erick, would you be available for a meeting at 11:45 Monday?
- Maxime
I can only meet starting at 11:45. When do you have to leave the University?
Marc
On 2010-07-23, at 12:29 PM, chevalma@iro.umontreal.ca wrote:
Marc, are we having a group meeting on Monday the 26th? If so, I'm only available during the morning.
- Maxime
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
Yes
Erick
Le 10-07-25 14:47 , chevalma@iro.umontreal.ca a écrit :
I have to leave at 13:15 at the latest.
Erick, would you be available for a meeting at 11:45 Monday?
- Maxime
I can only meet starting at 11:45. When do you have to leave the University?
Marc
On 2010-07-23, at 12:29 PM, chevalma@iro.umontreal.ca wrote:
Marc, are we having a group meeting on Monday the 26th? If so, I'm only available during the morning.
- Maxime
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-07-25, at 10:57 PM, Bruno Dufour wrote:
On 2010-07-25, at 18:12 , Marc Feeley wrote:
OK, then 11:45 it is!
Bruno, are you back in Montreal yet?
I am currently in DC. I will most reach Montreal tomorrow morning, but most likely too late to make it in time for the meeting.
Well if you do make it, it will be nice to see you!
Marc
-
Bruno Dufour -
chevalma＠iro.umontreal.ca -
Erick Lavoie -
feeley -
Marc Feeley
-
Maxime Chevalier-Boisvert