<div>FWIW, The implementation of Erlang treats integers larger than 2^27 as "bignums" which are separate from "regular integers." The reason it's not 2^31 or 2^32 is that Erlang uses a few bits for "tag bits," probably to optimize the storage of these numbers within the garbage collected heap.</div>
<div> </div><div>This also means that Erlang math arithmetic is not especially zippy compared to most other languages, because the tag bits must generally be removed for each operation.</div><div> </div><div>Chances are that making an int64 *always* generates a bignum, whereas making an int only makes a bignum if it's necessary. If the assumption is that integers < 2^27 in magnitude are always little-ints, then it seems like the behavior of making int64 is arguably broken for such numbers.</div>
<div> </div><div>Sincerely,</div><div> </div><div>jw</div><div> </div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br></div><div class="gmail_quote">On Wed, Jun 29, 2011 at 3:11 PM, Paul Davis <span dir="ltr"><<a href="mailto:paul.joseph.davis@gmail.com">paul.joseph.davis@gmail.com</a>></span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
<div class="im">On Mon, Jun 27, 2011 at 6:03 AM, Sverker Eriksson<br>
<<a href="mailto:sverker@erix.ericsson.se">sverker@erix.ericsson.se</a>> wrote:<br>
> Have you tested with a debug built emulator. That may catch faulty NIF<br>
> behaviors earlier. Otherwise if a NIF builds broken terms on the process<br>
> heap it might not be discovered until later when those terms are matched or<br>
> maybe garbage collected.<br>
><br>
> There is no difference to make NIF's for the halfword emulator. Just use the<br>
> NIF API as intended and don't cheat (make assumptions about<br>
> sizeof(ERL_NIF_TERM) for example).<br>
><br>
> /Sverker, Erlang/OTP<br>
><br>
<br>
</div>I've reduced this to a failing test case in the NIF API [1].<br>
<br>
In the end it boils down to these two functions (notice one is int64,<br>
the other not):<br>
<br>
ERL_NIF_TERM<br>
run_test1(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])<br>
{<br>
    return enif_make_int64(env, 1);<br>
}<br>
<br>
ERL_NIF_TERM<br>
run_test2(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])<br>
{<br>
    return enif_make_int(env, 1);<br>
}<br>
<br>
Test 1 returns a Value V where (V =:= 1) is false, but (V == 1) is<br>
true. The second function returns a value where both comparisons are<br>
true.<br>
<br>
Paolo also found that amusingly this bug disappears at 2^27 as shown by:<br>
<br>
ERL_NIF_TERM<br>
run_test3(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])<br>
{<br>
    return enif_make_int64(env, 134217727);<br>
}<br>
<br>
ERL_NIF_TERM<br>
run_test4(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])<br>
{<br>
    return enif_make_int64(env, 134217728);<br>
}<br>
<br>
run_test3 returns a value that can't be pattern matched against<br>
134217727 but test 4 returns a value that can be matched against<br>
134217728.<br>
<br>
Also, I built R14B03 on Ubuntu 10.04 with this configure:<br>
<br>
./configure --enable-smp --enable-threads --enable-m64-build<br>
--without-javac --enable-halfword-emulator<br>
<br>
The processors are a pair of dual core Xeon's if that's important at all.<br>
<br>
[1] <a href="https://github.com/davisp/halfwordtest" target="_blank">https://github.com/davisp/halfwordtest</a><br>
<div><div></div><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>