From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id BD57E7EE49 for ; Mon, 16 Sep 2013 19:14:29 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of markus.mottl@gmail.com) identity=pra; client-ip=209.85.212.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of markus.mottl@gmail.com designates 209.85.212.172 as permitted sender) identity=mailfrom; client-ip=209.85.212.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="markus.mottl@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f172.google.com) identity=helo; client-ip=209.85.212.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="markus.mottl@gmail.com"; x-sender="postmaster@mail-wi0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcCAH87N1LRVdSslGdsb2JhbABagz9GDMB9gRgIFg4BAQEBBwsLCRIqgiUBAQQBQAEUBx0BAwELBgULDS4hAQERAQUBHAYTCIdoAQMJBpwtjFGDB4QgChknDWSITwEFDIx5gm4HhB4DlhKBaYxBg0oYKYRoIA X-IPAS-Result: ApcCAH87N1LRVdSslGdsb2JhbABagz9GDMB9gRgIFg4BAQEBBwsLCRIqgiUBAQQBQAEUBx0BAwELBgULDS4hAQERAQUBHAYTCIdoAQMJBpwtjFGDB4QgChknDWSITwEFDIx5gm4HhB4DlhKBaYxBg0oYKYRoIA X-IronPort-AV: E=Sophos;i="4.90,917,1371074400"; d="scan'208";a="33099386" Received: from mail-wi0-f172.google.com ([209.85.212.172]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Sep 2013 19:14:28 +0200 Received: by mail-wi0-f172.google.com with SMTP id hn9so1414351wib.11 for ; Mon, 16 Sep 2013 10:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p4WimWa+rbET4jZ5twIuymuqD2sP1YXRFFXzlK1hIm8=; b=nGw6F/CgR2wzaYWnTzAIubMjZDL0utrJGoZjKN78fqyk+Dm8FupfnOdIx6iwvOOyHM /Nyls5kZUkg5vD/KQXXZYiyoRsp6WxpfXSYIfK4jBAu3j0fmRxTdiwbMp59mj61Yfq0Z dUIcgdhHWpsQdQ0gCDn8rd7vrsc2mvyrtQKJawtAtoiOFecXoutZa4nkZDWwY3y+t4u8 M6LcoWvo5YgzC3AneK+2k4EvAxpQYY9bThTOo6afLxw/T+/vEiCHATUQJCYF++rKU3DO XUF/rrt/OTV+yjJv/jI063HKPCWsKZi8Vs9uiOk/h+4B3owCZ7BU5+t4naqAsUxAHUMp Wu1A== MIME-Version: 1.0 X-Received: by 10.194.9.70 with SMTP id x6mr18067367wja.22.1379351669295; Mon, 16 Sep 2013 10:14:29 -0700 (PDT) Received: by 10.194.172.4 with HTTP; Mon, 16 Sep 2013 10:14:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Sep 2013 13:14:29 -0400 Message-ID: From: Markus Mottl To: Yotam Barnoy Cc: Ocaml Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Expanding the Float Array tag On Mon, Sep 16, 2013 at 12:49 PM, Yotam Barnoy wrote: > Why do doubles need special handling though, even on a 32-bit system? My > suggestion is that the Double_tag be changed to Flat_tag, meaning that all > non-pointer objects can reside in this tag. The only issue I've found so far > is that polymorphic <, <=, > and >= would not work. However, these operators > should not be allowed on a vector anyway since there is no natural ordering > scheme for vectors. If there are other issues, please let me know. Here is a problem: If you marshal a float array on a 64-bit platform, how is the 32-bit platform supposed to know about the "logical" and "physical" size of the array? On 64-bit platforms where everything is the same size the distinction wouldn't matter, of course, but on 32-bit it does. The header word can only provide one size (but tag distinctions). > I agree regarding the expansion of 246 constructors. This must have been > kept for compatibility with 32 bit systems. I think what should happen in 32 > bit systems is that one constructor should be reserved for having >246 > constructors, in which case another word of memory could be utilized for the > constructor code. In fact, you'd only need to use that extra word if the > particular constructor exceeds 246. Appending such a "long" constructor to the end of the block is probably doable with acceptable complexity. In that position it should not require many changes elsewhere in the runtime system or code generators. On 64-bit platforms I'd still prefer seeing a change of the header field layout for efficiency reasons even though this would likely make a lot of "marshal" users cry and maybe require more effort to implement. But I wouldn't mind just using "extended" blocks with the current header layout there, too, if this made everybody happy. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com