Tachyon-list

tachyon-list@iro.umontreal.ca

258 discussions

Execution model and register usage on x86 and x86-64
by Erick Lavoie 07 Sep '10

07 Sep '10

I am trying to first clarify what elements are necessary for program execution and which of those might be worth putting in registers. I call register usage configuration which of those elements are put in a register and which are located in memory. I am trying to anticipate the different configurations we might want to try to see what is worth being made configurable. Feel free to add anything you think should be included and any ideas of optimizations that might have an impact on register usage. __Definitions__ X86_REG means any of EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP X64_REG means any of RAX, RBX, RCX, RDX, RSI, RDI, RBP, RSP, R8-R15 REG means any one of X86_REG or X64_REG (depending on the platform) excluding those previously used for a special purpose MEM means an emplacement in memory either accessible from the context or the stack. GLO means an emplacement in memory determined at linking time (like a global variable) which can be seen as static from the runtime code. Here are the elements we might want to put in a register or not. Possible configurations are given between brackets separated by commas. __Runtime elements and possible configurations__ Stack Pointer (xSP, xBP): Mark suggested using xBP to possibly use xSP for object allocation and I am also including xSP in case we might want to keep it in the standard location ( Would it simplify a future Foreign Function Interface?). Heap Pointer (xSP, GLO): Pointer to the remaining free space on the heap when using a compacting GC, like stop&copy or to the beginning of the free list when using a non-compacting GC like mark&sweep. If not in a register, I would suggest having it as a global variable since it is common to all Runtime Contexts. Runtime Context (REG, GLO): Contains all the information specific to a given instance of tachyon. An instance might be a browser tab/window or the compiler itself. The runtime context is an object in memory containing minimally the global object and the root object (Object.prototype). The runtime context object might contain handlers references when accessed from a register to preserve a register for other usage. Handlers (REG, GLO): Contains references to general handlers to perform the general but less common case for various operations such as additions, multiplication, etc. or for expensive but less common operations such as exception handling. When accessed from a register, the handlers references might be put at the end of the runtime context object. Argument Nb (REG, MEM): The number of arguments given by the caller of a function. When in a register, can be combined with the Runtime Context to save a register, given that the context object are aligned to a given value, liberating the lower bits of the Runtime Context register. When in memory, it will be saved on the stack as part of the function call protocol. Return Address (REG, MEM): Return address of the currently executing function. Whether in memory or in a register, it will be saved, restored or set as part of the function call protocol. Implicit Function Arguments (2 REG, REG + MEM, MEM): Arguments to a function not explicitly part of the function definition (not given between the brackets), such as the function reference (when arguments.callee is used or when calling a closure) and the this object, which can either be any object or the global object. When passed in registers, each implicit argument use a different register. When passed in memory, they are passed on the stack. In the two cases, this is part of the function call protocol. I separated them from the explicit function arguments because it might happen that most functions in a real world application are not used in an object-oriented style or as closures so it would liberate two registers for other arguments. If the distinction turns out not to be really useful, we might simply consider all of the arguments as explicit function arguments in the same order as given in the current IR. Explicit Function Arguments (k REG + (n-k) MEM): Arguments to a function explicitly part of the function definition (given between the brackets). k are the first k arguments given to a function call from left to right and n is the total number of arguments given to that function call. k is a register usage configuration parameter that applies to the whole program. n is the specific number of arguments at a given call site. The first k arguments are passed in registers and the remaining (n-k) arguments are passed on the stack. The parameter k is part of the function call protocol. That's it! As a complementary discussion, so far I have assumed that every register was caller-save. Do you guys think that it might be worth reserving some registers to be callee-save? In that case, when those should be spilled, at the entry of a function or at the site of usage? Erick

3 5

SPLASH 2010: early registration ending on september 16th
by Erick Lavoie 07 Sep '10

07 Sep '10

We have 10 days left for early registration. Since I don't want to miss a week of classes, I won't go this year, so I guess it will be the two of you, Marc and Maxime! Erick

3 3

Required Parser Fixes
by chevalma＠iro.umontreal.ca 03 Sep '10

03 Sep '10

