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
|
|
