[Libre-soc-isa] [Bug 650] write rfc for OpenPower fpr <-> gpr moves/conversions

[bugzilla-daemon at libre-soc.org]

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

--- Comment #35 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #33)
> Lkcl, I noticed you renamed the Rust conversion semantics to Java conversion
> semantics, 

yes: i find rust to be that irritating (that much hyped and obsessed over)
i'd rather we didn't mention it except in passing, where absolutely necessary.
also, if there's a language that has been around for longer and is more
commonly used i'd prefer it to be the one that's used as the reference.

also, when putting this to the OPF ISA WG they *may* flag up that java
and javascript are trademarks of oracle (javascript: 75026640),
although in these particular cases "fair use" is likely to cut it.
as in: we literally have no choice but to refer to
"the semantics of javascript" by any other means, and this is considered
acceptable under Trademark Law.

howeverrr... we maay have to invent terms (phrases) in order to refer
to these Trademarked languages to an absolute bare-minimum degree
(i.e. once, i.e. not as headings: "javascript semantics".)

turns out that rust is also trademarked
https://internals.rust-lang.org/t/rust-s-freedom-flaws/11533

and they're causing problems with it.

nope. i don't think it's safe to refer to *any* of these Trademarked
languages except once and only once.

how about:

* IEEE754 semantics as-is
* OpenPOWER semantics as-is
* saturated semantics replace java/rust
* modulo semantics (or, wrapping) replace javascript

> imho that makes it more confusing since those semantics only
> match Java for fp -> 32/64-bit integers, Java fp -> 8/16-bit integers
> instead convert to 32-bit integer and then truncate that 32-bit integer to
> 16/8-bit.

then that should have been mentioned! :)

it sounds to me like it's completely different language semantics,
which would justify a separate instruction.  or, at the very least,
an explicit mention of the difference.


> For example, Java converts 257.0 to the unsigned 8-bit value 1 (because 257
> fits in a 32-bit integer, then the top 24 bits are removed to leave the
> value 1),
> whereas Rust correctly saturates to 255.

that's *definitely* something to put into the page as being completely
different semantics

> Also, WebAssembly recently introduced saturating fp -> int conversions:
> https://webassembly.github.io/spec/core/exec/numerics.html#op-trunc-sat-u

urrr... another bandwagon. good as a reference to justify adding the
instructions though.


(In reply to Jacob Lifshay from comment #34)
> one other idea: have a variant of fp->int that sets OV/OV32 (and SO) if the
> rounded fp value doesn't fit in the destination type or the input is
> NaN...would be very useful for the other webassembly fp->int conversions
> that are specified to trap in those cases. the proposed instruction wouldn't
> trap, it'd just set OV and return the saturated result. wasm engines can
> just branch on overflow if they want.

yes, good idea.

> this would likely also be useful for fp->bigint conversions (like in python
> float->int) or fp->128-bit integer conversions so they can try the simple
> 64-bit conversion and if it sets overflow, then branch to the slow path.

yep, an exception's a bit overkill although i'm tempted to suggest it.

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