9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: [9fans] Integer arithmetic: some lessons
Date: Wed, 21 Apr 2010 15:40:19 +0200	[thread overview]
Message-ID: <20100421134019.GA1382@polynum.com> (raw)

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



             reply	other threads:[~2010-04-21 13:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21 13:40 tlaronde [this message]
2010-04-21 15:03 ` geoff
2010-04-21 20:19   ` tlaronde
2010-04-21 23:28 ` Bakul Shah
2010-04-22  5:51   ` tlaronde
2010-04-22  9:42   ` Steve Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100421134019.GA1382@polynum.com \
    --to=tlaronde@polynum.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).