112855Sgabeblack@google.com/*****************************************************************************
212855Sgabeblack@google.com
312855Sgabeblack@google.com  Licensed to Accellera Systems Initiative Inc. (Accellera) under one or
412855Sgabeblack@google.com  more contributor license agreements.  See the NOTICE file distributed
512855Sgabeblack@google.com  with this work for additional information regarding copyright ownership.
612855Sgabeblack@google.com  Accellera licenses this file to you under the Apache License, Version 2.0
712855Sgabeblack@google.com  (the "License"); you may not use this file except in compliance with the
812855Sgabeblack@google.com  License.  You may obtain a copy of the License at
912855Sgabeblack@google.com
1012855Sgabeblack@google.com    http://www.apache.org/licenses/LICENSE-2.0
1112855Sgabeblack@google.com
1212855Sgabeblack@google.com  Unless required by applicable law or agreed to in writing, software
1312855Sgabeblack@google.com  distributed under the License is distributed on an "AS IS" BASIS,
1412855Sgabeblack@google.com  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
1512855Sgabeblack@google.com  implied.  See the License for the specific language governing
1612855Sgabeblack@google.com  permissions and limitations under the License.
1712855Sgabeblack@google.com
1812855Sgabeblack@google.com *****************************************************************************/
1912855Sgabeblack@google.com
2012855Sgabeblack@google.com/*****************************************************************************
2112855Sgabeblack@google.com
2212855Sgabeblack@google.com  test.cpp --
2312855Sgabeblack@google.com
2412855Sgabeblack@google.com  Original Author: Martin Janssen, Synopsys, Inc., 2002-02-15
2512855Sgabeblack@google.com
2612855Sgabeblack@google.com *****************************************************************************/
2712855Sgabeblack@google.com
2812855Sgabeblack@google.com/*****************************************************************************
2912855Sgabeblack@google.com
3012855Sgabeblack@google.com  MODIFICATION LOG - modifiers, enter your name, affiliation, date and
3112855Sgabeblack@google.com  changes you are making here.
3212855Sgabeblack@google.com
3312855Sgabeblack@google.com      Name, Affiliation, Date:
3412855Sgabeblack@google.com  Description of Modification:
3512855Sgabeblack@google.com
3612855Sgabeblack@google.com *****************************************************************************/
3712855Sgabeblack@google.com
3812855Sgabeblack@google.com/*
3912855Sgabeblack@google.comNov/29/00 Ulli Holtmann
4012855Sgabeblack@google.com
4112855Sgabeblack@google.comAssignment of values other than 0 or 1 to an sc_bit results in a core dump
4212855Sgabeblack@google.comon Sparc SC5.0 as well as g++. I used SystemC 1.0.1
4312855Sgabeblack@google.com
4412855Sgabeblack@google.comI can understand that only 0 and 1 make sense, so please either forbid
4512855Sgabeblack@google.comassignment from an integer and cast the integer to bool first. A core dump is
4612855Sgabeblack@google.coma bit to drastic.
4712855Sgabeblack@google.com
4812855Sgabeblack@google.comExample:
4912855Sgabeblack@google.com*/
5012855Sgabeblack@google.com
5112855Sgabeblack@google.com#include <systemc.h>
5212855Sgabeblack@google.com
5312855Sgabeblack@google.comint sc_main(int argc, char* arg[])
5412855Sgabeblack@google.com{
5512855Sgabeblack@google.com    sc_bit res;
5612855Sgabeblack@google.com
5712855Sgabeblack@google.com    // works fine
5812855Sgabeblack@google.com    res = 0;           cout << res << "\n";
5912855Sgabeblack@google.com    res = 1;           cout << res << "\n";
6012855Sgabeblack@google.com    res = bool(2);     cout << res << "\n";
6112855Sgabeblack@google.com
6212855Sgabeblack@google.com    // results in a core dump
6312855Sgabeblack@google.com    res = sc_bit(2);   cout << res << "\n";
6412855Sgabeblack@google.com    res = 2;          cout << res << "\n";
6512855Sgabeblack@google.com
6612855Sgabeblack@google.com    return 0;
6712855Sgabeblack@google.com}
6812855Sgabeblack@google.com
6912855Sgabeblack@google.com
7012855Sgabeblack@google.com/*
7112855Sgabeblack@google.comDec/7/00 ulrich
7212855Sgabeblack@google.com
7312855Sgabeblack@google.comHi Gene,
7412855Sgabeblack@google.com
7512855Sgabeblack@google.comI agree that the assignment of values other than 0,1 doesn't make much sense, so please go ahead
7612855Sgabeblack@google.comand forbid it in one way or another. However, such an illegal assignment may easily happen in a
7712855Sgabeblack@google.comuser-program because the compiler accepts it. It very easy to write.
7812855Sgabeblack@google.com
7912855Sgabeblack@google.comThe point I dislike is that the class library immediately core dumps without any warning or
8012855Sgabeblack@google.comexplanation. Does SystemC throw an exception? I don't know and I most likely will not write
8112855Sgabeblack@google.coman exception handler, therefore I will never know. I just see that the SystemC kernel core
8212855Sgabeblack@google.comdumps.
8312855Sgabeblack@google.com
8412855Sgabeblack@google.comWhat about an assert statement such like
8512855Sgabeblack@google.com	assert(v==0 || v==1);
8612855Sgabeblack@google.comThat should me as the user a precise and reasonable explanation that I made a mistake. I could
8712855Sgabeblack@google.comalso accept an error message like E200x or so coming like when I enter illlegal bit characters,
8812855Sgabeblack@google.come.g. sc_bv<10>="102abd00". But please, not just a core dump.
8912855Sgabeblack@google.com
9012855Sgabeblack@google.com
9112855Sgabeblack@google.com
9212855Sgabeblack@google.comJan/9/01 ulrich
9312855Sgabeblack@google.com
9412855Sgabeblack@google.comHi Gene, I still only ask that the program does not core dump and instead prints an error
9512855Sgabeblack@google.commessage or warning like it does for sc_logic. I only object to the core dump itself. Example:
9612855Sgabeblack@google.com
9712855Sgabeblack@google.com
9812855Sgabeblack@google.comint main(int argc, char* arg[])
9912855Sgabeblack@google.com{
10012855Sgabeblack@google.com  sc_logic l (5);
10112855Sgabeblack@google.com  cout << l << "\n";
10212855Sgabeblack@google.com
10312855Sgabeblack@google.com  sc_bit b(2);
10412855Sgabeblack@google.com  cout << b << "\n";
10512855Sgabeblack@google.com}
10612855Sgabeblack@google.com
10712855Sgabeblack@google.comBoth are invalid assignments. The first one prompt a warning (1006), the second a core
10812855Sgabeblack@google.comdump. Both should prompt warnings/run time errors.
10912855Sgabeblack@google.com
11012855Sgabeblack@google.comI reduce the prioity to B2 because it's now only a matter of properly reporting an error.
11112855Sgabeblack@google.com
11212855Sgabeblack@google.comOther than
11312855Sgabeblack@google.comthis, I can share your view that assigning 2 is a user error.
11412855Sgabeblack@google.com*/
115