Re: ambiguous operators with SC_INCLUDE_FX

Philipp/David - will this also handle the original situation where I observed this issue (typing from memory) where I had:

sc_fixed<8,2,...> A,B,C,D;

...

A = B + C * D;

Today you have to code the math as

A = B + (sc_fixed<8,2,...>)(C*D);

or

A = C*D;
A = B+A;

which is rather silly, especially if you are playing with data types and modes of a large numerically intensive program to see their effect on precision - you have to insert casts, and change the declaration and the casts throughout the program, or break your program into a series of simple expressions, both which are error prone and ugly and a bit embarrassing...

Mac

----- Original Message -----
From: owner-systemc-p1666-technical@eda.org <owner-systemc-p1666-technical@eda.org>
To: Bishnupriya Bhattacharya
Cc: systemc-p1666-technical@eda.org <systemc-p1666-technical@eda.org>; David Long <david.long@doulos.com>
Sent: Fri Nov 26 03:48:32 2010
Subject: Re: ambiguous operators with SC_INCLUDE_FX

Bishnupriya,

to me, the root cause of the ambiguity issue is the implicit conversion
from the native data-types to sc_fxval(_fast). The constructors are not
'explicit', therefore these classes get in our way in this case. But
for the sake of backwards compatibility, we can't change
sc_fxval(_fast), I suppose.

  So we have to add operators to sc_(u)int_base for the builtin types,
in case of SC_INCLUDE_FX defined. I doubt, that this leads to
performance degradation, if these operators are defined inline. Why
should a compiler inline the conversion function, but not the operator?

  For the LRM, I think no changes are required in that case. The LRM
simply lists the possible expressions for all combinations. It's up to
the implementation to get this right.

So I see two options here:
 1) change sc_fxval(_fast) in the LRM to have 'explicit' constructors
    from the builtin (integral) types (cleaner, but with slight
    backwards comp. issues)
 2) add operators to sc_(u)int_base, when SC_INCLUDE_FX is defined
    and keep the LRM as it is now

Greetings from Oldenburg,
  Philipp

On 26/11/10 05:59, Bishnupriya Bhattacharya wrote:
> David, All,
>
> In SystemC, if the SC_INCLUDE_FX macro is defined then arithmetic operations with sc_int/sc_uint throw up compile errors because of ambiguity with operators defined for sc_fxval and sc_fxval_fast.
>
> The issue is demonstrated with the simple program below.
>
> #define SC_INCLUDE_FX
> #include <systemc.h>
>
> int sc_main(int argc, char * argv[])
> {
> sc_int<20> x, y;
>
> #ifdef WORK_AROUND
> y = (sc_int<20>)x + (sc_int<20>)y;
> #else
> y = x + 1; <----------------- compile error on this line
> #endif
>
> sc_start(25);
> return 0;
> }
>
> "$TESTDIR/simple.cpp", line 11: error: more than
> one operator "+" matches these operands:
> built-in operator "arithmetic + arithmetic"
> function "sc_dt::operator+(const sc_dt::sc_int_base &, const
> sc_dt::sc_fxval &)"
> function "sc_dt::operator+(const sc_dt::sc_int_base &, const
> sc_dt::sc_fxval_fast &)"
> operand types are: sc_dt::sc_int<20> + int
> y = x + 1;
>
> I've discussed this with Andy Goodrich. The compile error is happening because the sc_int class does not provide explicit operators for sc_int and native C++ data types, but rely on the automatic conversion of a sc_int to long long, and then for the native operators to kick in - this is for performance reasons, such that sc_int math is faster because the native hardware gets used rather than executing an overloaded operator. If the fixed point types are involved, then it creates ambiguity because it defines operator * for sc_int_base and sc_fxval, and the native types can all be converted to sc_fxval and to sc_fxval_fast.
>
> The workaround is to do the explicit casting as above, which can get quite tedious for long expressions.
>
> Fisrt question: Is there anything that can be done? One fix would be to define all the operators for sc_int and sc_uint and the native C++ types, but that would defeat the purpose of sc_int and sc_uint in the first place, which is to do things native. Is there any other way to make this work?
>
> Second, if we have to live with this behavior, then I think it makes sense for the LRM to explicitly mention this issue if SC_INCLUDE_FX is defined. I looked in the LRM, but could not find any such mention - I hope I didn't miss it.
>
> Thoughts?
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.