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
Afficher les réponses par date
Ok. I'll be looking into adding that to the front-end later today or tomorrow.
- Maxime
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),
- once.
I have reactivated the warning for 30 bit integers in the parser to help identify the problem spots.
Marc
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
Marc, if you have time, I think it might be quite useful for the back-end to have a function to convert a bignum/num to an array of byte values.
- Maxime
Ok. I'll be looking into adding that to the front-end later today or tomorrow.
- Maxime
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),
- once.
I have reactivated the warning for 30 bit integers in the parser to help identify the problem spots.
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 2011-02-14, at 2:28 PM, chevalma@iro.umontreal.ca wrote:
Marc, if you have time, I think it might be quite useful for the back-end to have a function to convert a bignum/num to an array of byte values.
Please explain exactly what you want (there are many variations possible). Where in the source can I find a use for this?
Marc
The use would be to write immediate integer values (8, 16, 32, 64 bits in 2s complement) when generating code in the backend. At some point we need to be able to generate the machine-representation of those values.
I'm not sure how exactly it's handled right now. Erick has an address/pointer class with a getBytes() method. Constants have a getImmValue() method which simply returns a JavaScript number at the moment (which doesn't work for 64 bit integer values). This will need to change, and ideally be unified into one mechanism.
- Maxime
On 2011-02-14, at 2:28 PM, chevalma@iro.umontreal.ca wrote:
Marc, if you have time, I think it might be quite useful for the back-end to have a function to convert a bignum/num to an array of byte values.
Please explain exactly what you want (there are many variations possible). Where in the source can I find a use for this?
Marc
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list
There are already methods in backend/asm.js for generating immediate integer values (up to 64 bits wide and in either big-end or little-end format). The methods are
gen8 gen16 gen16BE gen16LE gen32 gen32BE gen32LE gen64 gen64BE gen64LE
Those methods currently use right shifts and bitwise-and to extract the appropriate bytes. I have rewritten them to use the num type instead.
Is that sufficient?
Marc
On 2011-02-14, at 2:37 PM, chevalma@iro.umontreal.ca wrote:
The use would be to write immediate integer values (8, 16, 32, 64 bits in 2s complement) when generating code in the backend. At some point we need to be able to generate the machine-representation of those values.
I'm not sure how exactly it's handled right now. Erick has an address/pointer class with a getBytes() method. Constants have a getImmValue() method which simply returns a JavaScript number at the moment (which doesn't work for 64 bit integer values). This will need to change, and ideally be unified into one mechanism.
- Maxime
On 2011-02-14, at 2:28 PM, chevalma@iro.umontreal.ca wrote:
Marc, if you have time, I think it might be quite useful for the back-end to have a function to convert a bignum/num to an array of byte values.
Please explain exactly what you want (there are many variations possible). Where in the source can I find a use for this?
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
-
chevalma＠iro.umontreal.ca -
Marc Feeley