qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: bharata@linux.ibm.com, qemu-devel@nongnu.org, david@redhat.com
Subject: Re: [PATCH v2 06/10] softfloat: Implement float128_muladd
Date: Fri, 16 Oct 2020 09:55:32 -0700	[thread overview]
Message-ID: <b0625633-f8aa-a3b3-706e-74757bb215e8@linaro.org> (raw)
In-Reply-To: <87tuuuuo7d.fsf@linaro.org>

On 10/16/20 9:31 AM, Alex Bennée wrote:
>> +static void float128_unpack(FloatParts128 *p, float128 a, float_status *status)
>> +{
>> +    p->sign = extractFloat128Sign(a);
>> +    p->exp = extractFloat128Exp(a);
>> +    p->frac0 = extractFloat128Frac0(a);
>> +    p->frac1 = extractFloat128Frac1(a);
> 
> Here we are deviating from the exiting style, it would be nice if we
> could separate the raw unpack and have something like:
> 
> static const FloatFmt float128_params = {
>     FLOAT_PARAMS(15, 112)
> }
> 
> static inline FloatParts128 unpack128_raw(FloatFmt fmt, uint128_t raw)
> {
>     const int sign_pos = fmt.frac_size + fmt.exp_size;
> 
>     return (FloatParts128) {
>         .cls = float_class_unclassified,
>         .sign = extract128(raw, sign_pos, 1),
>         .exp = extract128(raw, fmt.frac_size, fmt.exp_size),
>         .frac1 = extract128_lo(raw, 0, fmt.frac_size),
>         .frac2 = extract128_hi(raw, 0, fmt.frac_size),
>     };
> }
> 
> So even if we end up duplicating a chunk of the code the form will be
> similar so when we side-by-side the logic we can see it works the same
> way.

I suppose, but unlike the smaller fp formats, we won't be able to reuse this.
Even if we pull in the x86 80-bit format and the m68k 96-bit format, there are
a number of fundamental differences.  E.g. the implicit bit

>> +        /* Add the implicit bit. */
>> +        p->frac0 |= UINT64_C(0x0001000000000000);

is not present in the x86 and m68k formats.

Finally, I'm continuing to use the existing Berkeley packing logic.  Which a
bit persnickety with where that implicit bit goes.  Our smaller formats put the
implicit bit at bit 62.


r~


  reply	other threads:[~2020-10-16 16:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 15:20 [PATCH v2 00/10] softfloat: Implement float128_muladd Richard Henderson
2020-09-25 15:20 ` [PATCH v2 01/10] softfloat: Use mulu64 for mul64To128 Richard Henderson
2020-10-15 19:08   ` Alex Bennée
2020-09-25 15:20 ` [PATCH v2 02/10] softfloat: Use int128.h for some operations Richard Henderson
2020-10-15 19:10   ` Alex Bennée
2020-09-25 15:20 ` [PATCH v2 03/10] softfloat: Tidy a * b + inf return Richard Henderson
2020-10-16  9:40   ` Alex Bennée
2020-10-16 17:04   ` Philippe Mathieu-Daudé
2020-09-25 15:20 ` [PATCH v2 04/10] softfloat: Add float_cmask and constants Richard Henderson
2020-10-16  9:44   ` Alex Bennée
2020-09-25 15:20 ` [PATCH v2 05/10] softfloat: Inline pick_nan_muladd into its caller Richard Henderson
2020-10-16 16:20   ` Alex Bennée
2020-10-16 16:36     ` Richard Henderson
2020-10-18 21:06       ` [PATCH] softfpu: Generalize pick_nan_muladd to opaque structures Richard Henderson
2020-10-19  9:57         ` Alex Bennée
2020-09-25 15:20 ` [PATCH v2 06/10] softfloat: Implement float128_muladd Richard Henderson
2020-10-16 16:31   ` Alex Bennée
2020-10-16 16:55     ` Richard Henderson [this message]
2020-09-25 15:20 ` [PATCH v2 07/10] softfloat: Use x86_64 assembly for {add, sub}{192, 256} Richard Henderson
2020-09-25 15:20 ` [PATCH v2 08/10] softfloat: Use x86_64 assembly for sh[rl]_double Richard Henderson
2020-09-25 15:20 ` [PATCH v2 09/10] softfloat: Use aarch64 assembly for {add, sub}{192, 256} Richard Henderson
2020-09-25 15:20 ` [PATCH v2 10/10] softfloat: Use ppc64 " Richard Henderson
2020-10-15 17:23 ` [PATCH v2 00/10] softfloat: Implement float128_muladd Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0625633-f8aa-a3b3-706e-74757bb215e8@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=bharata@linux.ibm.com \
    --cc=david@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).