Subject: Re: pointers & handles
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Jan 07 2003 - 16:26:15 PST
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! ***
>
>
This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 16:27:03 PST