Subject: Re: pointers & handles
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Jan 08 2003 - 07:47:15 PST
Hello Doug,
Thanks for this very good response. Let me try to show my thinking:
I am far away from wanting to re-enter the direct vs. abstract philosophy.
I have agree'd to direct accesses and there is no change in my opinion here
at all. But keep in mind we were talking here about different reasons:
Abstract access was originally intended to have a better debug capability.
We are not talking about debugging here at all ...
Also I don't say that abstract access is the only solution. If there is a better
one, fine with me. I have more problems with
a) asserting appropriate behavior under all possible design configurations
b) don't impose any implementation that may result in negative effects
(w.r.t. speed, usability or similar issues)
As such I stick with your assertion '... we voted to stick with direct access
_whenever_possible_'. I am questioning in this particular case the latter. Not
that I want to have abstract access here, I want a solution that:
. avoids a situation where implementation assumptions might result in non-
deterministic behavior or produce certain flaws. As an user I want a stable
and fool (Michael) proof solution.
. avoids a requirement to provide a complete copy of the array for every
access (read + write), since it is not know whether and which element
of an array is being modified. This is a space and performance issue.
IMHO the modification of pointers _imposes_ a solution that requires to sacrifice
one of the two above. Having a Put method _permits_ (but does not require)
to implement certain optimizations (which I have already pointed out). Not having
any visibility by the simulator into what is going on _prohibits_ these optimizations.
When DirectC provides scalar parameters it is easy to have a local copy for
these simple items and to detect changes. But in case of a (probably multi-
dimensional) array this is a different issue. If I have to copy a complete array
consisting of 256x64 bits every time one of my dumb functions want to chance
only a specific bit (I have seen such implementations in PLI!) and then have to
look for the modified bit in the modified array to only propogate the modification
and suppress further useless evaluations I am significantly sacrificing my performance.
And I still don't see how you can avoid those local copies without sacrificing the
stability and simulation semantic of the overall system.
Hope this clarifies a little bit my concerns.
Best regards,
Michael
"Warmke, Doug" wrote:
> Michael,
>
> I'm a little concerned that this line of reasoning is leading
> us back into the "direct" vs. "abstract" philosophy fray that
> I tried to head off by requesting the vote between options
> a), b), and c).
>
> Recall, we voted to stick with direct access whenever possible,
> and only resorting to abstract means when necessary. (And,
> no redundancy between direct and abstract access modes)
>
> With my user's hat on, rather than my simulation vendor's hat,
> I think direct access is very appealing and I would prefer to
> use it for reasons of simplicity and (potential) performance.
>
> With my vendor's hat on, I think it would be easier to
> implement abstract access. It would definitely be easier
> to propagate values from C code onto SV registers and nets
> at the right times with abstract access.
>
> In my judgement the original goals of our committee (simplicity,
> convenience, performance) win out over my implementation concerns,
> and I think we should use direct access for sized array parameters.
> I think Andrzej's proposal strikes a good balance between some
> difficult constraints.
>
> It's hard for me to precisely understand your concerns about
> modifying simulator data structures. What are you worried about?
> The simulator vendors on the committee don't seem as worried
> as the users, which seems unusual.
>
> Thanks and regards,
> Doug
>
> Michael Rohleder wrote:
> > Andrzej,
> >
> > I think you need to distinguish between the need for pointers to
> > . permit the reference to arbitrary types
> > . modify the actual value of a simulation object.
> > While I agree to the first bullet, Kevin and myself have some concerns about the second one.
> >
> > When we would have a set of GetElement and PutElement functions to read and modify the
> > actual value of an element, then the remaining functionality could be exactly like with parameters
> > of a DirectC function.
> >
> > -Michael
> >
> > Andrzej Litwiniuk wrote:
> >
> >
> >>Kevin wrote:
> >>
> >>>I have no objection to individual implementations using pointers if they
> >>>can, however an interface that depends on it won't work in general.
> >>
> >>Why do you think so? What's wrong with the pointers?
> >>
> >>
> >>>If the interface is specified such that all calls can be macro-definintions
> >>>then it should work either way.
> >>
> >>>Indirect:
> >>>
> >>> #define svcGetArrElemPtr2(my_value,MyType,h,i,j)\
> >>> NSCsvGetArrElemPtr2(&(my_value), h, i, j);
> >>
> >>Kevin,
> >>
> >>The interface may provide functions for the predefined types
> >>(int, shortreal, etc.) or predefined classes of types (packed bit/logic arrays),
> >>but =not= for all the possible user-defined types!
> >>
> >>Although it is possible to generate an access function for each user defined
> >>type, such approach seems impractical.
> >>Therefore no simulator can provide a function "NSCsvGetArrElemPtr2"
> >>for your private type "MyType".
> >>
> >>I don't see how it could be possible to provide access to an array element of arbitrary a type without resorting to pointers, if a predefined library
> >>is to be used.
> >>
> >>
> >>>NB: Macro definitions generally don't take "..." arguments.
> >>
> >>Right. So, macros won't do the trick either, will they?
> >>
> >>Andrzej
> >
> >
> > --
> >
> > NOTE: The content of this message may contain personal views
> > which are not neccessarily the views of Motorola, unless specifically stated.
> >
> > ___________________________________________________
> > | |
> > _ | Michael Rohleder Tel: +49-89-92103-259 | _
> > / )| Software Technologist Fax: +49-89-92103-680 |( \
> > / / | Motorola, Semiconductor Products, System Design | \ \
> > _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
> > (((\ \>|_/ > < \_|</ /)))
> > (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////)
> > \ /_______________________________________________\ /
> > \ _/ \_ /
> > / / \ \
> >
> > The information contained in this email has been classified as:
> > Motorola General Business Information (x)
> > Motorola Internal Use Only ( )
> > Motorola Confidential Proprietary ( )
> >
> >
> > *** This note may contain Motorola Confidential Proprietary or
> > Motorola Internal Use Only Information and is intended to be
> > reviewed by only the individual or organization named above.
> > If you are not the intended recipient or an authorized representative
> > of the intended recipient, you are hereby notified that any review,
> > dissemination or copying of this email and its attachments, if any,
> > or the information contained herein is prohibited. If you have received
> > this email in error, please immediately notify the sender by
> > return email and delete this email from your system.
> > Thank you! ***
> >
> >
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Wed Jan 08 2003 - 07:48:43 PST