Tachyon-list Mars 2011

tachyon-list@iro.umontreal.ca

4 participants
45 discussions

variables not implicitly initialized to undefined
by Marc Feeley 17 Mar '11

17 Mar '11

Maxime can you check if there isn't a problem with declarations of the form: var foo; which should be equivalent to var foo = undefined; The code generated for insertErrorIR is currently wrong, but when I make a small modification to the function, like this: function insertErrorIR(context, errorName, errorMsg) { // Find the error contructor var errorCtor = undefined; //FIXME: was just: var errorCtor; switch (errorName) { case 'RangeError': the function works properly. In other words, the absence of an initializer does not behave like an "undefined" explicit initializer. Marc

1 0

ast-passes.js Pass 4 problem
by Marc Feeley 16 Mar '11

16 Mar '11

After applying a few workarounds to advance in the bootstrap, I discovered that Tachyon is not compiling pass 4 of parser/ast-passes.js correctly. Specifically the part that handles the ForVarStatement had to be rewritten like this, otherwise the variable accum would be equal to undefined instead of null: else if (ast instanceof ForVarStatement) { var accum; // CHANGED, used to be: var accum = null; accum = undefined; // CHANGED for (var i=ast.decls.length-1; i>=0; i--) { var decl = ast.decls[i]; this.add_variable(decl.id, false); if (decl.initializer !== null) { decl.initializer = this.walk_expr(decl.initializer); var init = new OpExpr(decl.loc, op2_table[EQUAL_CAT], [new Ref(decl.id.loc, decl.id), decl.initializer]); if (accum === undefined) // CHANGED accum = init; else accum = new OpExpr(decl.loc, op2_table[COMMA_CAT], [init, (accum===undefined)?null:accum]); // CHANGED } } ast.expr2 = this.walk_expr(ast.expr2); ast.expr3 = this.walk_expr(ast.expr3); ast.statement = this.walk_statement(ast.statement); return new ForStatement(ast.loc, (accum===undefined)?null:accum, // CHANGED ast.expr2, ast.expr3, ast.statement); } Someone with a better understanding of the compiler should debug this. Marc

2 3

SplitError
by Marc Feeley 16 Mar '11

16 Mar '11

I added some more traces, this time in linearscan.js, and got this output when the Tachyon/Tachyon (i.e. the bootstrapped Tachyon) was compiling fib: ... insertCondErrorIR errorName=TypeError insertErrorIR errorName=TypeError errorCtor=box $t_27 = load_box $t_25, $t_26 Generating IR for: "runtime/strings.js" Generating IR for: "runtime/ffi.js" Generating IR for: "runtime/rtinit.js" Performing IR lowering for: "object layout source" Performing IR lowering for: "FFI wrapper source" Performing IR lowering for: "runtime/utility.js" Performing IR lowering for: "runtime/primitives.js" Performing IR lowering for: "runtime/strings.js" Performing IR lowering for: "runtime/ffi.js" Performing IR lowering for: "runtime/rtinit.js" Generating machine code for: "object layout source" unhandledQueue.enqueue(current.split(nextRegPos - 1)); pos=11 this.startPos()=10 unhandledQueue.enqueue(current.split(nextRegPos - 1)); pos=11 this.startPos()=11 *** RUN-TIME ERROR *** SplitError: position '11' happens at the beginning of the interval Earlier in the trace, when Tachyon/V8 was compiling the Tachyon source code, the trace was: ... insertCondErrorIR errorName=TypeError insertErrorIR errorName=TypeError errorCtor=box $t_27 = load_box $t_25, $t_26 Generating IR for: "runtime/strings.js" Generating IR for: "runtime/ffi.js" Generating IR for: "runtime/rtinit.js" Performing IR lowering for: "object layout source" Performing IR lowering for: "FFI wrapper source" Performing IR lowering for: "runtime/utility.js" Performing IR lowering for: "runtime/primitives.js" Performing IR lowering for: "runtime/strings.js" Performing IR lowering for: "runtime/ffi.js" Performing IR lowering for: "runtime/rtinit.js" Generating machine code for: "object layout source" unhandledQueue.enqueue(current.split(freeUntilPos[reg])); pos=16 this.startPos()=4 unhandledQueue.enqueue(current.split(freeUntilPos[reg])); pos=16 this.startPos()=4 unhandledQueue.enqueue(current.split(freeUntilPos[reg])); pos=16 this.startPos()=4 unhandledQueue.enqueue(current.split(freeUntilPos[reg])); pos=16 this.startPos()=4 unhandledQueue.enqueue(current.split(freeUntilPos[reg])); pos=16 this.startPos()=4 ... If I understand correctly, the two traces should be the same (since "object layout source" is the same). Marc

1 0

TypeError problem
by Marc Feeley 16 Mar '11

16 Mar '11

I modified the function insertErrorIR in ast-to-ir.js like this: /** Throw an error object containing an error message */ function insertErrorIR(context, errorName, errorMsg) { // Find the error contructor var errorCtor = undefined; //FIXME: was just: var errorCtor; print("insertErrorIR errorName="+String(errorName)); //FIXME switch (errorName) { case 'RangeError': errorCtor = insertCtxReadIR(context, ['rangeerror']); break; case 'ReferenceError': errorCtor = insertCtxReadIR(context, ['referror']); break; case 'SyntaxError': errorCtor = insertCtxReadIR(context, ['syntaxerror']); break; case 'TypeError': errorCtor = insertCtxReadIR(context, ['typeerror']); break; case 'URIError': errorCtor = insertCtxReadIR(context, ['urierror']); break; } print("errorCtor="+String(errorCtor)); //FIXME assert ( errorCtor !== undefined, 'error constructor not found for: "' + errorName + '"' ); // Create a new context from which to throw the exception var throwCtx = context.pursue(null); // Insert a call to the error constructor var excVal = insertPrimCallIR( throwCtx, 'makeError', [ errorCtor, ConstValue.getConst(errorMsg) ] ); // Throw the error created throwToIR(context, throwCtx, excVal); } and now get a little further in the bootstrap: Generating IR for: "object layout source" Generating IR for: "FFI wrapper source" Generating IR for: "runtime/utility.js" Generating IR for: "runtime/primitives.js" insertCondErrorIR errorName=TypeError insertErrorIR errorName=TypeError errorCtor=box $t_35 = load_box $t_33, $t_34 insertCondErrorIR errorName=TypeError insertErrorIR errorName=TypeError errorCtor=box $t_14 = load_box $t_12, $t_13 insertCondErrorIR errorName=TypeError insertErrorIR errorName=TypeError errorCtor=box $t_27 = load_box $t_25, $t_26 Generating IR for: "runtime/strings.js" Generating IR for: "runtime/ffi.js" Generating IR for: "runtime/rtinit.js" Performing IR lowering for: "object layout source" Performing IR lowering for: "FFI wrapper source" Performing IR lowering for: "runtime/utility.js" Performing IR lowering for: "runtime/primitives.js" Performing IR lowering for: "runtime/strings.js" Performing IR lowering for: "runtime/ffi.js" Performing IR lowering for: "runtime/rtinit.js" Generating machine code for: "object layout source" *** RUN-TIME ERROR *** SplitError: position '11' happens at the beginning of the interval So it seems that my changes have removed the bug "error constructor not found for: "TypeError"" but it is not clear why... I guess the next problem can wait until the first two are fixed... Marc

1 0

Progress
by Marc Feeley 16 Mar '11

16 Mar '11

The problem in pass 4 of ast-passes.js is indeed caused by the interference with the other declaration of "accum". I renamed the second accum to accum2 and I got further in the bootstrap: Parsing Tachyon source: "runtime/rtinit.js" =========pass2 =========pass3 =========pass4 =========pass5 Generating IR for: "object layout source" Generating IR for: "FFI wrapper source" Generating IR for: "runtime/utility.js" Generating IR for: "runtime/primitives.js" *** RUN-TIME ERROR *** error constructor not found for: "TypeError" Now... why is the constructor for TypeError not found! Marc

1 0

-x64 -> -x86_64
by Marc Feeley 16 Mar '11

16 Mar '11

I noticed that the command line option -x64 has been added to Tachyon. That should be -x86_64 if we want to stay with the official naming scheme. Marc

2 1

bt-fib strangeness
by Marc Feeley 15 Mar '11

15 Mar '11

I fixed the multiplication overflow problem in runtime/objects.js which allowed me to complete a "make bootstrap" (which currently tries to compile and execute fib). However I get this error: ... Executing unit for: "backend/x86/config.js" Executing unit for: "backend/x86/ir-to-asm.js" Executing unit for: "bt-fib.js" Tachyon initialization complete bt-fib32.js:1: ReferenceError: btfib is not defined btfib(false); ^ Which is strange because it seems that V8 is trying to call btfib(false). Shouldn't that call be in Tachyon generated code? The makefile appears to be wrong... So I added the call btfib(false); at the end of bt-fib.js and the "make bootstrap" went further: ... Executing unit for: "backend/x86/config.js" Executing unit for: "backend/x86/ir-to-asm.js" Executing unit for: "bt-fib.js" Heap size : 4657 KB Num strings: 3719 Num globals: 1185 Running after initialization of boostrap code Initializing Tachyon bootstrap Creating backend context layout Creating fronted context layout Creating object layouts Initialize FFI functions initFFI Get primitives source code *** RUN-TIME ERROR *** global property not defined timeCurrentMillis So the next step would seem to be to make timeCurrentMillis (and friends) available through the FFI. Once that is done we will start to have some profiling information on the Tachyon generated code, which will be very interesting! Erick, Maxime? I'm currently working on the parser (string annotations). Marc

2 1

Allocation breakdown
by Bruno Dufour 15 Mar '11

15 Mar '11

I just finished a first version of the allocation profiling tool, and I have results (attached) for the tachyon bootstrap (current master branch). Types in angular brackets are builtin types, while the others are normal JS object types. There are two known issues with this version, however : 1) Array sizes are not computed properly. This is due to an issue in v8 where some array objects seem to only be partially initialized by the time the profiler intercepts their creation. As a result, trying to access their elements results in a bus error. I haven't found a way to identify these objects at the moment, so I have to avoid getting the element size for all arrays just to be on the safe side. 2) There is a potential overcounting of the object sizes as well. This is due to the fact that object maps can be shared, but I currently count the object's map size as part of its total size. The decision is based on the fact that sharing is relatively rare, so it is better to count the map in most cases. If this turns out to be a problem, I can implement some smarter size computation that takes sharing into consideration. Bruno

1 0

Parser Fix Required
by chevalma＠iro.umontreal.ca 14 Mar '11

14 Mar '11

Hello Marc, We've run into a problem with the debug traces. Right now, these are generated by modifying every function in the AST to add calls to debug functions. Unfortunately, some of our primitive functions have annotations to disable global calls, and some are called before the hash consing table is created. Could you add support in the parser for annotations in the function prologue? This way, we could simply modify the debug trace code to not annotate the functions that have specific annotations. Furthermore, it would make it possible to eventually only log specific events in the debug trace. What we need is simply a list of the annotation strings found at the beginning of each function. - Maxime

1 0

x86 64 bits support
by Erick Lavoie 12 Mar '11

12 Mar '11

All the tests are now executing correctly in 32 and 64 bits. The makefile target assumes the 64 bit version of d8 is named d8_64. I also tested only the parser, bootstrapped in 32 and 64 bits, respectively with 'make bt-parser' and 'make bt-parser64'. There is a multiplication overflow when executing the 32 bit version but the 64 bit version parses and pretty print fibonacci correctly. Tomorrow I'll look at the full boostrap. Erick

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Tachyon-list Mars 2011