Re: nb_peek

Stuart,

you're right, it would be only a convenience functionality to access the
FIFO from the end without explicitly querying the current number of items.

  I don't have strong opinions in either direction, just wanted to point
this out as a consistent alternative for the peek/poke interface
definition. If you think this adds more harm than benefits, I agree
that dropping negative indices altogether is the best remaining option.

Greetings from Oldenburg,
Philipp

On 29/03/10 22:32, Stuart Swan wrote:
> For both nb_peek and nb_poke, you can get the same functionality
> by simply querying the current # items in the fifo and then doing
> peek/poke using a non-negative number less than the current size.
>
> If the user is passing in negative numbers then it seems to me that
> there is a fair chance there is a bug in his code, in which case we
> should disallow it in the LRM and put a check in the fifo implementation
> to catch it.
>
> Stuart
>
>> -----Original Message-----
>> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
>> Sent: Monday, March 29, 2010 12:06 PM
>> To: Stuart Swan
>> Cc: john.aynsley@doulos.com; systemc-p1666-technical@eda.org
>> Subject: Re: nb_peek
>>
>> John, Stuart,
>>
>> On 29/03/10 20:29, Stuart Swan wrote:
>>>
>>> I think that is some hack that Adam Rose probably put in - I don't
>>> think it should be included in the LRM since the same functionality
>>> can be achieved using other (and cleaner) TLM fifo apis.
>>
>> I think nb_peek and nb_poke are both clean and useful for non-consuming
>> fifo accesses. Doing this from "both ends" of the current queue is a
>> valid use case (not only for debugging).
>>
>> Consequently, I would even extend the functionality for both functions
>> to accept negative indices smaller than -1 to access inner elements from
>> the end. See below.
>>
>>> From: john.aynsley@doulos.com
>>> Sent: Monday, March 29, 2010 9:29 AM To:
>>> Subject: nb_peek
>>>
>>> The usual behavior of method
>>>
>>> tlm_fifo<T>::nb_peek( T &t , int n ) const
>>>
>>> is to return a reference to the item at location n, where 0 <= n <
>>> size()-1
>>
>> This should be used(), not size(), right?
>>
>> Also note, that the current documentation in tlm_fifo_ifs.h of these
>> functions does not match their implementation. It currently says:
>>
>> // non blocking peek and poke - no notification
>> //
>> // n is index of data :
>> // 0 <= n < size(), where 0 is most recently written, and size() - 1
>> // is oldest ie the one about to be read.
>>
>> Whereas in the implementation n=0 returns the one about to be read and
>> used()-1 would return the last written element. used() == size() is
>> only a special case, if the FIFO is currently completely filled.
>>
>>> However, the code includes a hack to accept n == -1, and have it
>>> equivalent to n == size()-1, i.e. peek the oldest item in the FIFO.
>>> Strangely, nb_poke does not have the equivalent special case.
>>>
>>> Do we want to document this special case of nb_peek in the LRM, in
>>> which case, should we add the same special case n == -1 to nb_poke?
>>
>> Peeking/poking from the writing end of the FIFO currently requires to
>> pass "used() - n" (except for the current hack).
>>
>> I would find it useful and consistent to allow arguments
>> -used() <= n < used()
>> where negative arguments are equivalent to "used() + n".
>>
>> This would both reduce the amount of typing and the risk of
>> programming errors (e.g. to use size() instead of used() in case of
>> partly filled FIFOs).

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS
R&D Division Transportation | FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-240/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.