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" <sof@galconn.com> | To: "Julian Seward (Intl Vendor)" <v-julsew@microsoft.com> | Cc: <partain@dcs.gla.ac.uk>; "Ashley Yakeley" | <ashley@semantic.org>; "GHC List" <glasgow-haskell-users@haskell.org> | Sent: Tuesday, August 07, 2001 16:00 | Subject: Re: GHC FFI Return Type Bug | | | > | > "Julian Seward (Intl Vendor)" <v-julsew@microsoft.com> 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 | |
Hi! On Mon, 10 Sep 2001, Julian Seward (Intl Vendor) wrote:
[..] extra insn. This won't make it into 5.02, tho.
Speaking of 5.02 . Could someone enlighten us that are not on the CVS mailing list about the state of things? When can we expect the release? /Josef
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.
So GHC's Int/Word implementation is different from Hugs'? Hugs represents Word8 (say) by a 32 bit int but doesn't guarantee that the top 24 bits are all zero. Instead we either use an 8-bit operation when we operate on a word8 or we mask the arguments and use the 32-bit operation (for *, /, ==, etc.) or we don't mask and use the 32-bit operation (works for and, or, +, and some of the shifts) -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (3)
-
Alastair David Reid -
Josef Svenningsson -
Julian Seward (Intl Vendor)