hlslibs / ac_types Goto Github PK

Hi, David and @andres-takach ,

I'm wondering why class ac_fixed does not provide overloaded operator=(). Is there any special considerations or limitations by which ac_types designers decides not to overload operator=()?

Thanks,
Peng

When compiling with g++ (GCC) 12.2.0, ac_bitref functions and ac_int::operator[] will produce a deprecated copy warning. Here an example on how to reproduce them:

#include "ac_int.h"

int main() {
  ac_int<3,false> a;
  a[0] = 1;
  return 0;
}

Compiled with g++ -Wall -Wextra -std=c++17 -I . t.cc

Produces:

ac_int.h: In instantiation of 'ac_int<W, S>::ac_bitref ac_int<W, S>::operator[](int) [with int W = 3; bool S = false]':
t.cc:5:6:   required from here
ac_int.h:2603:12: warning: implicitly-declared 'constexpr ac_int<3, false>::ac_bitref::ac_bitref(const ac_int<3, false>::ac_bitref&)' is deprecated [-Wdeprecated-copy]
 2603 |     return bvh;
      |            ^~~
ac_int.h:2588:22: note: because 'ac_int<3, false>::ac_bitref' has user-provided 'ac_int<W, S>::ac_bitref ac_int<W, S>::ac_bitref::operator=(const ac_int<W, S>::ac_bitref&) [with int W = 3; bool S = false]'
 2588 |     inline ac_bitref operator = ( const ac_bitref &val ) {
      |                      ^~~~~~~~
ac_int.h: In instantiation of 'ac_int<W, S>::ac_bitref ac_int<W, S>::ac_bitref::operator=(int) [with int W = 3; bool S = false]':
t.cc:5:10:   required from here
ac_int.h:2582:15: warning: implicitly-declared 'constexpr ac_int<3, false>::ac_bitref::ac_bitref(const ac_int<3, false>::ac_bitref&)' is deprecated [-Wdeprecated-copy]
 2582 |       return *this;
      |               ^~~~
ac_int.h:2588:22: note: because 'ac_int<3, false>::ac_bitref' has user-provided 'ac_int<W, S>::ac_bitref ac_int<W, S>::ac_bitref::operator=(const ac_int<W, S>::ac_bitref&) [with int W = 3; bool S = false]'
 2588 |     inline ac_bitref operator = ( const ac_bitref &val ) {
      |                      ^~~~~~~~

First of all, thanks for a really nice fixed-point library!

Is it possible to change all integer types to use explicit sizes, i.e int32_t and uint32_t? The reason is that I'm running on 64 bit systems, and thus all ac_types are twice as large as they have to be.

The definition of SAT_SYM in the PDF documentation states the following:

For unsigned, treat as SAT.
For signed: an overflow or number is MIN set to the closest of.

The meaning of this is unclear. Could someone please elaborate on this?

Thanks!

All other tags are using the v prefix for tags, just 3.9.2 doesn't: https://github.com/hlslibs/ac_types/tags

It would be nice if you could set v3.9.2 in addition to 3.9.2.

e.g., ac_float operator +=(const AC_FL(2) &op2):

https://github.com/hlslibs/ac_types/blob/master/include/ac_float.h#L656

returns

 error: control reaches end of non-void function
      [-Werror,-Wreturn-type]

I'm writing some simulator code to do some bit-accurate verification, and to simplify my work I hope to use ac_types as my arithmetic library. I need to transform some raw bytes into ac data types, but only ac_int provides such things like bit_fill_xxx, no similar methods for ac_float.

There is a workaround that I first convert these raw bytes into C-float, then convert them into ac_float, but consider following code:

// tested on latest version 3.7.2
#include <ac_float.h>
#include <iostream>
#include <cstdio>
using namespace std;
int main() {
float a = 3.141592653589793;
auto b = ac_float<23, 1, 8>(a);
float c = b.to_float();
printf("0x%08x\t%.7f\n", *(unsigned *)&a, a);
printf("0x%08x\t%.7f\n", *(unsigned *)&c, c);
}

The output is:

0x40490fdb      3.1415927
0x40490fd8      3.1415920

There is precision loss when converting to and from C-float type.
So is there any other way to meet my needs? Thank you~

When trying to compile my code on macOS, using clang compiler, I get the following error :

ac_types-stable/include/ac_int.h:2501:11: error: no viable overloaded '|='
      res |= h;
      ~~~ ^  ~
ac_types-stable/include/ac_int.h:2205:11: note: candidate template ignored: could not match 'ac_int<W, S>' against 'int'
  ac_int &operator |= ( const ac_int<W2,S2> &op2 ) {
          ^
ac_types-stable/include/ac_int.h:2500:11: error: no viable overloaded '<<='
      res <<= 4;
      ~~~ ^   ~
ac_types-stable/include/ac_fixed.h:971:7: note: in instantiation of member function 'ac_int<29, false>::bit_fill_hex' requested here
    x.bit_fill_hex(str);
      ^
utils/cpp/src/MyUtils.cpp:220:7: note: in instantiation of member function 'ac_fixed<29, 29, false, AC_TRN, AC_SAT>::bit_fill_hex' requested here
    a.bit_fill_hex(ss.str().c_str());
      ^
ac_types-stable/include/ac_int.h:2251:11: note: candidate template ignored: could not match 'ac_int<W2, true>' against 'int'
  ac_int &operator <<= ( const ac_int<W2,true> &op2 ) {
          ^
ac_types-stable/include/ac_int.h:2259:11: note: candidate template ignored: could not match 'ac_int<W, false>' against 'int'
  ac_int &operator <<= ( const ac_int<W2,false> &op2 ) {
          ^

A possible fix would be this :

in ac_int.h lines 2500, 2501 change from :

res <<= 4;¬
res |= h;¬

to

res <<= ac_int<W,S>(4);
res |= ac_int<W,S>(h);

Please review. Thanks.

I'm slightly confused about the definition of the sign_conj function in ac_complex. According to the PDF docs, it does the following:

sign_conj() returns (sign(real), sign(imag))) as an ac_complex<ac_int<2,true> >

However, the definition returns the following:

  ac_complex< ac_int<2,true> > sign_conj() const {
    return ac_complex< ac_int<2,true> >(
      _r ? (_r < 0 ? -1 : 1) : 0,
      _i ? (_i < 0 ? 1 : -1) : 0
    );
  }

Based on the code and name, it returns the sign of the conjugate. Can someone please confirm if this is correct, and if so, perhaps update the docs, or let me know so I can send a PR to update the wording, something along the lines of:

returns (sign(real(conj())), sign(imag(conj())))) as an ac_complex<ac_int<2,true>

I am observing that the ac_fixed sizes change when I use unsigned 32 bits.

Here is an example:

ac_fixed<32, 16, true> x = 3.14;
std::cout << "Sizeof: " << sizeof(x) << " bytes\n";
[Out] Sizeof: 4 bytes

ac_fixed<32, 16, false> x = 3.14;
std::cout << "Sizeof: " << sizeof(x) << " bytes\n";
[Out] Sizeof: 8 bytes

This happens in version AC Datatypes v4.4.1

I'm not sure this is a bug, but I did find this effect strange, forcing me to change my code to accommodate this.

Compilation Info:

* Oracle Linux Server release 7.9
* g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44.0.3)
* g++ example.cpp -o run -I ../include/ -O3 -Werror -Wall -g -std=c++11

ac_std_float has some compiler warnings with clang-9.

For example, with -Wbitwise-conditional-parentheses and -Wunused-variable:
./ac_types/include/ac_std_float.h:429:23: error: unused variable 'rnd' [-Werror,-Wunused-variable]
static const bool rnd = QFX!=AC_TRN && QFX!=AC_TRN_ZERO;

...

./ac_types/include/ac_std_float.h:790:51: error: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Werror,-Wbitwise-conditional-parentheses]
int exp = ( (e1_lt_e2 & !op2_zero) | op1_zero ? op2_e_b : op1_e_b);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
./ac_types/include/ac_std_float.h:790:51: note: place parentheses around the '|' expression to silence this warning
int exp = ( (e1_lt_e2 & !op2_zero) | op1_zero ? op2_e_b : op1_e_b);
^
( )
./ac_types/include/ac_std_float.h:790:51: note: place parentheses around the '?:' expression to evaluate it first
int exp = ( (e1_lt_e2 & !op2_zero) | op1_zero ? op2_e_b : op1_e_b);

It would be really nice if this new header could be warnings-clean under clang, as disabling warnings transitively affects every translation unit that includes the header, and we've found these warnings to be particularly effective at keeping code bug-free.

Below is an example to show the division difference between signed ac_fixed and double:

#include "ac_types/include/ac_fixed.h"

int main()
{
    ac_fixed<40,30,true> num = -46800;
    ac_fixed<40,30,true> den = 2136;
    ac_fixed<40,30,true> q = num / den;

    std::cout << "division using ac_fixed division = " << q.to_string(AC_BIN) << ", " << q << std::endl;

    q = static_cast<double>(num.to_int64())/den.to_int64();

    std::cout << "division using double   = " << q.to_string(AC_BIN) << ", " << q << std::endl;

   return 0;
}

The output of the above code snippet.

division using ac_fixed = 0b101010.0001011101, -21.9091796875
division using double   = 0b101010.0001011100, -21.91015625

There is a small typo 'syntheiss' in this line

Hi,
I think there might be an issue in:

virtual void write(FILE* f) {
    // The function to_string(AC_BIN) returns a string with the zero-radix prefix (i.e. "0b").
    // Strip that prefix off because compose_line will add its own.
    std::fprintf(f, "%s", compose_line(((ac_int<W,false>)object).to_string(AC_BIN,true).substr(3)).c_str());
    old_value = object;
  }

That substr(3) : shouldn't that be a 2 instead that would skip "0b" ?

ac_ieee32_float32::add returns a result with wrong sign for some combinations of operand values if AC_RND_INF rounding mode is used. The following program

#include "ac_std_float.h"
#include <cstdint>
#include <cstring>
#include <iomanip>
#include <iostream>

int main() {
    std::uint32_t au = 0x380470edu;
    std::uint32_t bu = 0x447fffffu;

    float af, bf;
    std::memcpy(&af, &au, sizeof af);
    std::memcpy(&bf, &bu, sizeof bf);

    ac_ieee_float32 a = af;
    ac_ieee_float32 b = bf;
    ac_ieee_float32 c = a.add<AC_RND_INF, false>(b);

    std::cout << std::setprecision(9) << a << " + " << b << " = " << c << std::endl;
}

prints

3.15764228e-05 + 1023.99994 = -1024

which is obviously wrong. It seems that the code that determines sign of result has bug.

Compilers used: MinGW-w64 GCC 8.0.1 x86_64 and MSVC 2019 (v16.7.2).

GCC's UB sanitizer complains about a negative left shift which is in fact UB. The following patch solves the issue:

--- a/include/ac_int.h
+++ b/include/ac_int.h
@@ -1028,7 +1028,7 @@ namespace ac_private {
     }
   }
   template<> inline void iv_shift_l<1,1>(const int *op1, unsigned op2, int *r) {
-    r[0] = op2 < 32 ? op1[0] << op2 : 0;
+    r[0] = op2 < 32 ? static_cast<unsigned int>(op1[0]) << op2 : 0u;
   }
   template<> inline void iv_shift_l<2,1>(const int *op1, unsigned op2, int *r) {
     Ulong vop1 =

Note other specialization of iv_shift_l do implement the missing cast which suggests this was overlooked only in this particular one.

Hi,
I am getting a runtime exception when I try to trace the ac_type signal. I really appreciate if I could get some assistance or examples of tracing using the ac_types used in systemC context.

SystemC version: 2.3.3
ac_types version: 4.6.1
Compilers tried : MSVC 2019, gcc 9.3.0

#include "systemc.h"
#include "ac_int.h"
#include "ac_sc.h"

int sc_main(int argc, char *argv[])
{
std::cout << "Starting DUT Simulation\n";
// Open VCD file
sc_trace_file *trace_file = sc_create_vcd_trace_file("test");

ac_int<14, false> ac_test;
sc_uint<14> sc_test;

ac_test = 10;
sc_test = 10;

sc_trace(trace_file, ac_test, "test.ac_test"); // exception goes away if I comment this line.
sc_trace(trace_file, sc_test, "test.sc_test");

sc_start(10, SC_NS);
sc_close_vcd_trace_file(trace_file);

std::cout << "SIM Complete";
return 0;

}

Here is the exception:
Exception thrown at 0x00007FF666D15972 in ac_type_tests.exe: 0xC0000005: Access violation writing location 0x0000000000000000.