Marc, do you have any time to fix the parser issues we discussed before leaving? There are a few things I'd like to fix in the IR conversion that I'd can't really do until those fixes are applied. Things to fix: - Identifier/variable objects not the same (not ===) for function parameters vs locals that are parameters - Scope of var declarations inside catch not matching JS semantics - Function declarations inside catch resolve their variable to the outer containing function, not the catch scope (but function expressions behave as you would expect) - arguments variable should not appear free, should be a local Feature requests: - function/program prologue annotations extraction, functions should have a field that is a list of all prologue annotation strings - when eval appears free in a function or a sub-function, make all variables "escaping" all the way to the function containing the eval, to signal that they could all be captured by a closure corresponding to eval code - Maxime

3 2

Global object property search optimization: first results
by Erick Lavoie 31 Aoû '10

31 Aoû '10

Experiments after having changed the lookup algorithm on the global object to test for the 3 first properties before doing a linear search show a .5 second speedup on a 2.13 GHz Intel Core 2 Duo Macbook for fib(40). Fast lookup: user 0m3.702s Original Linear search: user 0m4.339s Those tests can be repeated by running: time make test in the two following branches, available on the tachyon repository: globalOriginalLinearSearch globalFastSearch The source code for the search algorithm can be found in 'codegen/ir-to-asm-x86.js' at line: 338: irToAsm.translator.prototype.get_prop_addr = function (opnds, dest) Erick

5 9

Disponibilités Automne 2010
by Erick Lavoie 31 Aoû '10

31 Aoû '10

Mes disponibilités pour l'automne 2010 sont: Lundi: 12h00 - ... Mardi: 9h00 - ... Mercredi: 12h00 - 14h15 Jeudi: 10h30 - 15h15 Vendredi 9h00 - ... Erick

4 7

Fibonacci working
by Erick Lavoie 27 Aoû '10

27 Aoû '10

I've added a test to the test suite executing fib(20) automatically. As long as your d8 shell is patched with the changes from Marc, you should be able to enjoy repeatedly compiling fibonacci by simply doing 'make test'. Erick

1 0

Abstract for Compiler-Driven Performance Workshop
by Maxime Chevalier-Boisvert 27 Aoû '10

27 Aoû '10

We would like to submit a talk proposal for the Compiler-Driven Performance Workshop. Talk title: Tachyon: a Meta-circular Optimizing JavaScript Virtual Machine Author list: Maxime Chevalier-Boisvert Erick Lavoie Marc Feeley Bruno Dufour Speaker: Maxime Chevalier-Boisvert Abstract: JavaScript is now the most widely supported dynamic programming language in existence; it is the language that powers the client-side of the web, and large companies such as Google and Microsoft have clearly stated their intent to build web applications intended to replace current desktop software based on this technology. Finding ways to get better performance out of JavaScript code and to provide more portable implementations of the language have become foremost concerns. The Tachyon project is a research initiative involving the creation of a meta-circular JavaScript virtual machine. This virtual machine is meta-circular because it is itself written in JavaScript and intended to compile and optimize itself just-in-time, along with client code, to platform-specific machine code. This project was officially started this year, and while still in early stages, has the potential to offer researchers a simpler and powerful alternative to explore novel dynamic language optimization techniques and study the behavior or dynamic languages. We intend to use this project to demonstrate the potential performance and design benefits of meta-circularity, to explore novel optimization techniques based on dynamic analysis, dynamic recompilation and on-stack replacement and to experiment with the idea of a virtual machine capable of serializing its own state. We plan to integrate Tachyon in a real web browser so as to test and demonstrate its capabilities in real-world situations, on non-synthetic JavaScript code. We further intend to make our system open source and available to other researchers. - Maxime Chevalier-Boisvert

2 2

Re: [Tachyon-list] Symétrie entre l'ordre de récupération des arguments et l'ordre de passage des arguments à 'call' ?
by Maxime Chevalier-Boisvert 26 Aoû '10

26 Aoû '10

Good suggestions. I will make the changes this afternoon. - Maxime On 10-08-23 10:34 AM, Erick Lavoie wrote: > En y repensant, > > je suggèrerais que l'argument objet soit construit par la fonction > appelée pour éviter le coût de sa construction dans les cas où il > n'est pas utilisé. Puisque l'objet argument serait donc construit et > non passé en argument, je suggèrerais une instruction spécifique pour > sa construction plutôt que de le récupérer comme un argument > explicite, donc quelque chose comme: > > t1 = make_arg_obj > > et que cette instruction apparaisse toujours après les instructions de > récupération des arguments. > > Erick > > Le 10-08-23 10:02 , Erick Lavoie a écrit : >> Salut, >> >> je viens de remarquer que l'ordre de récupération des arguments au >> début d'une fonction n'est pas le même que celui de passage de ces >> arguments à l'instruction call. Je suggèrerais de les rendre >> symétriques. En suivant l'ordre de call, ça donnerait: >> >> funcObj = arg 0 >> this = arg 1 >> x1 = arg 2 >> ... >> xn = arg n+1 >> argObj = arg n+2 >> >> Si n arguments sont passés à call de la façon suivante: >> >> call [func], [global or obj], x1, ..., xn >> >> >> >> Erick >>

