Tachyon-list

tachyon-list@iro.umontreal.ca

258 discussions

Good News!
by chevalma＠iro.umontreal.ca 19 Fév '11

19 Fév '11

I added support for the >>> operator to the constant propagation and ran a "make bootstrap". The good news is that all the code passed through the front end and all CFG validation tests. It got to the actual code generation stage and then we encountered a bug in the back-end. If we're optimistic, all that's left is fixing bugs in the back-end and we should be able to say the bootstrap is complete. Realistically, there will probably be other bugs in other parts of the system, but those will only show up when we try to run our own code. I will probably spend the rest of the afternoon adding more unit tests to try and make sure we really have our bases covered. Perhaps include some of our own code in a unit test, or try coding a simple parser, to have something more reflective of the code we actually run. I should also add the /hir, /lir, /asm shell commands because they will probably be very useful debugging tools in the next few days. - Maxime

2 4

Bignum & Unsigned Right Shift
by chevalma＠iro.umontreal.ca 17 Fév '11

17 Fév '11

The bignum refactoring for the front-end is pretty much complete and so far all unit tests pass. However, I think there is one feature missing from the bignum code. I would like to be able to do unsigned right shifts in addition to signed shifts. If you have time, Marc, could you add an unsigned flag to the shift function, and perhaps have it assume signed shift by default? If you do, please make sure to pull the latest code from the repo. Tomorrow I'll try the boostrap again and see how far we can get. Hopefully I won't have introduced too many bugs in the code I just modified! (fingers crossed). - Maxime

2 1

Fwd: [fonc] CfP: ICOOOLPS 2011
by Erick Lavoie 17 Fév '11

17 Fév '11

Might be interesting to submit an article there as well ;-) BTW, Andreas Gal is on the program committee. Erick -------- Message original -------- Sujet: [fonc] CfP: ICOOOLPS 2011 Date : Thu, 17 Feb 2011 22:06:14 +0100 De : Michael Haupt <Michael.Haupt(a)hpi.uni-potsdam.de> Répondre à : Fundamentals of New Computing <fonc(a)vpri.org> Pour : Fundamentals of New Computing <fonc(a)vpri.org> * apologies for multiple copies * Call For Papers for the sixth annual workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (ICOOOLPS) to be held at ECOOP 2011 in Lancaster, UK on July 26th 2011 http://www.icooolps.info/ Overview: Computer programming languages, especially Object-Oriented languages, are pervasive and play a significant role in computer science and engineering life and sometime appear as ubiquitous and completely mature. However, despite a large number of works, there still is a clear need for solutions for efficient implementation and compilation of OO languages in various application domains ranging from embedded and real-time systems to desktop systems. The ICOOOLPS workshop thus aims to address this crucial issue of optimization, mainly but not only in OO languages, programs and systems. It intends to do so by bringing together researchers and practitioners working in the field of implementation and optimization of programming languages. Its main goals are identifying fundamental bases and key current issues pertaining to the efficient implementation, compilation and optimization of OO languages, and outlining future challenges and research directions. An expected output of this workshop is a synthesis identifying fundamental bases and key current issues pertaining to the efficient implementation and compilation of OO languages, in order to spread them further amongst the various computing systems. It is also intended to extend this synthesis to encompass future challenges and research directions in the field of OO languages implementation and optimization, as well as non-OO languages. Important Dates: Workshop paper submission: April 15, 2011 Workshop paper acceptance: May 20, 2011 Workshop: July 26, 2011 Program Committee: Mark van den Brand TU Eindhoven, The Netherlands Peter Dickman Google, Switzerland Roland Ducournau LIRMM, France M. Anton Ertl Technical University of Vienna (TU Wien), Austria Remi Forax University of Marne-la-Vallée, France Björn Franke University of Edinburgh, UK Andreas Gal Mozilla Corporation, USA Kevin Hammond University of St Andrews, UK Tim Harris Microsoft Research, UK Michael Haupt Hasso-Plattner-Institut, Germany Eric Jul (co-chair) DIKU, The University of Copenhagen, Denmark Tomas Kalibera The University of Kent, UK Stein Krogdahl University of Oslo, Norway Francis Chi Moon Lau The University of Hong Kong, Hong Kong Ian Rogers (chair) Azul Systems, USA Jennifer Sartor Ecole Polytechnique Federale de Lausanne, Switzerland Manuel Serrano INRIA, France Mario Wolczko Oracle Labs, USA Olivier Zendra (co-chair) INRIA/LORIA, France -- Dr.-Ing. Michael Haupt michael.haupt(a)hpi.uni-potsdam.de Software Architecture Group Phone: ++49 (0) 331-5509-542 Hasso Plattner Institute for Fax: ++49 (0) 331-5509-229 Software Systems Engineering http://www.hpi.uni-potsdam.de/swa/ Prof.-Dr.-Helmert-Str. 2-3, D-14482 Potsdam, Germany Hasso-Plattner-Institut für Softwaresystemtechnik GmbH, Potsdam Amtsgericht Potsdam, HRB 12184 Geschäftsführung: Prof. Dr. Christoph Meinel

