From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 6C6A67EE4B for ; Fri, 27 Sep 2013 20:12:37 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.216.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.216.172 as permitted sender) identity=mailfrom; client-ip=209.85.216.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@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-qc0-f172.google.com) identity=helo; client-ip=209.85.216.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-qc0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDAAfKRVLRVdislGdsb2JhbABbgz9SrXiKEohCgRgIFg4BAQEBBwsLCRIqgiUBAQQBQAEbEgwDAQsGBQsDFyEhAQERAQUBChIGARIICodhAQMJBgybN4xSgwqEDwoZJwMKZIkAAQUMjFqCZwuEIAOWFoFpgS+LFYNKGCmEaSA X-IPAS-Result: AlwDAAfKRVLRVdislGdsb2JhbABbgz9SrXiKEohCgRgIFg4BAQEBBwsLCRIqgiUBAQQBQAEbEgwDAQsGBQsDFyEhAQERAQUBChIGARIICodhAQMJBgybN4xSgwqEDwoZJwMKZIkAAQUMjFqCZwuEIAOWFoFpgS+LFYNKGCmEaSA X-IronPort-AV: E=Sophos;i="4.90,994,1371074400"; d="scan'208";a="34665846" Received: from mail-qc0-f172.google.com ([209.85.216.172]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 Sep 2013 20:12:35 +0200 Received: by mail-qc0-f172.google.com with SMTP id l13so1993961qcy.3 for ; Fri, 27 Sep 2013 11:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=szlcN+mrNKguYIjMHbYjkrOc3LTMy13JQNsodb01oWY=; b=u6xT9gOz4iC0jLCWyFMZApcVvf8dfxb4edAZ5G/86xNEVt3SgG/E0LGHg+NKN3Gi9g oF0aBsrWr3eiglKkEJZXQZ4ZNU9NR6swRec1Gq8jLx21rF9K8T21mdEgrCgnQZDyOg7W ImJM02bZduON9zlFl5P/KY/+6sWmnR87hA6bCXdLgg9619yj3YMdgHxrWsVoclJg2tQE C/kzfiqUNUZpEYK+8dGuUcQm9fVQqEf2wkXZ9XW/jLPY3V0yGplpsMVZK1N2kBMbX1pm fuvYk9+SLbxo+Fc9e39Qzaqtc1h4TrPTMzUzRWBjMaysM8P3XfJUNvAanac++nQwaBy/ eLqg== X-Received: by 10.224.130.72 with SMTP id r8mr16088511qas.32.1380305555553; Fri, 27 Sep 2013 11:12:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.139.20 with HTTP; Fri, 27 Sep 2013 11:12:15 -0700 (PDT) In-Reply-To: References: From: Yotam Barnoy Date: Fri, 27 Sep 2013 14:12:15 -0400 Message-ID: To: Dmitry Grebeniuk , Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a1132ec7052095504e7616e07 Subject: Re: [Caml-list] Fwd: Proposal: re-design of ocaml headers --001a1132ec7052095504e7616e07 Content-Type: text/plain; charset=ISO-8859-1 I updated the definitions by reducing the number of bits for the tag to 13 (allowing up to 8000 tags, which definitely seems like it should be enough). I also forgot to insert the 0 tag, which is for arrays, tuples, records etc. So that's included now: + For 16-bit and 32-bit architectures: +---------------+----+----+-----+-------+------+ | wosize | ext|cust|noptr| color | tag | +---------------+----+----+-----+-------+------+ bits 31 18 17 16 15 14 13 12 0 - noptr: no pointers present - ext: uses extension word - cust(om): uses custom word. Custom word is normally used to indicate floats and pointers. - If both ext and cust are on, the extension word precedes the custom word in memory. 32 bit extension word (present only if ext is 1) +---------------------------------------------+ | wosize | +---------------------------------------------+ bits 31 0 32 bit custom word (default usage - present only if cust is 1): +----+----------------------------------------+ |nofp| pfbits | +----+----------------------------------------+ bits 31 30 0 - pfbits: indicates which double words are floats and pointers. Starting at the highest bit: - a 0 indicates neither a pointer nor a float - a 10 indicates a float (double) - a 11 indicates a pointer - If noptr is set, each bit indicates a float. If nofp is set, each bit indicates a pointer. + For 64-bit architectures: +----------------+--------+----+----+-----+-------+------+ | pfbits | wosize |cust|nofp|noptr| color | tag | +----------------+--------+----+----+-----+-------+------+ bits 63 37 36 18 17 16 15 14 13 12 0 - noptr: a structure with no pointers. All pfbits are used for floats, with a 1 signifying a float and a 0 signifying a non-float. - nofp: a structure with no floats. All pfbits are used for pointers, with a 1 signifying a pointer and a 0 signifying a value. - If both noptr and nofp are set, wosize is extended to include the pfbits. It does NOT mean that the structure has no floats and no pointers, only that the pfbits field is unused. - cust(om): uses custom double word. Custom double word is normally used to indicate more floats and pointers, but functionality can change with certain tags. - If the custom bit is set, wosize is expanded to include the pfbits in the main header. - pfbits: indicates which double words are floats and pointers. Starting at the highest bit: - a 0 indicates neither a pointer nor a float - a 10 indicates a float (double) - a 11 indicates a pointer - If noptr is set, each bit indicates a float. If nofp is set, each bit indicates a pointer. 64 bit custom header (default usage indicated - present only if cust is 1): +--------------------------------------------------------+ | pfbits | +--------------------------------------------------------+ bits 63 0 - pfbits: indicates which double words are floats and pointers. Starting at the highest bit: - a 0 indicates neither a pointer nor a float - a 10 indicates a float (double) - a 11 indicates a pointer - If noptr is set, each bit indicates a float. If nofp is set, each bit indicates a pointer. + Tags: - I think in general it's a good idea to move proprietary tags to the low end of the spectrum, and add more there if any are needed. This way, if the tag field is ever expanded, it's not necessary to move these tags again. - 0: Array, record, tuple tag - 1: Infix tag (must be 1 mod 4) - 2: Closure tag - 3: Lazy tag - 4: Object tag - 5: Forward tag - 6: Abstract tag - 7: String tag - 8: Double tag - 9: Custom tag - 10: Proposed tag: custom array. Half of custom header is used to indicate array member size, so one could have an array of tuples, saving both memory and indirections. - 100: Start of user tags -Yotam On Fri, Sep 27, 2013 at 2:08 PM, Yotam Barnoy wrote: > This is a good point. I'm not that familiar with the bindings in ocaml. > What I can say is that bindings should be written at an abstract enough > level that they don't mess directly with internal bit representations. > Using the ctypes library seems like a good way to go. If a bunch of > libraries' bindings have to be rewritten because the internal runtime > representation has changed... well then maybe that should be done once to > allow them to be abstract enough so that future internal changes don't have > the same impact. > > Yotam > > > On Fri, Sep 27, 2013 at 12:20 PM, Dmitry Grebeniuk wrote: > >> Hello. >> >> >> (this is a thread about runtime values >> >> representation, I suppose.) >> > This isn't really relevant to this topic, since this discussion is just >> > about ocaml headers, rather than the ocaml C FFI. The FFI would remain >> > largely the same. >> >> There is a lot of bindings have to be rewritten due to these >> changes. You can not automate it with C preprocessor. What would you >> suggest here? >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > --001a1132ec7052095504e7616e07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I updated the definitions by reducing the number of b= its for the tag to 13 (allowing up to 8000 tags, which definitely seems lik= e it should be enough). I also forgot to insert the 0 tag, which is for arr= ays, tuples, records etc. So that's included now:

+ For 16-bit and 32-b= it architectures:
=A0=A0=A0=A0 +---------------+----+----+-----+-------+= ------+
=A0=A0=A0=A0 |=A0=A0=A0=A0 wosize=A0=A0=A0 | ext|cust|noptr| col= or | tag=A0 |
=A0=A0=A0=A0 +---------------+----+----+-----+-------+----= --+
bits=A0 31=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 18=A0 17=A0=A0 16=A0=A0 15=A0=A0 1= 4=A0=A0 13 12=A0=A0 0

- noptr: no pointers present
- ext:=A0 uses= extension word
- cust(om): uses custom word. Custom word is normally us= ed to indicate floats and pointers.
- If both ext and cu= st are on, the extension word precedes the custom word in memory.

32 bit extension word (present only if ext is 1)
=A0=A0=A0=A0 +---------= ------------------------------------+
=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 wosize=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0 +----------------------------= -----------------+
bits=A0 31=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0

32 bit custom word (default usage - present only if cust is 1):
=A0= =A0=A0=A0 +----+----------------------------------------+
=A0=A0=A0=A0 |= nofp|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pfbits=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0 +----+-----------------= -----------------------+
bits=A0=A0 31=A0 30=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0

- pfbits: i= ndicates which double words are floats and pointers. Starting at the highes= t bit:
=A0=A0=A0 - a 0 indicates neither a pointer nor a float
=A0=A0= =A0 - a 10 indicates a float (double)
=A0=A0=A0 - a 11 indicates a pointer
=A0=A0=A0 - If noptr is set, each b= it indicates a float. If nofp is set, each bit indicates a pointer.

= + For 64-bit architectures:

=A0=A0=A0=A0 +----------------+--------+= ----+----+-----+-------+------+
=A0=A0=A0=A0 |=A0=A0=A0=A0 pfbits=A0=A0=A0=A0 | wosize |cust|nofp|noptr| co= lor | tag=A0 |
=A0=A0=A0=A0 +----------------+--------+----+----+-----+-= ------+------+
bits=A0 63=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 37 36=A0=A0= =A0 18=A0 17=A0=A0 16=A0=A0 15=A0=A0 14=A0=A0 13 12=A0=A0 0

- noptr:= a structure with no pointers. All pfbits are used for floats, with a 1 sig= nifying a float and a 0 signifying a non-float.
- nofp: a structure with no floats. All pfbits are used for pointers, with = a 1 signifying a pointer and a 0 signifying a value.
- If both noptr and= nofp are set, wosize is extended to include the pfbits. It does NOT mean t= hat the structure has no floats and no pointers, only that the pfbits field= is unused.
- cust(om): uses custom double word. Custom double word is normally used to= indicate more floats and pointers, but functionality can change with certa= in tags.
=A0=A0=A0 - If the custom bit is set, wosize is expanded to inc= lude the pfbits in the main header.
- pfbits: indicates which double words are floats and pointers. Starting at= the highest bit:
=A0=A0=A0 - a 0 indicates neither a pointer nor a floa= t
=A0=A0=A0 - a 10 indicates a float (double)
=A0=A0=A0 - a 11 indica= tes a pointer
=A0=A0=A0 - If noptr is set, each bit indicates a float. If nofp is set, ea= ch bit indicates a pointer.

64 bit custom header (default usage indi= cated - present only if cust is 1):
=A0=A0=A0=A0 +----------------------= ----------------------------------+
=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 pfbits=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0 +-------------------------------------= -------------------+
bits=A0 63=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0

- pfbits: indicates whi= ch double words are floats and pointers. Starting at the highest bit:
=A0=A0=A0 - a 0 indicates neither a pointer nor a float
=A0=A0=A0 - a 10= indicates a float (double)
=A0=A0=A0 - a 11 indicates a pointer
=A0= =A0=A0 - If noptr is set, each bit indicates a float. If nofp is set, each = bit indicates a pointer.

+ Tags:
- I think in general it's a good idea to move proprietar= y tags to the low end of the spectrum, and add more there if any are needed= . This way, if the tag field is ever expanded, it's not necessary to mo= ve these tags again.

- 0: Array, record, tuple tag
- 1: Infix tag (must be 1 mod 4)
- = 2: Closure tag
- 3: Lazy tag
- 4: Object tag
- 5: Forward tag
-= 6: Abstract tag
- 7: String tag
- 8: Double tag
- 9: Custom tag - 10: Proposed tag: custom array. Half of custom header is used to indicate= array member size, so one could have an array of tuples, saving both memor= y and indirections.
- 100: Start of user tags

-Yotam



On Fri, Sep 27, 2013 at 2:08 PM, Yotam Barnoy <yotambarno= y@gmail.com> wrote:
This is a good point. = I'm not that familiar with the bindings in=20 ocaml. What I can say is that bindings should be written at an abstract=20 enough level that they don't mess directly with internal bit=20 representations. Using the ctypes library seems like a good way to go.=20 If a bunch of libraries' bindings have to be rewritten because the=20 internal runtime representation has changed... well then maybe that=20 should be done once to allow them to be abstract enough so that future=20 internal changes don't have the same impact.

Yotam


On Fri, Sep 27, 2013 at 12:20 PM, Dmitry= Grebeniuk <gdsfh1@gmail.com> wrote:
Hello.

>> (this is a thread about runtime values
>> representation, I suppose.)
> This isn't really relevant to this topic, since this discussion is= just
> about ocaml headers, rather than the ocaml C FFI. The FFI would remain=
> largely the same.

=A0 There is a lot of bindings have to be rewritten due to these
changes. =A0You can not automate it with C preprocessor. =A0What would you<= br> suggest here?

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--001a1132ec7052095504e7616e07--