From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA11156; Thu, 3 Apr 2003 19:40:23 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA10756 for ; Thu, 3 Apr 2003 19:40:21 +0200 (MET DST) Received: from mail.exomi.com (mail.exomi.com [217.169.64.72]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h33HeL512903 for ; Thu, 3 Apr 2003 19:40:21 +0200 (MET DST) Received: from exomi.com (unknown [10.0.5.5]) by mail.exomi.com (Postfix) with ESMTP id 797755DFE; Thu, 3 Apr 2003 20:40:20 +0300 (EEST) Date: Thu, 3 Apr 2003 20:40:19 +0300 Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: caml-list@inria.fr To: Lauri Alanko From: Ville-Pertti Keinonen In-Reply-To: <20030402214655.GA10752@la.iki.fi> Message-Id: <568EB1B4-65FB-11D7-BBC9-000393863F70@exomi.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam: no; 0.00; caml-list:01 bug:01 printf:01 unboxed:01 datatype:01 untagged:01 implemented:01 boxing:01 ints:01 descriptors:01 int:01 ought:01 optimized:02 stack:02 explicitly:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > For occasional hotspots where naked integers are essential for > performance, wouldn't the easiest solution be to use the equivalent of > GHC's unboxed ints: a special _non-polymorphic_ datatype that doesn't > have tags. This type would be given a kind different from other types > to > prevent it from being used as a type parameter. Of course the GC still > needs to be prevented from following such values, but a separate stack > for them ought to do the trick. Untagged non-pointers on the stack are already identified by frame descriptors. Something like that but less restrictive could probably be implemented as optimized calling conventions for int32/int64 when explicitly specified. Native-sized integers are currently handled unboxed locally inside functions, they just require boxing when stored in a block, passed as parameters or returned. Using them is pretty inconvenient, though. ------------------- 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