hlslibs / ac_types Goto Github PK
View Code? Open in Web Editor NEWAlgorithmic C Datatypes
License: Apache License 2.0
Algorithmic C Datatypes
License: Apache License 2.0
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
Line 49 in cccc8bc
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.
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).
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
.
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.
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~
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.
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]
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 ) {
| ^~~~~~~~
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
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
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
);
}
Line 212 in 1ed7f2d
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>
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.
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" ?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.