[Libre-soc-bugs] [Bug 230] Video opcode development and discussion

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=230

--- Comment #75 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #74)

> Actually, RISC-V has both raw bitwise fpr <-> gpr moves (fmv.d.x and
> friends) and converting fpr <-> gpr moves (fcvt.d.lu and friends). I think
> we should have both converting moves and bitwise moves, especially because
> converting is easily >90% of the fpr <-> gpr moves, so a conversion taking
> one combined gpr -> fpr and convert instruction rather than two (gpr -> fpr
> bitwise move and a separate fpr -> fpr int -> fp instruction) is better.

yep makes sense. these do exist in v3.0B: they all target the FP regfile with
integer values.

> The scalar conversion instructions should support u32/u64/i32/i64 <->
> f32/f64. We need at least truncating conversion for fp -> int and roundeven
> for int -> fp, though supporting all of roundeven, floor, ceil, and trunc
> would be better.

they're all here - v3.0B p159 and in... err a section E.2 p642 which doesn't
exist is supposed to contain examples.  fcfid etc.

anyway, yes, frin frip friz frim (p166) are definitely for FP-to-FP
and map to round trunc ceil floor.

> fp -> int conversions should convert NaN to 0 and saturate for
> +-infinity/too-big-to-fit values -- that's the behavior needed for Rust,
> Java, LLVM's fptosi.sat/fptoui.sat intrinsics, and for OpenCL and Direct3D.
> IDK if that matches the other OpenPower conversion instructions (it doesn't
> match on x86, which makes conversions on x86 take more instructions in many
> cases).

can you double-check? p159 section 4.6.7

-- 
You are receiving this mail because:
You are on the CC list for the bug.