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 EAA26120; Fri, 16 Jul 2004 04:01:49 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA26680 for ; Fri, 16 Jul 2004 04:01:48 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i6G21jEV012370 for ; Fri, 16 Jul 2004 04:01:46 +0200 Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id LAA28474; Fri, 16 Jul 2004 11:00:17 +0900 (JST) Date: Fri, 16 Jul 2004 11:00:17 +0900 (JST) Message-Id: <20040716.110017.66047488.garrigue@kurims.kyoto-u.ac.jp> To: j.prevost@gmail.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Unboxing options, was RE: assertions or exceptions? From: Jacques GARRIGUE In-Reply-To: References: <20040716.093517.95470327.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 40F73709.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 unboxing:01 jacques:01 prevost:01 prevost:01 caml's:01 pointers:01 -byte:01 aligned:01 jacques:01 assertions:01 garrigue:01 garrigue:01 exceptions:04 xavier's:05 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: John Prevost > Apologies for keeping the conversation going, but since I just thought of this: > > Caml's internal pointers are at minimum 4-byte aligned. What about > using the other "safe" set of trailing bits, "10", to mark options? > i.e.: > > None = ...0010 (2) > Some None = ...0110 (6) > Some Some None = ...1010 (10) > Some Some Some None = ...1110 (14) > > and so on? This would remove the need to use a special memory area > (or check that area) for wrapping and unwrapping. There'd still be a > cost, but I would think it should be smaller than the cost you > describe? > > That said, I also don't think this is a critical issue. Now that you tell it, Xavier's idea (and implementation) was actually along this line. The trouble is that it doesn't change the cost: you just do an and on the lower bits rather than on the higher ones. Might be worth retrying some day, as hardware is changing, but I don't expect any real change. Jacques Garrigue ------------------- 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