All again,
there are various situations where knowing what is the current process
(if any) is important.
For instance, one could want to compute statistics on a per SystemC
process basis.
The current norm standardized very useful APIs to get information about
what is the current process, with sc_get_current_process_handle() and
the sc_process_handle
class.
However, there is no convenient and efficient way to understand what is
the current process
compared to previous invocations of sc_get_current_process_handle(). As
an example, let us
imagine I want to gather statistics about all processes in the
simulation. I would build an array
whose index would be a "process identifier" and that would contain my
"per-process" stat.
- The const char * returned by name() in sc_process_handle could be a
candidate to this "process identifier",
but this is rather inefficient (many string compare to understand in
which array index I already
stored my stat.,
- The adress of the sc_process_handle object cannot be taken as
"process identifier" as one could
have two different sc_process_handle representing the same process
information,
- There is also the operator== that allows to compare whether two
process handle actually represent
the same process's information. This would oblige to use the
sc_process_handle object itself (and not
a pointer to it) as the process indentified, which is not very
convenient, especially if you want to use a STL container
for the array (I guess that the copy constructor is private, which means
no std::vector, etc., etc.).
So we want to propose to add a method to the sc_process_handle class,
that could be as below:
uint64_t id() const;
and that could return a unique integer identifier associated with the
process. Hence, it would be
possible to retrieve and compare very quickly in what is the current
process.
Jerome Cornet
STMicroelectronics
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Mar 10 06:16:39 2010
This archive was generated by hypermail 2.1.8 : Wed Mar 10 2010 - 06:16:41 PST