From: Alexandre Ferrieux on
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
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
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