|
Prev: ANN TclJS 1.0 [Was: Re: Autoproxy behind a corporate firewall thatuses a website to configure proxy]
Next: ANN TclJS 1.0 [Was: Re: Autoproxy behind a corporate firewallthat uses a website to configure proxy]
From: Alexandre Ferrieux on 2 Jul 2008 19:22 Hi, Since we have now bignums seamlessly integrated in [expr] computations, what are the available idioms to do ol'good 32-bit arithmetic ? The obvious [expr {int($x+1)}] is inefficient, since for $x==0x7FFFFFFF the temporary result $x+1 is generated as a bignum (and demoted to a 32-bit int immediately). Is there another method ? -Alex
From: Don Porter on 2 Jul 2008 22:45 Alexandre Ferrieux wrote: > Since we have now bignums seamlessly integrated in [expr] > computations, what are the available idioms to do ol'good 32-bit > arithmetic ? The obvious [expr {int($x+1)}] is inefficient, Efficiency aside, that is also not correct, since the range returned by the int(.) function is platform-dependent. To really force 32-bit arithmetic in a completely portable way, you need lots of masking with & 0xFFFFFFFF. Check the packages in tcllib that confront this problem for examples. DGP
From: Alexandre Ferrieux on 3 Jul 2008 04:13
On Jul 3, 4:45 am, Don Porter <dgpor...(a)verizon.net> wrote: > Alexandre Ferrieux wrote: > > Since we have now bignums seamlessly integrated in [expr] > > computations, what are the available idioms to do ol'good 32-bit > > arithmetic ? The obvious [expr {int($x+1)}] is inefficient, > > Efficiency aside, that is also not correct, since the range > returned by the int(.) function is platform-dependent. To > really force 32-bit arithmetic in a completely portable way, > you need lots of masking with & 0xFFFFFFFF. Check the packages > in tcllib that confront this problem for examples. OK. In fact my question was not motivated by a practical example, but by the perspective of native compilation of exprs. Indeed, in the vicinity of the new ideas about extended, multi-assignment exprs, we could imageine to recognize situations where: - the syntax makes explicit the fact that some variables should be restricted to a given numeric subtype - these variables have no traces - several computations are done in a single expr without touching the Tcl ground again (multi-line expr juggling with the same variables, without [] or new mathops). In these situations, it is valid to generate code for: - checking and/or shimmering the input variables - cracking open the Tcl_Obj layer, extracting raw native types like int, float, double (bignums left aside, sorry ;-). - direct assembly instructions for math operations on these native values (add,mul,fadd,fmul,...) - reinjection of result and assigned vars into proper Tcl_Objs I have the feeling that such an optimization, along with the native compilation of a few frequent idioms like [for {...} {$i<...} {incr i}], could bring Tcl's speed close to C's in an important family of cases. -Alex |