Subject: RE: [sv-cc] Version 2 of DPI LRM] - compatibility, C Layer
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Mar 13 2003 - 14:12:46 PST
Andrzej,
The new wording looks good.
John,
Andrzej's other explanations are actually already in the LRM.
However, note that I consider those overly optimistic, and in
need of qualification with the extra caveats. Applications
requiring svc_src.h are not guaranteed safe source compatability.
They are guaranteed *not* to be binary compatible.
My request was that Andrzej temper the wording so as not
to be misleading about what it takes to achieve source
compatability. IMO his new wording accomplishes that.
Thanks Andrzej!
Regards,
Doug
> -----Original Message-----
> From: Stickley, John
> Sent: Thursday, March 13, 2003 11:13 AM
> To: Andrzej Litwiniuk
> Cc: sv-cc@server.eda.org
> Subject: Re: [sv-cc] Version 2 of DPI LRM] - compatibility, C Layer
>
>
> Andrzej,
>
> It looks good and I would also add specifically the comments
> you said before about if it only uses the contents of
> svc_src.h that it is safe for source compatibility. I think
> this puts things in pretty precise terms.
>
> -- johnS
>
> Andrzej Litwiniuk wrote:
> > Doug, JohnS, Michael and team,
> >
> > Would the following phrasing be less controversial and more precise?
> >
> >
> > [ A.7.1 Overview - 3rd paragraph - C Layer of DPI]
> >
> > "Access to packed arrays via canonical representation
> involves copying
> > arguments and does incur some overhead, however. Alternatively, for
> > the sake of performance the application can be tuned for a
> particular
> > tool and access the packed arrays directly through pointers using
> > implementation representation, which could compromise
> compatibility.
> > Data can be, however, moved around (copied, stored,
> retrieved) without
> > using canonical representation while preserving binary or
> source level
> > compatibility at the same time. This is possible by using
> pointers and
> > size of data and when the detailed knowledge of the data
> > representation is not required."
> >
> >
> > Regards,
> > Andrzej
> >
> >
> >
> >>--------------------------------------------
> >>A.7.1 Overview - 3rd paragraph
> >>
> >>I'm a little confused by the wording of this. If
> applications access
> >>packed arrays directly using implementation specific
> representation,
> >>is it not also source compatiblity that compromised as well ?
> >>
> >>Perhaps here we should make it clear that source compatability is
> >>compromised in addition binary compatibility.
> >>
> >>I understand that if all access is done using the access
> functions in
> >>section 10 for individual elements then it is still source
> compatible.
> >>But the wording of this implies direct access of the implementation
> >>specific representation without using any functions but
> rather vendor
> >>specific data types used in implementation. Was that your
> intent here
> >>?
> >>
> >>--------------------------------------------
> >
>
>
> --
>
> This email may contain material that is confidential,
> privileged and/or attorney work product for the sole use of
> the intended recipient. Any review, reliance or distribution
> by others or forwarding without express permission is
> strictly prohibited. If you are not the intended recipient,
> please contact the sender and delete all copies.
> __
> ______ | \
> ______________________/ \__ / \
> \ H Dome ___/ |
> John Stickley E | a __ ___/ / \____
> Principal Engineer l | l | \ /
> Verification Solutions Group | f | \/ ____
> Mentor Graphics Corp. - MED C \ -- / /
> 17 E. Cedar Place a \ __/ / /
> Ramsey, NJ 07446 p | / ___/
> | / /
> mailto:John_Stickley@mentor.com \ /
> Phone: (201)818-2585 \ /
> ---------
>
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 14:14:06 PST