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