From mboxrd@z Thu Jan  1 00:00:00 1970
From: tlaronde@polynum.com
Date: Wed, 21 Apr 2010 15:40:19 +0200
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20100421134019.GA1382@polynum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [9fans] Integer arithmetic: some lessons
Topicbox-Message-UUID: 0b725990-ead6-11e9-9d60-3106f5b1d025

Hello,

Still about integer arithmetic.

In my case, we have strictly the same C89 code (the process is hopefully
deterministic), and the test is on the very same node (very same
machine/cputype): plan9/386, NetBSD/i386.

The implementation of the C library is here not the problem. The problem
involves purely integer arithmetic.

And everything goes OK with gcc/NetBSD, but the most "calculus" program:
METAFONT, fails in some cases on Plan9 (TeX is indeed more a processor
and is simpler: works).

To be short the problem is about the negative integers.

Nothing is mandatory (in C89) about : a / b, only that :
	a == (a / b) * b + a % b;

There is two main types of choices: "translation preserving" and
"negation preserving" i.e. in this later case :
	(-a) div b == -(a div b).

This is "negation preserving" for both gcc and ken-cc.

Furthermore, (a + b) / 2 does not lead---with negative values--- to the
same as (a+b) >> 1: in this later case, we have the "floor", while the
"negation preserving" div leads the "ceil" for negatives.

This is the same with both gcc and ken-cc.

But if I start replacing div by binary shifting (when power of two are
involved), I have varying results with ken-cc, but not with gcc, whether
I set optimization or not.

Conclusion (apparently): gcc always translate div involving power of two
to binary manipulations, while (apparently) ken-cc does not.

Conclusion: I will have to replace in METAFONT all div involving power
of two to binary operations, since if I replace in some places and not
in others, I wreak havoc the algorithms since computations are not done
the same way for combined chunks.

If others have problems porting software to Plan9 (or from Plan9), this
may be a clue.

And I don't think---if I'm correct---that ken-cc is at fault, since the
results of (a+b)/2 and (a+b) >> 1 are not the same, so this is changing
the semantics of a program beyond the reach of the programmer.

[That's probably why there is still need for calculus dedicated
languages, since neither for float nor for integers, general purpose
languages guarantee a lot.]

Do people having worked with the compilers (Charles Forsythe for
example) can infirm/confirm or make the explanations more complete?

Cheers,
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C