Re: ambiguous operators with SC_INCLUDE_FX

Hi Phillip and Bishnupriya,

My preference would be for option 1) - make the sc_fxval(_fast )
constructors explicit. To allow for backwards compatibility (which I
suspect would not affect that many users), I suggest adding a macro
SC_FXVAL_IMPLICIT_CONV that would include the current set of constructors
instead.

Dave

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
Bishnupriya Bhattacharya <bpriya@cadence.com>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, David
Long <david.long@doulos.com>
Date:
26/11/2010 11:49
Subject:
Re: ambiguous operators with SC_INCLUDE_FX
Sent by:
owner-systemc-p1666-technical@eda.org

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
[attachment "signature.asc" deleted by David Long/doulos] 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.