From: "Fabrice Le Fessant" <fabricel@microsoft.com>
To: "Ville-Pertti Keinonen" <will@exomi.com>,
"Gregory Morrisett" <jgm@CS.Cornell.EDU>
Cc: <caml-list@inria.fr>
Subject: RE: [Caml-list] Bug? Printf, %X and negative numbers
Date: Thu, 3 Apr 2003 10:29:49 +0100 [thread overview]
Message-ID: <76A83D32A3D2704C9D01CDC1EFFC8FF6043A5322@tvp-msg-02.europe.corp.microsoft.com> (raw)
> I agree that the OCaml runtime makes good compromises that
> work well in practice. Any added complexity would probably
> hurt symbolic code, which seems to have had a high priority
> in considerations of tradeoffs.
Just my two pence: in MLdonkey, int64 are used everywhere instead of
int, and instead of int32, which are two
small for file sizes. So, it will not benefit from any optimization on
int32. However, it would benefit
from a new type 'long', that would be at-least a 63-bit integer.
Depending on the platform, this type could
be implemented either by a traditionnal int (with the integer-bit set,
on 64-bit platforms), or by an int64
on other platforms.
Since in the next years, more and more computers will be 64-bit, and
more and more applications will need
support for integers in the range 33-bit ... 63-bit, this could be more
interesting than optimizing 32-bit
integers (using the 'long' type, a program that would have used 32-bit
integers, would have the guaranty
that the longs are not allocated on 64-bit platforms). Moreover, it can
probably be implemented in the
Pervasives module without any changes in the compiler. But maybe int32
are already implemented by a normal int
on 64-bit platforms ?
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next reply other threads:[~2003-04-03 9:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-03 9:29 Fabrice Le Fessant [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-04-02 18:42 Gregory Morrisett
2003-04-02 21:12 ` Ville-Pertti Keinonen
2003-04-02 21:46 ` Lauri Alanko
2003-04-03 17:40 ` Ville-Pertti Keinonen
2003-04-04 16:14 ` Brian Hurt
2003-04-04 17:14 ` Ville-Pertti Keinonen
2003-04-04 17:27 ` Falk Hueffner
2003-04-03 0:52 ` brogoff
2003-03-28 21:19 Brian Hurt
2003-03-28 22:21 ` Yutaka OIWA
2003-03-30 9:51 ` Xavier Leroy
2003-03-31 15:44 ` Brian Hurt
2003-03-31 17:13 ` Ville-Pertti Keinonen
2003-04-01 8:19 ` Xavier Leroy
2003-04-01 16:09 ` David Brown
2003-04-01 16:45 ` Tim Freeman
2003-04-01 18:59 ` Brian Hurt
2003-04-01 19:16 ` Ville-Pertti Keinonen
2003-04-01 19:23 ` Tim Freeman
2003-04-01 21:00 ` Ville-Pertti Keinonen
2003-04-01 19:56 ` Brian Hurt
2003-04-01 20:45 ` Ville-Pertti Keinonen
2003-04-01 21:03 ` Brian Hurt
2003-04-02 8:55 ` Andreas Rossberg
2003-04-02 9:20 ` Ville-Pertti Keinonen
2003-04-01 18:34 ` Ville-Pertti Keinonen
2003-04-02 11:44 ` Claude Marche
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=76A83D32A3D2704C9D01CDC1EFFC8FF6043A5322@tvp-msg-02.europe.corp.microsoft.com \
--to=fabricel@microsoft.com \
--cc=caml-list@inria.fr \
--cc=jgm@CS.Cornell.EDU \
--cc=will@exomi.com \
/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