[ibis-macro] Re: A question on the suggestion of using **msg for error conditions
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 18 May 2011 12:00:16 -0700
Walter,
I think we could shorten your list to two points:
1) AMI_Close is always required to be present in an AMI DLL, and
expected to be executed by the EDA tool after the last GetWave
call or if GetWave doesn't exist, after the Init call.
2) AMI_Close is responsible to free all memory that was allocated
by AMI_Init and AMI_GetWave.
Questions:
Is the **AMI_parameters_out argument in AMI_Init and AMI_GetWave
one and the same pointer, or are they two independent pointers?
In other words, is AMI_GetWave allocating its own memory for this
argument or is it going to reuse the memory allocated by AMI_Init?
If AMI_Init or AMI_GetWave allocates memory other than what is
visible on the function arguments, how is AMI_Close going to know
how to free it? Do we have or need rules that if they do so, they
should free it for themselves? Or do we have/need rules that this
is not allowed, and everything needs to be made known to and freed
in AMI_close? This would influence what we say in #2 above...
Thanks,
Arpad
===================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, May 18, 2011 1:25 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: A question on the suggestion of using
**msg for error conditions
Arpad,
AMI_GetWave does allocate memory, so I recommend the following (it is a
little disjoint but covers what needs to be said):
1. If AMI_GetWave does not exist or is not called, then AMI_Close
needs to be called after AMI_Init.
2. If there are AMI_GetWave calls after the AMI_Init is called,
then AMI_Close needs to be called after the last call to AMI_GetWave.
3. One needs to assume that AMI_GetWave does allocate memory (e.g.
for the Overlap-save method).
4. AMI_Init allocated the memory for **QCD_Parameter_out and
**msg, and AMI_Close is responsible for freeing this memory.
5. AMI_Close is responsible for freeing all memory allocated by
AMI_Init, AMI_GetWave and AMI_Close.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, May 18, 2011 1:40 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: A question on the suggestion of using **msg
for error conditions
Walter,
Regarding "I think you are proposing...", to be precise, I was just
trying to find a way to incorporate the suggestion from Ambrish in
the BIRD draft, and in the process I ran into these questions...
Your suggestion of adding a new reserved parameter for this purpose
may be a cleaner way to do this.
However, having looked into this idea of using **msg, I feel that we
have another can of worms which are about get loose ...
Correct me if I am missing something, but I don't see the rules in
the spec about who allocates and deallocates memory for **msg. To
take this further, I don't see the rules spelled out about which
function is responsible for allocating and deallocating memory for
this or any other arguments.
I had this impression that the idea was that AMI_Init is responsible
for allocating memory and AMI_Close was responsible to deallocating
memory, but then look at this. According to pg. 181, AMI_Close is
optional except when AMI_GetWave is present:
I don't understand the reason for this rule, because it seems
that AMI_GetWave doesn't allocate any memory (at least as far
as the arguments go, unless the **AMI_parameters_out of
AMI_GetWave supposed to use a different memory space from the
**AMI_parameters_out argument of the AMI_Init function, which
is not spelled out in the spec either).
Considering this, if AMI_Close was needed for memory deallocation,
it seems that it should be required with AMI_Init and not
AMI_GetWave.
But going back to what the spec says currently, the current
rule that AMI_Close is not required with AMI_Init implies that
if AMI_Close is not present, AMI_Init would have to take care
of deallocating the memory it allocated. This means that **msg
and **AMI_parameters_out would have to be deallocated just before
AMI_Init exits in AMI_Init. On the other hand, if there is an
AMI_GetWave function, we would probably prefer to deallocate
memory in AMI_Close, so that AMI_GetWave could still enjoy
using them. This may be crystal clear to an experienced programmer,
but could be error prone even to them compared with a simple
rule that required AMI_Close all the time and said that all
memory is deallocated in AMI_Close.
Whether we simplify the rules or not, the main problem I have
is that most of this is not spelled out in the specification.
Comments?
Arpad
===================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Wednesday, May 18, 2011 6:02 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] A question on the suggestion of using **msg
for error conditions
Arpad,
I think you are proposing that AMI_GetWave can modify the content of the
data that **msg contains. I think this would work, as long as the length
of the string does not need to increase in size from what was initially
allocated by Init. I think a more satisficatory solution is a new
reserved parameter Message:
(Message (Usage Out) (Type String) (Value " ")
(Description "Message may be returned by either
AMI_Init or AMI_GetWave.
The contents of the Message string may
contain the following
keywords: **Error**, **Warning**, and
any other useful descriptive
strings that the User can interpret.
The Simulator should report
the value of Message to the User. The
EDA Tool may also make
choose to termination simulations if
the Message string contains
**Error**.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, May 18, 2011 1:35 AM
To: IBIS-ATM
Subject: [ibis-macro] A question on the suggestion of using **msg for
error conditions
Hello everyone:
I am working on updating the BIRD drafts we discussed in the
last ATM teleconference.
There was a suggestion that I should add some text in the
BIRD draft dealing with the return values that the **msg
argument should be used to explain the error conditions.
Thinking about how I should verbalize this, I noticed that
we only have a **msg argument in the AMI_Init function's
footprint. This raises more questions.
The current specification doesn't spell out who allocates
memory for **msg. We might want to spell out the rules
about that too, but I assume that the rules would be the
same as for AMI_parameters_out, i.e. the AMI model allocates
and clears the memory for it.
In addition, can we assume that all memory is cleared in
the AMI_Close function, and not at the time when the Init
function exits?
If these are true, can we assume that the memory at **msg
is available during the execution of both AMI_Init and
AMI_GetWave, therefore the model can write messages about
problems encountered during the execution of either
function?
Or is the model only supposed to use **msg during the
execution of AMI_Init?
Thanks,
Arpad
============================================================
Other related posts:
