caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
To: Markus Mottl <markus.mottl@gmail.com>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Expanding the Float Array tag
Date: Mon, 16 Sep 2013 15:09:12 -0400	[thread overview]
Message-ID: <CAN6ygOmXpgj9SJk7JZN2GzFrG8qY6roeuNcAfdvBjPFwLYUo7w@mail.gmail.com> (raw)
In-Reply-To: <CAP_800qfQeJfO0OZHGo87OOy1rWzbNYnEihqeh5S2My4L0TJsg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

That's a good point.

Another relatively easy optimization would be to use a bit from the header
on 64-bit platforms (32-bit platforms have no available bits) to indicate
another form of extension, whereby an extra word is used as a bitmap to
indicate which words are floats. Haskell uses a similar trick to indicate
which words are pointers on the stack. This would remove the indirection of
floats in the majority of cases, except of course in the stack itself.
This shouldn't have an impact on marshaling.

BTW bits in the 64-bit header should probably have been marked as reserved
rather than making the wo_size field impossibly large.

Yotam


On Mon, Sep 16, 2013 at 1:14 PM, Markus Mottl <markus.mottl@gmail.com>wrote:

> On Mon, Sep 16, 2013 at 12:49 PM, Yotam Barnoy <yotambarnoy@gmail.com>
> 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).
>

[-- Attachment #2: Type: text/html, Size: 2246 bytes --]

  reply	other threads:[~2013-09-16 19:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16 15:26 Yotam Barnoy
2013-09-16 16:29 ` Markus Mottl
2013-09-16 16:49   ` Yotam Barnoy
2013-09-16 17:14     ` Markus Mottl
2013-09-16 19:09       ` Yotam Barnoy [this message]
2013-09-17  0:31         ` Yotam Barnoy
2013-09-19  9:40     ` Goswin von Brederlow
2013-09-17  9:32 ` Gerd Stolpmann
2013-09-18 15:10   ` Yotam Barnoy
2013-09-19  6:18     ` oleg
2013-09-19  9:47       ` Goswin von Brederlow
2013-09-19 10:10     ` Goswin von Brederlow
2013-09-20  2:18       ` Yotam Barnoy
2013-09-20  6:25         ` Goswin von Brederlow

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=CAN6ygOmXpgj9SJk7JZN2GzFrG8qY6roeuNcAfdvBjPFwLYUo7w@mail.gmail.com \
    --to=yotambarnoy@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=markus.mottl@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;
as well as URLs for NNTP newsgroup(s).