Subject: Re: pointers & handles
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Jan 07 2003 - 16:51:49 PST
> From doug_warmke@mentorg.com Tue Jan 7 16:24:02 2003
>
> 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.
That assumes you have your data in a form that lends itself to
that kind of access. I don't agree with the assumption.
> 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.
A lot of C bugs have to do with memory being accessed inappropriately,
giving users pointers to simulation kernel memory guarantees that
you will get more hard to find bugs.
Defining the interface in a way that can be implemented with macros
using pointers and/or handles and abstract access gives everyone
what they want.
Regards,
Kev.
> 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! ***
> >
> >
>
>
This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 16:57:44 PST