qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [RFC PATCH 00/30] v8.2 half-precision support (work-in-pr


From: Richard Henderson
Subject: Re: [Qemu-arm] [RFC PATCH 00/30] v8.2 half-precision support (work-in-progress)
Date: Mon, 16 Oct 2017 19:34:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 10/13/2017 09:24 AM, Alex Bennée wrote:
> SoftFloat
> =========
> 
> Previously I had pondered if switching to the newer SoftFloat3 would
> be a worthwhile. While the upstream project is certainly open to
> accepting patches it would be a slow process given the changes we've
> made over the years. As a result I've decided to stick with expanding
> our current code.
> 
> Most of the helpers have been done fairly mechanically by copying the
> float32 equivalent, filing off the 32's, replacing with 16's and
> adjusting the constants appropriately (min/max exp, NaNs etc). I've
> done this in conjunction with reading the SoftFloat3 code as a sanity
> check although in places the design is a little different.

I think we need a re-think of the approach here.

For the most part, the code would be sharable *if* our internal representation
between float32 and float16 were identical.  So that all that's different are
unpacking and repacking routines at the beginning and end.

Unfortunately, the existing float32 code does lots of random unpacking in the
middle of other classification.  Fixing that would be a prerequisite.  Is it
worth upending our code base to make this happen?

Failing that, we need to stop using magic numbers, since so many of them were
wrong.  We need names for these.  We can start with float16 and then later
backport those numbers into larger formats.


r~



reply via email to

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