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

Just my 2¢. :-)

Greetings from Oldenburg,
Philipp

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