Bug 111 - FCVT unsigned/signed char/short/int/long (8/16/32/64) to FP16/32/64 needed
Summary: FCVT unsigned/signed char/short/int/long (8/16/32/64) to FP16/32/64 needed
Status: PAYMENTPENDING FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: ALU (including IEEE754 16/32/64-bit FPU) (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 48
  Show dependency treegraph
 
Reported: 2019-07-16 13:07 BST by Luke Kenneth Casson Leighton
Modified: 2021-04-20 14:54 BST (History)
2 users (show)

See Also:
NLnet milestone: NLnet.2019.02
total budget (EUR) for completion of task and all subtasks: 125
budget (EUR) for this task, excluding subtasks' budget: 125
parent task for budget allocation: 48
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
"lkcl"={amount=125, paid=2019-07-30}


Attachments
patch to sfpy to add int-fp conversion routines (4.73 KB, patch)
2019-07-17 09:20 BST, Luke Kenneth Casson Leighton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2019-07-16 13:07:53 BST
conversion from unsigned and signed 8/16/32/64 integers to
FP16, FP32 and FP64 are all needed.
Comment 1 Luke Kenneth Casson Leighton 2019-07-17 07:37:36 BST
>>> from sfpy import Float16, Float32
>>> y = Float16(10)
>>> y
Float16(5.960464477539062e-07)
Comment 2 Jacob Lifshay 2019-07-17 08:09:56 BST
(In reply to Luke Kenneth Casson Leighton from comment #1)
> >>> from sfpy import Float16, Float32
> >>> y = Float16(10)
> >>> y
> Float16(5.960464477539062e-07)

that looks correct to me, docs for convenience: 
"""Given an int, create a Float16 from the bitpattern represented by
that int. Otherwise, given some value, create a Float16 by rounding
float(value).
"""
Comment 3 Luke Kenneth Casson Leighton 2019-07-17 08:18:15 BST
*smacks-forehead* - of course.  i forgot about that, was looking
for a way to do int-to-float conversion.

am going to modify sfpy (created the repo on git.libre-riscv.org
already) to expose the i32_to_f16 (etc) functions from sfpy.float.

l.
Comment 4 Luke Kenneth Casson Leighton 2019-07-17 09:20:02 BST
Created attachment 18 [details]
patch to sfpy to add int-fp conversion routines
Comment 5 Luke Kenneth Casson Leighton 2019-07-18 14:46:37 BST
https://git.libre-riscv.org/?p=ieee754fpu.git;a=commitdiff;h=6e672a1a16c00f8d870b50b3de9686bc935db44f

added support for larger uint down to smaller FP, this is likely
to be uint32 or uint64 down to FP16, however uint64 to FP32 would
hit the reduction point as well.

seems to be ok - currently running through 20,000 tests on each of
        test_int_pipe_ui64_f32()
        test_int_pipe_ui32_f16()
        test_int_pipe_ui64_f16()
        test_int_pipe_ui16_f32()
        test_int_pipe_ui16_f64()
        test_int_pipe_ui32_f64()
Comment 6 Jacob Lifshay 2019-07-18 14:50:36 BST
for testing u16/i16/f16 as inputs, it may be better to go through all cases, since there aren't that many
Comment 7 Luke Kenneth Casson Leighton 2019-07-18 15:38:57 BST
(In reply to Jacob Lifshay from comment #6)
> for testing u16/i16/f16 as inputs, it may be better to go through all cases,
> since there aren't that many

yeh that sounds sensible.  presently i am doing only 17 bit random on uint32/64 to fp16, otherwise the probability of generating numbers that fit within range is.. well... negligeable.  everything gets converted to INF.

full coverage is a good idea, and achievable.
Comment 8 Luke Kenneth Casson Leighton 2019-07-19 11:03:18 BST
https://git.libre-riscv.org/?p=ieee754fpu.git;a=commitdiff;h=fca1093babd57f9cba2e4b1093a8f97dd0450728

first example usage of the new FPPipeContext "operator".  it's pretty
basic: no "tidiness" class that helps actually identify it as such,
it's just straight "set op_wid=1" then:

with m.If(self.i.ctx.op[0]):
    # start doing signed decode
with m.Else():
    # start doing unsigned decode

pretty basic, and i can confirm that the ctx.op, like ctx.muxid, is
properly passed down the pipeline chain.

i might just add in a completely new class, just to see if that also works
(it should).

preliminary run on signed-to-FP works, i'll do some more comprehensive
unit tests, now.
Comment 9 Luke Kenneth Casson Leighton 2019-07-19 13:46:11 BST
https://git.libre-riscv.org/?p=ieee754fpu.git;a=commitdiff;h=d93975e80a3ae0f2b38d307ae91336095303cc4b

int32 and uint32 -> fp32 done - a bit of weirdness detected, however
it works.  ran enough tests here to consider this one "done".