public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Dominik Vogt <vogt@linux.vnet.ibm.com>
To: libffi-discuss@sourceware.org
Cc: Andreas Krebbel <krebbel@linux.vnet.ibm.com>,
	       Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	       Andreas Arnez <arnez@linux.vnet.ibm.com>
Subject: C99 complex types support
Date: Mon, 24 Feb 2014 10:34:00 -0000	[thread overview]
Message-ID: <20140224103411.GA5130@linux.vnet.ibm.com> (raw)

I'm thinking about implementing support for complex types in
libffi.  At the moment some implementations that use libffi emulate
complex types as structs with two fields, but this does not work on
all targets.  Specifically, s390 and s390x are unable to handle
"_Complex float" as structs (or the complex64 type in the Go
language).

In 2007 there was a short discussion about complex:

> > Tom Tromey schrieb:
> > >>>>>> "Thomas" == Thomas Heller <theller@ctypes.org> writes:
> > I would possibly be able to find the official specification how
> > complex types have to be passed for architectures that I have access to
> > AND I'm at least halfway familiar with (x86 and AMD64, maybe G4), but there
> > is no hope I could make a patch for other architectures.  How would that
> > be handled?
> 
> Offhand I don't know.  I guess we could make it an error on
> unsupported platforms somehow.  Perhaps a compile-time error.

I've tried to implement complex support for s390[x] in libffi to
get a feeling how it works.  I could write a patch that adds
FFI_TYPE_COMPLEX (with value 15) that takes one base type as an
argument, and provide implementations for s390[x].

That leaves the question how to handle targets that have not
implemented the new type.

  * Compile time error
  * Runtime assertion if FFI_TYPE_COMPLEX is used
  * Runtime error if FFI_TYPE_COMPLEX is used

I've no real preference here as this choice it won't affect
s390[x], but I could implement error handling for all targets.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

                 reply	other threads:[~2014-02-24 10:34 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20140224103411.GA5130@linux.vnet.ibm.com \
    --to=vogt@linux.vnet.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=krebbel@linux.vnet.ibm.com \
    --cc=libffi-discuss@sourceware.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).