Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Mattias Engdegård" <mattias@virtutech.se>
To: skaller@users.sourceforge.net
Cc: jonathan.roewen@gmail.com, pal_engstad@naughtydog.com,
	caml-list@inria.fr
Subject: Re: [Caml-list] if (n:int) < 0 then (-n) > 0 is FALSE
Date: Fri, 8 Dec 2006 12:09:12 +0100	[thread overview]
Message-ID: <200612081109.kB8B9CB22752@virtutech.se> (raw)
In-Reply-To: <1165545466.6979.20.camel@rosella.wigram> (message from skaller on Fri, 08 Dec 2006 13:37:46 +1100)

>> (Signed overflow is not legal in C (undefined behaviour), and a decent
>> compiler will warn this can be detected statically.)

s/warn/warn when/ (sorry)

>Hmmm. In the usual full word register operations most CPU
>have an overflow flag which a single conditional branch can
>detect. Given branch prediction the branch is unlikely to be
>taken the cost of detection is probably extremely small,
>provided you have control at the assembler level.

Even well-predicted branches are not free. They pollute the BTB, make
the code bigger (consuming I-cache), consume various resources
(decoding, instruction queue, ALU, rename registers etc) and as
integer operations are very common these all add up.

The ideal architecture in this regard would be one with optionally
trapping integer instructions, and very fast user-mode traps.

>Ocaml has slighly messier representation with one less
>bit, but i guess overflow detection wouldn't be so hard
>or all that expensive -- but I could be wrong, perhaps
>someone on Ocaml team has looked at this can can comment?

I suppose it wouldn't be impossible to add a compiler flag to change
the integer overflow semantics from wrapping to trapping.
Doing so for constant expressions (the original complaint in this thread)
would probably be less work.


  reply	other threads:[~2006-12-08 11:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-07 18:32 Pal-Kristian Engstad
2006-12-07 19:19 ` [Caml-list] " Jonathan Roewen
2006-12-07 19:43   ` Mattias Engdegård
2006-12-07 20:02     ` Brian Hurt
2006-12-08  2:37     ` skaller
2006-12-08 11:09       ` Mattias Engdegård [this message]
2006-12-08 17:48     ` Jon Harrop
2006-12-08 18:20       ` Mattias Engdegård
2006-12-08 18:37         ` Brian Hurt
2006-12-09  2:03           ` skaller
2006-12-07 21:13 ` Martin Jambon

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=200612081109.kB8B9CB22752@virtutech.se \
    --to=mattias@virtutech.se \
    --cc=caml-list@inria.fr \
    --cc=jonathan.roewen@gmail.com \
    --cc=pal_engstad@naughtydog.com \
    --cc=skaller@users.sourceforge.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