1 0

Globals Working Properly
by chevalma＠iro.umontreal.ca 17 Fév '11

17 Fév '11

I just fixed the issue with global var statements and added support for program unit tests with multiple source files, as well as a multi_file unit test to make sure that this is all working properly. Now onto refactoring for bignum support... Après mon break syndical. - Maxime

1 0

Apply working
by Erick Lavoie 17 Fév '11

17 Fév '11

I am pleased to announce that apply and call work since around 5pm this afternoon. The tests written for strings and arrays using it worked the first time we tried them ;-) Erick

3 2

Array.splice strangeness
by chevalma＠iro.umontreal.ca 15 Fév '11

15 Fév '11

Erick finished support for the arguments object and I was able to get most of the array code working inside Tachyon. There are some basic unit tests in 'programs/stdlib_arrays/stdlib_arrays.js'. Not everything is yet tested as it will require support for apply. I did encounter one strange thing. The behavior of Array.splice(0) on our system does the intuitive thing (removes nothing from the array). However, on V8, it removes everything from the array instead. Another place where we differ is that V8's default array sort function seems to do a lexicographical sort. However, the standard seems to say this is implementation dependent, perhaps because this decision was made with the help of a Ouija board. Marc, if you have time, could you look into which behavior is correct and adjust our array code if necessary? If you need to make changes, please make sure to use the latest version on the repository as I made some changes to the code already. - Maxime

3 7

Infinite precision integers
by Marc Feeley 14 Fév '11

14 Fév '11

I have added utility/num.js and utility/tests/num.js which implement infinite precision integers. The "num" abstract type is represented as the union of the JavaScript integer representation and the bignum representation. I also modified the scanner to use the "num" type when computing the integer value. Here's the code for reference: var lhs_value = function (accepted_char, base, char_value) { var n = 0; for (;;) { var c = that.lookahead_char(0); if (!accepted_char(c)) break; that.advance(1); n = num_add(num_mul(n, base), char_value(c)); } return n; }; The arithmetic functions on the "num" type are all prefixed with num_ (in particular: num_add, num_sub, num_mul, num_div, num_mod, num_lt, num_eq, num_gt, num_neg, num_not, num_and, num_or, num_xor, num_shift, num_to_string). The compiler's code, in particular the constant folding and the back-end, will have to use these functions when manipulating integers that may exceed the 30 bit fixnum range. Please make the appropriate modifications. For example, instead of doing a test like x > 2147483647 (the literal is 2^31-1), do this instead: num_gt(x, num_sub(num_shift(1, 31), 1)). Of course it would be best to compute num_sub(num_shift(1, 31), 1) once. I have reactivated the warning for 30 bit integers in the parser to help identify the problem spots. Marc

2 5

ICFP11 paper in repo
by Marc Feeley 14 Fév '11

14 Fév '11

Hi. I've added a skeleton ICFP11 paper under papers/ICFP11 . To build it type "make" in that directory. Here's an important comment from the main .tex file: % If you add a section, create a new file whose name is the abreviated % name of the section and ending in .tex, and put a \input{...} where % the section should appear in the paper. This will make it easy to % move things around if needed. Also, add a dependency on that file % in the makefile. Marc

1 0

Mozilla trip
by Marc Feeley 04 Fév '11

04 Fév '11

I've thought about this some more and now I think we should only go to Mozilla after we have submitted the paper to ICFP. There's really no rush from our side to see the Mozilla people, and if we go after the submission we will have some well organized thoughts, which should help in our meeting with Mozilla. Obviously it will also give us some more time to prepare our paper. So I'm proposing we go the 28 and 29 of March. Is that OK with everyone? Marc

4 8

strings.js included in build?
by Bruno Dufour 04 Fév '11

04 Fév '11

Hi, Does strings.js need to be included by default in 'make test'? My current stdlib implementation is done (the test-on-top-of-v8 part, not the tachyon-with-iir part), but committing it would break the master branch. I get a bus error after tachyon attempts to compile it: Parsing Tachyon source: "stdlib/strings.js" Generating IR for: "stdlib/strings.js" Performing IR lowering for: "stdlib/strings.js" Generating machine code for: "stdlib/strings.js" Linking machine code for: "stdlib/strings.js" Initializing standard library make: *** [test] Bus error Any suggestions? Bruno

2 11

Aller à la page :

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Tachyon-list