RE: IM33: Modifying and/or sending messages received

        Hi Russ,
             Did you want to make this a formal proposal for the next
version of the spec. If so, I will open an issue number for it, so that it
doesn't get forgotten.
        
        Thanks
        Brian
        
        -----Original Message-----
From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Russell
Vreeland
Sent: Friday, November 05, 2004 11:04 AM
To: 'Bojsen, Per'; itc@eda.org
Subject: 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
        
        
        
        
Received on Sat Nov 6 11:13:46 2004