On 20 July 2012 23:48, Catalin Patulea catal...@google.com wrote:
On Tue, Jul 17, 2012 at 10:49 AM, Catalin Patulea catal...@google.com wrote:
the Windows build would not put the fields 'mantissa' and
'one' in the same 64 bit word, it would insert a padding bit.
Since floatx80 is not part of
On Tue, Jul 17, 2012 at 10:49 AM, Catalin Patulea catal...@google.com wrote:
the Windows build would not put the fields 'mantissa' and
'one' in the same 64 bit word, it would insert a padding bit.
Since floatx80 is not part of a Windows API (in fact, it's not part of
any API, it's in a
On 17 July 2012 03:24, Catalin Patulea catal...@google.com wrote:
I'm just sending this in as a draft for now. There are two outstanding issues:
1) What is the recommended type for bitfields? A quick grep shows inconsistent
usage of unsigned int/signed int/uintNN_t across the codebase. Note
On Tue, Jul 17, 2012 at 8:23 AM, Peter Maydell peter.mayd...@linaro.org wrote:
I think our current position is don't use bitfields for anything that
has to match an externally defined layout. This is because on Windows
we have to compile with -mms-bitfields [for compatibility with Windows
I'm just sending this in as a draft for now. There are two outstanding issues:
1) What is the recommended type for bitfields? A quick grep shows inconsistent
usage of unsigned int/signed int/uintNN_t across the codebase. Note that
mantissa must be 63 bits so int won't do on either 32 or 64-bit
On Mon, Jul 16, 2012 at 10:24 PM, Catalin Patulea catal...@google.com wrote:
I don't think FPREM
can ever lose precision with respect to its operands.
Sorry, this should be, FPREM can't _gain_ precision with respect to
its operands.
Think of the binary representation with infinite precision,
