| Summary: | FCVT unsigned/signed char/short/int/long (8/16/32/64) to FP16/32/64 needed | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | ALU (including IEEE754 16/32/64-bit FPU) | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | PAYMENTPENDING FIXED | ||
| Severity: | enhancement | CC: | libre-soc-bugs, programmerjake |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| NLnet milestone: | NLnet.2019.02.012 | 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}
|
|
| Bug Depends on: | |||
| Bug Blocks: | 48 | ||
| Attachments: | patch to sfpy to add int-fp conversion routines | ||
|
Description
Luke Kenneth Casson Leighton
2019-07-16 13:07:53 BST
>>> from sfpy import Float16, Float32
>>> y = Float16(10)
>>> y
Float16(5.960464477539062e-07)
(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). """ *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. Created attachment 18 [details]
patch to sfpy to add int-fp conversion routines
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() for testing u16/i16/f16 as inputs, it may be better to go through all cases, since there aren't that many (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. 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. 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". |