From: Shawn Wagner <shawnw@speakeasy.org>
To: caml-list@inria.fr
Subject: Re: [Caml-list] int32/int64 literals in next release?
Date: Wed, 13 Nov 2002 23:44:25 -0800 [thread overview]
Message-ID: <20021113234425.C23757@speakeasy.org> (raw)
In-Reply-To: <200211132142.WAA19709@pauillac.inria.fr>; from pierre.weis@inria.fr on Wed, Nov 13, 2002 at 10:42:36PM +0100
On Wed, Nov 13, 2002 at 10:42:36PM +0100, Pierre Weis wrote:
> Hi,
>
> > Is there any chance some way of inputing int32/int64 literals can be
> > added to the compiler for this next release?
>
> AFAIK, this is fairly hight in the todo list.
>
Ask, and ye shall recieve (In other words, I had a few hours to kill and
have been wanting this feature myself).
http://raevnos.pennmush.org/code/litint306-1.diff.gz
or http://raevnos.pennmush.org/code/ocaml.html in case the direct URL
doesn't work, as I might put up newer versions (-2, -3, etc.) if I fix any of
the problems noted below.
Uses a suffix to the number to indicate type, like in C. The actual suffixes
are taken from the printf formats.
With it:
% ./ocaml
Objective Caml version 3.06
# 0;;
- : int = 0
# 0l;;
- : int32 = <int32 0>
# 0L;;
- : int64 = <int64 0>
# 0n;;
- : nativeint = <nativeint 0>
# Int32.mul 6l 7l;;
- : int32 = <int32 42>
Tested with bytecode and i386 linux native.
Problems I know about already:
* The native compiler doesn't support literal int64's, as I didn't see a place
to crib from for what to emit in cmmgen.ml after a quick look.
* int32's and nativeints on the native compiler aren't heavily tested, though
simple problems using them compile and appear to work right.
* Compiling camlp4 breaks with:
../../boot/ocamlrun ../boot/camlp4 -nolib -I ../boot ./pa_lispr.cmo
pa_extend.cmo q_MLast.cmo pr_dump.cmo -o pa_lisp.ppo pa_lisp.ml
Error while loading "./pa_lispr.cmo": interface mismatch on MLast.
I haven't been able to figure out why. camlp4 is commented out of the
Makefile for now.
* The Foo.of_string functions aren't handling the suffixes, even though I
changed ints.c:parse_long() and ints.c:int64_of_string() to do so, and they
work when called through gdb. Do ocamlrun and the native compiler use
another set of functions for the conversions?
Help with any of the above is appreciated.
--
Shawn Wagner
shawnw@speakeasy.org
-------------------
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 prev parent reply other threads:[~2002-11-14 7:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-13 22:03 Chris Hecker
2002-11-13 21:42 ` Pierre Weis
2002-11-14 7:44 ` Shawn Wagner [this message]
2002-11-14 8:49 ` Yurii A. Rashkovskii
2002-11-15 0:14 ` Shawn Wagner
2002-11-15 5:32 ` Daniel de Rauglaudre
2002-11-26 7:10 ` Shawn Wagner
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=20021113234425.C23757@speakeasy.org \
--to=shawnw@speakeasy.org \
--cc=caml-list@inria.fr \
/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