RE: Verbosity Control

Philip,

You raise very good points, as always. Please see my comments below.

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Friday, December 03, 2010 11:30 PM
To: john.aynsley@doulos.com
Cc: Bishnupriya Bhattacharya; systemc-p1666-technical@eda.org
Subject: Re: Verbosity Control

John, Bishnupriya,

in general, I'm in favour of adding the verbosity proposal to the LRM.

I did a review of the refined proposal, sent by Bishnupriya earlier today and found a couple of potential issues, though.

1) position of verbosity parameter / SC_IGNORE_VERBOSITY

  I think, if we choose an overload instead of a default parameter, we
  don't need the SC_IGNORE_VERBOSITY symbol. If we include it anyhow,
  we should define its meaning.

  Personally, I'd prefer the overload over the default parameter for no
  real technical reason.

[agreed]

2) sc_module::sc_report, sc_core::sc_report

   This is most likely an oversight, but there is already an
   sc_core::sc_report class defined in the LRM. While we technically
   _can_ overload the class name sc_core::sc_report with a function,
   I'd consider this quite bad style. This would also break any
   user-defined catch clauses, I think.

   So we need another name here, I guess.
     sc_do_report
     sc_create_report
     sc_make_report
     ...

[ooops! My prototype had the name as report() - since report() is very likely to clash with an user-defined method name, I tagged it with a sc_, and ended up duplicating. Another name has to be chosen for sure like what you propose or sc_gen_report()]

3) SC_REPORT_XXX_V

   Bishnupriya says:
   "the macros expand to invoke the function sc_report(); if the macros
    are invoked from global scope, sc_report() will resolve to the
    global function, and if invoked from module scope, sc_report() will
    resolve to the module's sc_report() function;"

   I don't like this macro definition to perform an unqualified call to
   sc_report(). This won't work on the global scope, if the user only
   includes <systemc> (which is recommended, I guess). Secondly, it
   will resolve to the wrong function, if sc_module is inherited
   indirectly from a templated base class (sice sc_report is not a
   dependent name).

[I myself had this technical concern for the global case when user includes <systemc>, but could not reproduce it with my prototype - not sure why. The sc_module derived case had never occurred to me.]

With 2) and 3), I think the module-specific verbosity might be too late to include for now. I would vote to skip this and only add a global function "sc_do_report" (better name?), with the signature:

[I agree with your technical concern on 3) but I do not agree that necessitates taking off module-specific verbosity altogether. 2) can be addressed by choosing an approrpriate name for the sc_module member method. For 3), we can simply take off the SC_REPORT_<XXX>_V macros and the global function sc_report(), and only stick to the new sc_report_handler::report() overloaded function, and the sc_module::sc_gen_report() method. User then has to explicitly call either the sc_report_handler::report() function or the sc_gen_report() function, depending on what scope he is in. Not the smooth use model that the SC_REPORT_<XXX>_V macros intended to achieve, but still usable, and no risk of ambiguities etc. If we want we can also come up with 2 different macros like SC_REPORT_<XXX>_GLOBAL_V and SC_REPORT_<XXX>_V.

Other than the possible ambiguity arising out of trying to use SC_REPORT_<XXX>_V macro for both global and module scope, do you see any technical disadvantage in including the reporting related member methods for sc_module? Our experience has shown us clearly that the global verbosity feature is definitely very useful, but the module-specific control adds a great deal of additional value.]

Thanks,
-Bishnupriya

namespace sc_core {
  void
  sc_do_report( sc_severity severity,
                const char* msg_type,
                const char* msg,
                int verbosity,
                const char* file = NULL,
                int line = 0 );
}

where file and line are optional for convenience.

Greetings from Oldenburg,
  Philipp

On 03/12/10 16:19, john.aynsley@doulos.com wrote:
> All,
>
> Do we want to get verbosity control into 1666? I ask because we only have a few days to go before the deadline, so everybody would have to accept the Cadence proposal more-or-less as it stands; we are not going to have time to debate the finer points. Would everyone please check out the proposal and "vote" yes or no.
>
> Thanks,
>
> John A
>
>
>

--
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.