On 2006-04-29, Manuel M T Chakravarty wrote:

Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:

...

On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:

...

I was curious if ghc could support the following basic types, they will likely just be aliases of existing types.

WordPtr uintptr_t WordMax uintmax_t IntPtr intptr_t IntMax intmax_t

all these C types are defined by ISO C so should be available, otherwise, they are easy enough to generate in ghcs autoconf script.

jhc provides these under these names in Data.Word and Data.Int. they would be useful for writing jhc/ghc portable low level code, and writing 32/64 bit safe code.

oh, I forgot the all important conversion routines,

ptrToWordPtr :: Ptr a -> WordPtr wordPtrToPtr :: WordPtr -> Ptr a

ptrToIntPtr :: Ptr a -> IntPtr intPtrToPtr :: IntPtr -> Ptr a

jhc makes these available in Jhc.Addr, but if ghc decides to provide them in a common spot (Foreign.Ptr maybe?)

then I will have jhc follow suit.

I'd also propose these be added to the FFI standard.

I collect additions to the FFI on the Haskell' wiki:

http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface

I added a note about these types. Any other ISO C types that we should include?

complex <foo>. -- Aaron Denney -><-

John Meacham:

On Tue, May 02, 2006 at 03:29:16AM +0000, Aaron Denney wrote:

...

On 2006-04-29, Manuel M T Chakravarty wrote:

...

Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham:

...

On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote:

...

I was curious if ghc could support the following basic types, they will likely just be aliases of existing types.

WordPtr uintptr_t WordMax uintmax_t IntPtr intptr_t IntMax intmax_t

all these C types are defined by ISO C so should be available, otherwise, they are easy enough to generate in ghcs autoconf script.

jhc provides these under these names in Data.Word and Data.Int. they would be useful for writing jhc/ghc portable low level code, and writing 32/64 bit safe code.

oh, I forgot the all important conversion routines,

ptrToWordPtr :: Ptr a -> WordPtr wordPtrToPtr :: WordPtr -> Ptr a

ptrToIntPtr :: Ptr a -> IntPtr intPtrToPtr :: IntPtr -> Ptr a

jhc makes these available in Jhc.Addr, but if ghc decides to provide them in a common spot (Foreign.Ptr maybe?)

then I will have jhc follow suit.

I'd also propose these be added to the FFI standard.

I collect additions to the FFI on the Haskell' wiki:

http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface

I added a note about these types. Any other ISO C types that we should include?

complex <foo>.

not ISO C, but I think they would be very cool to provide

http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Vector-Extensions.html

various vector (SSE, MMX, SIMD) types that are machine independent and compiled to whatever vector processing instructions the underlying arch supports. (pretty much all support some sort of them nowadays)

I agree that this would be cool, but I think it goes beyond Haskell'. It is not just a matter of data types. For it to be useful, you need to generate the right code, too. Manuel

Ben Rudiak-Gould wrote:

John Meacham wrote:

...

also, incidentally, for anyone on x86 that cares about math performance, use -optc-fsse2 to make it use the much nicer math coprocessor available on modern x86 cpus.

I object to its characterization as "nicer". It's faster, but *lower precision*. It worries me that people are so blithely abandoning those extra bits in the name of speed. A few years from now there's going to be an expensive engineering failure, and months of investigation will reveal that it was because a math library was compiled for SSE2. Be careful out there.

On the other hand, keeping intermediate Doubles to 80-bit precision is both (a) non-portable and (b) unpredictable (the programmer doesn't know which intermediates are going to be stored in 80 bits, and turning on optimisation will probably make a difference). I suppose you might argue that "extra precision is always good". But I like it when Haskell programs give the same results, regardless of the platform, compilation strategy, and level of optimisation.

(And while I'm on the subject, Haskell should have a LongDouble type.)

LongDouble would be fine, but storing intermediate Doubles in 80 bits is bad. Cheers, Simon

Simon Marlow wrote:

I suppose you might argue that "extra precision is always good".

Well... I'm having a hard time thinking of a situation where it isn't. I realize that people want reproducibility, I'm just not convinced that they should. The situations where optimization flags make a significant difference in the result are situations where the original result wasn't trustworthy to begin with. Reproducible rounding gives you a false sense of security in those cases, and doesn't make a difference otherwise. If you know IEEE 754 inside out, and IEEE double-precision is exactly what you want, then it's nice if your programming language can cater to that, but along those lines it'd be nice if Haskell supported rounding modes, trap handlers, and so on. I suppose this problem could be solved the way the analogous Int problem is solved, with a machine-precision Float and portable/reproducible Float32 and Float64. The x87 isn't the only FPU with this problem. The PowerPC has a fused (double*double)+double operation that the optimizer can't use if you need reproducibility, because it doesn't round the intermediate product.

LongDouble would be fine, but storing intermediate Doubles in 80 bits is bad.

The x87 registers are actually 82 bits wide, so even using LongDouble doesn't guarantee reproducibility. Maybe there needs to be a Float80 also. (Available only on x86, presumably.) -- Ben

skaller wrote:

On Fri, 2006-05-12 at 00:34 +0100, Ben Rudiak-Gould wrote:

...

Simon Marlow wrote:

...

I suppose you might argue that "extra precision is always good". Well... I'm having a hard time thinking of a situation where it isn't.

Wastes space in the cache tree, slowing down the program and limiting the max size problem that can be handled.

But we were talking about flushing temporary values to memory to force rounding; in this case keeping the extra precision is cheaper than getting rid of it. When that's not true, I agree that less precision is sometimes better. -- Ben

On 12 May 2006 00:47, John Meacham wrote:

On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:

...

On the other hand, keeping intermediate Doubles to 80-bit precision is both (a) non-portable and (b) unpredictable (the programmer doesn't know which intermediates are going to be stored in 80 bits, and turning on optimisation will probably make a difference).

Indeed, not storing the intermediate values as 80 bits is one of the 'nicer' things I was refering to. :)

though, this does bring up another standardish C type we should support

__float128

and __complex as pointed out by Aaron.

any idea what would be a good module to export them from?

How standard are these? Foreign.C.Types is the obvious place, but it wouldn't be a good idea for that module to contain optional parts of its interface. Cheers, Simon

Donald Bruce Stewart wrote:

simonmar:

...

On 12 May 2006 00:47, John Meacham wrote:

...

On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote:

...

On the other hand, keeping intermediate Doubles to 80-bit precision is both (a) non-portable and (b) unpredictable (the programmer doesn't know which intermediates are going to be stored in 80 bits, and turning on optimisation will probably make a difference).

Indeed, not storing the intermediate values as 80 bits is one of the 'nicer' things I was refering to. :)

though, this does bring up another standardish C type we should support

__float128

and __complex as pointed out by Aaron.

any idea what would be a good module to export them from?

How standard are these? Foreign.C.Types is the obvious place, but it wouldn't be a good idea for that module to contain optional parts of its interface.

Especially since even:

checking Haskell type for intmax_t... not supported checking Haskell type for uintmax_t... not supported

aren't universal :)

Well, yes. Any suggestions for what to do here? Make a best guess? Cheers, Simon

john:

On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote:

...

...

Especially since even:

checking Haskell type for intmax_t... not supported checking Haskell type for uintmax_t... not supported

aren't universal :)

Well, yes. Any suggestions for what to do here? Make a best guess?

What is the problem here? are intmax_t and uintmax_t not on all systems?

Well, not on OpenBSD at least. So that probably means not on Solaris or Irix or AIX either.

there is a handy autoconf macro that generates an appropriate ISO compliant inttypes.h if one doesn't exist on a system.

Ah, now that sounds like a solution. -- Don