RE: IM33: Modifying and/or sending messages received

Per,

It's a valid point that the SceMiMessageData class could represent an
interface to the actual transfer data rather than an object for storage. The
implementations I've used (all one of them) don't do it that way and the
language that's in the spec regarding the objects having the same width as
the ports they're sent to hints that the objects are separate and
self-contained rather than interfaces.

Nevertheless, after these last couple emails, it's hard to argue that a
clarification is not in order! Maybe you could work the word "persistent"
into your proposed language?

Not that this is doable at this late date but I guess it would make more
sense to me if the SceMiMessageData class were folded into the two Proxy
classes -- that would eliminate the CycleStamp issue and generally simplify
things. Each proxy would encapsulate its own MessageData and the user
wouldn't have to fool with a separate construction of a MessageData object,
and be sure it's the same width as the proxy. If SCEMI ever implements
variable message lengths, this would be more suitable for that, I believe,
since you wouldn't have problems with port and message data width
discrepancies occuring dynamically. To address multiple data copy issues, it
would be cool to be able to set up an input port proxy to hold
references/pointers to data space elsewhere, or to have it call a user
function that could be used to do some assembly of message data every time
Send() is called.
Just musing out loud.

-Russ

---------------------------------------
--- Russ Vreeland (949)926-6143 ---
--- vreeland@broadcom.com ---
--- Senior Principal Engineer ---
--- Broadcom Corporation ---
---------------------------------------

-----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Bojsen, Per
Sent: Friday, November 05, 2004 8:24 AM
To: 'vreeland@broadcom.com'; itc@eda.org
Subject: RE: IM33: Modifying and/or sending messages received

Hi Russ,

> I believe the spec adequately describes the limited scope and lifetime
> of SceMiMessageData objects received through an OutputPortProxy.

Agreed, but the issue was not this, but whether the spec allows or should
allow these objects to be sent to input ports. Although this is a minor
issue and probably uncommon usage, what the spec says does affect the
implementation. For instance, if the spec explicitly forbids this usage,
then the implementation could take advantage of this in how it internally
handles and implements SceMiMessageData objects. Note, the SceMiMessageData
class is only the interface the application sees and more state may be kept
under the hood that differs depending on the direction of message transport.
 
> I would suggest, without any real fervor, that whether a user
> chooses to construct once and store SceMiMessageData objects for
> use with an InputPortProxy or "use once and discard" is an
> implementation detail best left to the users and requires no
> further clarification.

The point of adding the clarification was to ensure that all SCE-MI
implementations support both of these use models. This is important for
portability. If we do not specify whether reusing SceMiMessageData objects
are allowed or not, then there is a risk that eventually some
implementations will allow it while others will not.

> Since we're dealing with a C++ class here, and we're passing it to
> Send() via a const reference, the proposed clarification amounts to a
> C++ truism.

It is not that simple because the SceMiMessageData class is just the
interface. There is no requirement in the spec that the SceMiMessageData
class contain all the information related to a message. It is quite
possible to envision a case where forbidding reuse of SceMiMessageData
objects could lead to a more optimized implementation. In fact, allowing
reuse makes it harder for the implementation to avoid a data copy.

> The requirement that SceMiMessageData objects have the same
> width as the ports they're sent to is addressed in the description
> of the constructor in 5.4.5.1

True. Removing this, the proposal is now:

  Send()
 
  In Section 5.4.6.1, document p. 53, PDF p. 61, after the
  sentence under
  `data' add:

    This object may be arbitrarily modified after Send() and used for
    an arbitrary number of sends to the same and other message ports.
 
  Receive()
  
  In Section 5.4.7.1, document p. 55, PDF p. 63, after the last
  paragraph in the section add:
 
    The class SceMiMessageData object passed to the receive callback
    may be sent any number of times to any number of input ports.
    Modifying the class SceMiMessageData object by casting away const
    leads to undefined behavior.

> Changing subjects, after reading the spec some more, I found
> what might be a
> separate issue. The CycleStamp() accessor for
> SceMiMessageData objects is
> presented in the spec (p52, PDF 60) without any description
> of what would
> happen if a renegade user were to call it on a
> SceMiMessageData object not
> originating from an OutputPortProxy. Should the accessor call
> the port's
> error handler in this case, return 0, or is "undefined
> behavior" adequate?

I don't think undefined behavior is good. I think it makes sense to make
this an error, but unfortunately, CycleStamp() does not have a SceMiEC
argument so we cannot make it an error without changing CycleStamp()'s
declaration. If doing this is not an option, the only reasonable choices
left are to return 0, or, perhaps better, return the most recent value of
cycle stamp received through an output proxy.

Regards,
Per

-- 
Per Bojsen                                Email: <bojsen@zaiqtech.com>
Zaiq Technologies, Inc.                   WWW:   http://www.zaiqtech.com
78 Dragon Ct.                             Tel:   781 721 8229
Woburn, MA 01801                          Fax:   781 932 7488