3 2

Fwd: reminder: 9th Compiler-Driven Performance Workshop - CASCON 2010
by Marc Feeley 19 Aoû '10

19 Aoû '10

Begin forwarded message: > From: Clark Verbrugge <clump(a)cs.mcgill.ca> > Date: August 19, 2010 11:48:11 AM EDT > To: undisclosed-recipients:; > Subject: reminder: 9th Compiler-Driven Performance Workshop - CASCON 2010 > > Hi, > > Just a reminder that I need to receive your abstracts by next week Wednesday, August 25. (If you have already sent it, thank you.) > > ttfn, > clark verbrugge > associate professor > school of computer science > mcgill university > clump(a)cs.mcgill.ca > > > clark verbrugge wrote: >> 9th Compiler-Driven Performance Workshop >> November 4, 2010 (Thursday) >> Hilton Suites Toronto/Markham Conference Centre >> Associated with CASCON 2010 >> (http://www.cas.ibm.com/cascon) >> (Nov 1-4 2010) >> Dear Colleague: >> We would like to invite you to participate in the 9th Compiler-Driven >> Performance Workshop (CDP10) which will be held during the IBM Center for >> Advanced Studies Conference (CASCON) 2010 in Markham, Ontario, Canada. >> In the past seven years we had very successful one-day events in which faculty >> members, students and practitioners presented their recent work and research >> plans. >> Topics to be discussed in the workshop include, but are not limited to: >> * innovative analysis, transformation, and optimization techniques >> * languages, compilers, and optimization techniques for multicore processors >> and other parallel architectures >> * compiling for streaming or heterogeneous hardware >> * dynamic compilation for high-performance and real-time environments >> * compilation and optimization for scripting languages >> * compilation techniques for reducing power >> * tools and infrastructure for compiler research >> SUBMISSION: >> NO LATER THAN WEDNESDAY AUGUST 25, we would like to hear from you if you >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> would like to give a talk about your research or to volunteer a student to do >> so. Please send, by email to clump(a)cs.mcgill.ca, your talk title, the >> author list, the name of the speaker, and a brief abstract. >> Please note that the number of presentation slots is quite limited. Once we >> have a list of title/speakers, we will let you know if your presentation has >> been selected. >> CDP does not publish proceedings. Presenters are required to provide an >> electronic copy of their slides. The slides will be available on a website soon >> after the workshop. >> CASCON has a very well organized exhibit section that is an excellent forum to >> display students' current work and allow for discussions. We would like to >> suggest that you encourage some of your students to participate in the exhibit >> section. >> We also would like to encourage all participants to gather during the lunch and >> coffee breaks for more informal interactions. The workshop does not have funds >> to defray the travel/lodging costs for participants/speakers. However >> registration for CASCON is free, and lunch is provided to all attendees. >> We look forward to your participation in CDP10! >> Steering Committee: >> Kit Barton - IBM Toronto Lab >> David Grove - IBM Watson >> Ondrej Lhotak - University of Waterloo >> J. Gregory Steffan - University of Toronto >> Mark Stoodley - IBM Toronto Lab >> Clark Verbrugge - McGill University

1 0

Required Parser Fixes
by chevalma＠iro.umontreal.ca 18 Aoû '10

18 Aoû '10

Marc, do you have any time to fix the parser issues we discussed before leaving? There are a few things I'd like to fix in the IR conversion that I'd can't really do until those fixes are applied. Things to fix: - Identifier objects not the same for parameters vs locals that are parameters - Scope of var declarations inside catch - Function declarations inside catch resolve their variable to the outer containing function, not the catch scope (but function expressions behave as you would expect) Feature requests (lesser priority): - conservative eval use detection - conservative arguments object use detection - function prologue annotations extraction, functions should have a field that is a list of all prologue annotation strings - Maxime

1 0

Aller à la page :

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Tachyon-list