Skip to content

[SYCL] Add external arbitrary floating point functions #2114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 17, 2020

Conversation

mlychkov
Copy link
Contributor

@mlychkov mlychkov commented Jul 14, 2020

Add support of functions that operate on arbitrary precision floating
point numbers. This datatype and its corresponding operations can be
useful on targets that can take advantage of narrower representation
such as FPGAs.

Arbitrary precision floating point numbers are represented using
arbitrary precision integers (_ExtInt(N)). Additional parameters are:

  • E: represents the number of exponent bits
  • M: represents the number of mantissa bits
    The total width of the type is E+M+1 where the last bit is used to
    represent the sign. The data layout is shown below:
    [ S (sign bit) ][ E (Exponent) ][ M (Mantissa) ]

The width of the data (E+M+1) is encoded with the width of the
arbitrary precision integer variable. Mantissa (namely M) is encoded
within each of the signature of the operations. Exponent values
(namely E) are inferred from the width of corresponding variable.

Usage example:
_ExtInt(Wa) a;
_ExtInt(Wb) b;
_ExtInt(Wout) res = __spirv_ArbitraryFloatAddINTEL<Wa, Wb, Wout>(a, Ma, b, Mb, Mout);

Signed-off-by: Mikhail Lychkov [email protected]

@mlychkov mlychkov requested a review from a team as a code owner July 14, 2020 17:37
@mlychkov mlychkov requested a review from againull July 14, 2020 17:37
Add support of functions that operate on arbitrary precision floating
point numbers. This datatype and its corresponding operations can be
useful on targets that can take advantage of narrower representation
such as FPGAs.

Arbitrary precision floating point numbers are represented using
arbitrary precision integers (_ExtInt(N)). Additional parameters are:
* _E_: represents the number of exponent bits
* _M_: represents the number of mantissa bits
The total width of the type is `E+M+1` where the last bit is used to
represent the sign. The data layout is shown below:
`[ S (sign bit) ][ E (Exponent) ][ M (Mantissa) ]`

The width of the data `(E+M+1)` is encoded with the width of the
arbitrary precision integer variable. Mantissa (namely `M`) is encoded
within each of the signature of the operations. Exponent values
(namely `E`) are inferred from the width of corresponding variable.

Usage example:
  _ExtInt(Wa) a;
  _ExtInt(Wb) b;
  _ExtInt(Wout) res = __spirv_ArbitraryFloatAddINTEL<Wa, Wb, Wout>(a, Ma, b, Mb, Mout);

Signed-off-by: Mikhail Lychkov <[email protected]>
@mlychkov mlychkov force-pushed the private/mlychkov/add_ihs_float_built-ins branch from e03ae23 to 57f58b5 Compare July 14, 2020 17:51
Copy link
Contributor

@againull againull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there are much more functions for floating point than for fixed point. Is this intentional? or are there plans to support missing functions for fixed point?

@bader bader merged commit 0a8e7d3 into intel:sycl Jul 17, 2020
@mlychkov
Copy link
Contributor Author

Looks like there are much more functions for floating point than for fixed point. Is this intentional? or are there plans to support missing functions for fixed point?

I think that @GarveyJoe better knows about that?

@mlychkov mlychkov deleted the private/mlychkov/add_ihs_float_built-ins branch July 17, 2020 11:20
@MrSidims
Copy link
Contributor

Looks like there are much more functions for floating point than for fixed point. Is this intentional? or are there plans to support missing functions for fixed point?

It is intentional, variety of functions follows https://hlslibs.org/ declarations.

@keryell
Copy link
Contributor

keryell commented Jul 17, 2020

It is intentional, variety of functions follows hlslibs.org declarations.

Interesting. I hope the SYCL implementation will be in modern C++ instead...

@MrSidims
Copy link
Contributor

It is intentional, variety of functions follows hlslibs.org declarations.

Interesting. I hope the SYCL implementation will be in modern C++ instead...

I have a feeling that yes :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants