[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 00/15] softfloat: alternate conversion of float128_addsub

From: Richard Henderson
Subject: Re: [RFC PATCH 00/15] softfloat: alternate conversion of float128_addsub
Date: Wed, 21 Oct 2020 10:53:28 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 10/21/20 10:46 AM, Alex Bennée wrote:
>> This layout, with the big-endian ordering, means that storage
>> can be shared between them, just by ignoring the least significant
>> words of the fraction as needed.  Which may make muladd more
>> understandable.
> Would the big-endian formatting hamper the compiler on x86 where it can
> do extra wide operations?

Well, you couldn't just use Int128 in the structure.  But you could write the
helpers via int128_make128/getlo/gethi, which would still get the compiler

>> However, the big-endian word ordering means that Int128
>> cannot be used directly; so a set of wrappers are needed.
>> If added the Int128 routine just for use here, then it's
>> probably easier to bypass Int128 and just code it here.
> Are you talking about all our operations? Will we still need to#ifdef
> CONFIG_INT128 in the softfloat code?

If we decline to put the operation into qemu/int128.h, because they're not
generally useful, then yes, we may put those ifdefs into our softfloat code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]