Thanks. I think the decision here is to do the safe thing and mask the return results ourselves, since it's only one extra insn. This won't make it into 5.02, tho. J | -----Original Message----- | From: Sigbjorn Finne [mailto:sof@galconn.com] | Sent: Saturday, September 08, 2001 4:27 PM | To: Julian Seward (Intl Vendor) | Cc: partain@dcs.gla.ac.uk; Ashley Yakeley; GHC List | Subject: Re: GHC FFI Return Type Bug | | | Here's another data point on this topic - I asked around | inside of MS, and the consensus is that the contents of the | unused portions of EAX is undefined upon return (upper 3 | bytes for byte-sized return values, upper 2 for 16-bit | values). This is invariant of x86 calling convention on Win32 | (cdecl,stdcall,fastcall). Still no known doc/spec which | spells this out. | | ==> GHC's NCG and C backends need to know the sizes of the | unboxed Ints and Words involved in CCalls to generate correct code. | | --sigbjorn | | ----- Original Message ----- | From: "Sigbjorn Finne" | To: "Julian Seward (Intl Vendor)" | Cc: ; "Ashley Yakeley" | ; "GHC List" | Sent: Tuesday, August 07, 2001 16:00 | Subject: Re: GHC FFI Return Type Bug | | | > | > "Julian Seward (Intl Vendor)" writes: | > > | > > | > char fooble ( ... ) | > > | > { | > > | > return 'z'; | > > | > } | > > | > | > > | > on an x86, 'z' will be returned at the lowest 8 bits in %eax. | > > | > What I | > > | > > | > don't know is, is the C compiler obliged to clear the | upper 24 | > > | > bits | > > of | > > | > %eax, or does that onus fall on the callee? | > > | | > > | Yes, the callee is required to narrow <expr> in 'return | <expr>;' | > > | to fit that of the specified return type -- see 9.8 of Harbison | > > | and Steele. | > > | | > ... | > > So we don't need to worry about doing the masking on the Haskell | > > side, right? | > > | > | > Yes, that's been my understanding. But, as Carl Witty | rightly points | > out, a distinction can be made between narrowing down the | result value | > and the transmission of the narrowed result back to the caller. | > | > Carl's example doesn't fully convince me though, since the masking | > done in the code for "g" is patently redundant ("f" does | mask out the | > upper 3 bytes of %eax upon return). However, the example | given in the | > original bug report can be made to emit code that doesn't | mask %eax | > (via "gcc-2.96 -O" on an i686-pc-linux). Another data point is that | > MSVC also emits code that masks. | > | > So, indications are that you actually do need to mask on an | x86, but | > I've got no supporting documentation. If anyone is able to | dig up more | > info and/or know someone that could answer this one decisively, I'd | > interested to hear of their findings. | > | > --sigbjorn | > | > btw, the document specifying the x86 ABI, located via | > | > http://uwsg.iu.edu/hypermail/linux/kernel/0011.1/0596.html | > | > , doesn't cover this as far as I've been able to tell. | > | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | |