add built-in complex number types for C ABI compatibility

[steveklabnik]

Issue by thestinger
Friday Nov 15, 2013 at 06:15 GMT

For earlier discussion, see rust-lang/rust#10500

This issue was labelled with: I-enhancement in the Rust repository

---

These are sadly not just treated as a simple struct on various platforms and have ABI requirements. I think support for the existing C math library is important because this isn't something we want to recreate on every platform.

[huonw]

A possible implementation strategy is a new #[repr] (e.g. C_complex) that can only be attached to a struct of two f32s or two f64s and forces them to be considered C complex numbers for the purpose of calling extern "C" functions.

[nagisa]

As far as I could understand it can and should be represented as an array of 2 floats or doubles to be C99-compatible.

struct<T: f32 or f64> Complex<T>{
    data: [T; 2]
}

https://gist.github.com/258c1bfdc80970642dd1 seems to work at least on play.rust-lang.org.

[bluss]

I don't think playground is using x86, which was the platform with noticeable breakage.

[main--]

Looks like playground is is using x86_64.

[nagisa]

Why is x86 behaving differently?

[bluss]

@nagisa, see this comment; we need a new compiler feature for this.

[nagisa]

@bluss I saw how it is different. I’m asking why it is different… i.e. is it specified anywhere in the C standard or x86/Sys V ABI (I admit, I have hard time reading and searching these most of the time) or is it just C compilers doing C things?

[codyps]

@nagisa the C standard doesn't specify any calling conventions. SysV ABI for i386 (at least this version) specifies the use of registers for returning complex float (but note it also specifies complex double is returned in memory)

Not sure if all systems follow that ABI (anyone know what windows does?)

[nagisa]

@jmesmon great!

To be more precise (for people who have as much trouble searching for things as me) it is table 2.4 on page 14.

It could still be hacked around without (much) language support by doing something along the lines of

#[cfg(target_Cabi="SysVx86")] // replace with the relevant target_os and target_arch combinations
#[repr(C)]
struct<T: f32> Complex<T>{ // probably will need to give up parametricity because different representations are necessary for `Complex<f32>` and `Complex<f64>`
    data: i64
}

EDIT: it probably wants to be a newtyped alias instead or perhaps an enum with repr(u64).

EDIT2: My primary goal is to understand as much as possible about the problem before agreeing or disagreeing with this course of action (adding language level things). This requires at least details on C ABIs used on all platforms we support.

Short summary so far:

• x86 Sys V (pages 12 and 14 of http://www.uclibc.org/docs/psABI-i386.pdf)
  • Complex<f32> = u64
  • Complex<f64> = memory = struct { f64, f64 } or [f64; 2] (?)
• x86_64 Sys V (page 18 of http://www.x86-64.org/documentation/abi.pdf)
  • Complex<T> = struct { T, T}

[codyps]

Shouldn't some form of specialization allow us to keep Complex parameterized?

[nagisa]

VC does not support C complex.h. As far as C++ goes… complex definition.

On x64, the complex<float> should be passed the same way as u64 according to their ABI’s parameter passing.
I gave up searching for x86 conventions.

---

Something to also consider is that once we implement something for _Complex at language level, we should also do something similar for _Decimal.

[andresv]

Workaround in action: https://github.com/cubehub/doppler/blob/master/src/dsp.rs
Here cexpf works on both 64 and 32 bit machine.