You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Has anybody had a need for such a routine? I thought of putting this question on discourse but did not want to clutter things up. Not sure the reach I will achieve by posting an issue by let's try it anyway.
Technically, a compiler is not IEEE 754 compliant unless it supports this operation. It is a basic, i.e. fundamental, IEEE 754 arithmetic operation, not a library routine even though it might look like it is normally implemented as such (and indeed it might even be on something like X86-64. Some newer ISAs jabe a single instruction to do it. As an operation ranks up there with the arithmetic operations +, -, / and * and is part of the family of operations which messes or otherwise with the sign bit when making a duplicate or clone of the (primary) operand:
copy y to x, i.e. x := y
negate x, i.e. -x
absolute value of x, i.e. abs(x)
I implement it as a routine and quite happy with the approach. I am curious if I should share what I have if there is a demand, or advocate for the LLVM built-in to be accessible which I guess means putting a new primitive into the compiler: See
https://llvm.org/docs/LangRef.html
I would assume that the preferred path is to use the LLVM built-in.
I can live with what I have forever so I am not asking that anything change but I thought I would just throw this into the mix of low priority tasks. This is not a heavy use routine or a performance killer.
For something like an x86-64, you can come up with a pretty good library routine of varying degrees of complexity and performance and readability using the transmute() feature. For
something like a RISC-V and (maybe) POWER architecture, you might want to use the built-in to get access to the single machine instruction which does the same job. Not sure about ARM.
The text was updated successfully, but these errors were encountered:
In the absence of a primitive for this operation, here is a slightly sub-optimal implementation, one which highlights the use of the transmute() method:
inlineproc copysign(x :real(?w), y :real(w))
{
const _x = x.transmute(uint(w));
const _y = y.transmute(uint(w));
// compute the exclusive OR but only look// i.e. the result of the most significant bit, the// negative bit, or what some call the sign bitreturnif ((_x ^ _y) >> (w -1)) ==0then x else-x;
}
Has anybody had a need for such a routine? I thought of putting this question on discourse but did not want to clutter things up. Not sure the reach I will achieve by posting an issue by let's try it anyway.
Technically, a compiler is not IEEE 754 compliant unless it supports this operation. It is a basic, i.e. fundamental, IEEE 754 arithmetic operation, not a library routine even though it might look like it is normally implemented as such (and indeed it might even be on something like X86-64. Some newer ISAs jabe a single instruction to do it. As an operation ranks up there with the arithmetic operations +, -, / and * and is part of the family of operations which messes or otherwise with the sign bit when making a duplicate or clone of the (primary) operand:
I implement it as a routine and quite happy with the approach. I am curious if I should share what I have if there is a demand, or advocate for the LLVM built-in to be accessible which I guess means putting a new primitive into the compiler: See
I would assume that the preferred path is to use the LLVM built-in.
I can live with what I have forever so I am not asking that anything change but I thought I would just throw this into the mix of low priority tasks. This is not a heavy use routine or a performance killer.
For something like an x86-64, you can come up with a pretty good library routine of varying degrees of complexity and performance and readability using the transmute() feature. For
something like a RISC-V and (maybe) POWER architecture, you might want to use the built-in to get access to the single machine instruction which does the same job. Not sure about ARM.
The text was updated successfully, but these errors were encountered: