From: Yotam Barnoy <yotambarnoy@gmail.com>
To: Dmitry Grebeniuk <gdsfh1@gmail.com>,
Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Fwd: Proposal: re-design of ocaml headers
Date: Fri, 27 Sep 2013 14:12:15 -0400 [thread overview]
Message-ID: <CAN6ygOkQYP2n3X50f6XW1coxqVpYTc7TCfcDJXmwA4smPnG31A@mail.gmail.com> (raw)
In-Reply-To: <CAN6ygOnmeFTkLsBMgGExJgcpdX_FpcmCq2ryO3x70z3yoKBDtg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5534 bytes --]
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 <yotambarnoy@gmail.com> 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 <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.
>>
>> 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
>>
>
>
[-- Attachment #2: Type: text/html, Size: 7220 bytes --]
next prev parent reply other threads:[~2013-09-27 18:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 14:05 [Caml-list] " Yotam Barnoy
2013-09-27 15:08 ` Dmitry Grebeniuk
[not found] ` <CAN6ygOmuCX6HLfSns0tXQCF3LWMANqhpnSN0vGWcNg0one2QzQ@mail.gmail.com>
2013-09-27 15:25 ` [Caml-list] Fwd: " Yotam Barnoy
2013-09-27 16:20 ` Dmitry Grebeniuk
2013-09-27 18:08 ` Yotam Barnoy
2013-09-27 18:12 ` Yotam Barnoy [this message]
2013-09-27 18:15 ` Paolo Donadeo
2013-09-27 18:41 ` Yotam Barnoy
2013-09-27 15:31 ` [Caml-list] " Anthony Tavener
2013-09-27 15:37 ` Yotam Barnoy
2013-09-27 16:50 ` Dmitry Grebeniuk
2013-09-30 14:48 ` Goswin von Brederlow
2013-09-30 15:31 ` Yotam Barnoy
2013-10-08 10:52 ` Goswin von Brederlow
2013-10-11 15:48 ` Yotam Barnoy
2014-01-30 20:53 ` Yotam Barnoy
2014-02-01 15:27 ` Goswin von Brederlow
2013-10-06 10:39 ` Florian Weimer
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=CAN6ygOkQYP2n3X50f6XW1coxqVpYTc7TCfcDJXmwA4smPnG31A@mail.gmail.com \
--to=yotambarnoy@gmail.com \
--cc=caml-list@inria.fr \
--cc=gdsfh1@gmail.com \
/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