I just thought, it would probably make more sense to define Infinity to be the largest magnitude 30 bit integer we can support in both the positive and negative range, so comparisons against infinity still make sense, and so does -Infinity.

- Maxime

On 10-12-16 10:00 PM, Maxime Chevalier-Boisvert wrote:

...

...

There are 38 uses of Infinity in the code and 1 use of NaN... these

must be removed!

In my code at least, I used infinity to say that there is no specified upper bound on something. One thing we can do, for now, is cheat. It seems that at least in V8, Infinity is a global variable. Possibly we could just do something like "const Infinity = {};", just for the bootstrap. We could do the same for NaN.

...

...

It happens so often that it would be abstracted: typeString(name,

"name");

Right now, assert is a function defined in debug.js. The plan is to eventually make it a special name that Tachyon will recognize, so that assertions are weeded out from our code when we aren't debugging. This is perhaps slightly more complicated if we start to have many functions whose purpose is only to perform an internal assertion. As you said, this would be better served by macros. For now, I would suggest keeping all assertions the way they are. I defined some helper functions in utility, such as isPosInt, to test for the common case that a value is a positive integer, so you can do "assert (isPosInt(x), ...);".

If you still think we should add extra functions that call assert, I would suggest using the "tachyon:inline" prologue annotation inside of them, so that when the internal assert gets weeded out, so does the whole call to the function doing the assertion. I would also suggest naming them in the form "assertSomething(...)", so in this case, "assertString(x, name)".

• Maxime

...

Too bad there aren't macros in JS... it would then be simply: typeString(name);

The following code is suspect:

allocator.min = function (a, accessFct) { if (accessFct === undefined) accessFct = function (x) { return x; };

  var minIndex = 0;
  var minValue = 0;
  var i;

  for (i=0; i<   a.length; ++i)
  {
      if (accessFct(a[i])>   minValue)
      {
          minIndex = i;
          minValue = a[i];
      }
  }

  return { index:minIndex, value:minValue };

};

shouldn't it be:

allocator.min = function (a, accessFct) { if (accessFct === undefined) accessFct = function (x) { return x; };

  var minIndex = 0;
  var minValue = 0;
  var i;

  for (i=0; i<   a.length; ++i)
  {
      var x = accessFct(a[i]);
      if (x<   minValue)   // NOTE:<   instead of>
      {
          minIndex = i;
          minValue = x; // NOTE: x
      }
  }

  return { index:minIndex, value:minValue };

};

Let me know if that is not correct. Has this code been tested? Moreover, it would be simpler to return the index (the value can be gotten by the client using the index). Also, is the accessFct argument really useful? It doesn't seem to be used in the code! Let's not bloat the compiler needlessly!

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

On 2010-12-16, at 10:00 PM, Maxime Chevalier-Boisvert wrote:

...

...

There are 38 uses of Infinity in the code and 1 use of NaN... these

must be removed!

In my code at least, I used infinity to say that there is no specified upper bound on something. One thing we can do, for now, is cheat. It seems that at least in V8, Infinity is a global variable. Possibly we could just do something like "const Infinity = {};", just for the bootstrap. We could do the same for NaN.

That won't work if numbers are compared using <, etc (to find a min/max or as a sentinel). Perhaps we can say

const Infinity = 99999999;

for the bootstrap and it will work. On the other hand perhaps the algorithms could be rewritten in a better style. It is rare to see a compiler use floats for internal operations. I fear that if we keep this style of code, integers and floats will get mixed, which will deteriorate the type analysis (i.e. value(foo) in union(Float,Int)), and inefficient code will be generated.

...

...

It happens so often that it would be abstracted: typeString(name,

"name");

Right now, assert is a function defined in debug.js. The plan is to eventually make it a special name that Tachyon will recognize, so that assertions are weeded out from our code when we aren't debugging. This is perhaps slightly more complicated if we start to have many functions whose purpose is only to perform an internal assertion. As you said, this would be better served by macros. For now, I would suggest keeping all assertions the way they are. I defined some helper functions in utility, such as isPosInt, to test for the common case that a value is a positive integer, so you can do "assert (isPosInt(x), ...);".

If you still think we should add extra functions that call assert, I would suggest using the "tachyon:inline" prologue annotation inside of them, so that when the internal assert gets weeded out, so does the whole call to the function doing the assertion. I would also suggest naming them in the form "assertSomething(...)", so in this case, "assertString(x, name)".

assertString(x, name) would be fine.

Marc

...

I replaced Infinity by MAX_FIXNUM as suggested by Marc in

Hmm, I think you only used infinity for interval bounds. Do you think you could define your own MAX_INTERVAL instead, or use false/undefined, or simply your own infinity constant just for register allocation (defined to be 2^20 or something). I don't really like the idea of having a constant that depends on our tagging scheme in utility.

I think we should generally avoid defining a "MAX_FIXNUM", but if we do define one, it should be defined under primitives/objects, along with our other tagging scheme constants.

- Maxime