Subject: [Fwd: ISSUE #?? Proposal: const attribute for input params]
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Nov 27 2002 - 10:02:27 PST
Sorry, forgot to include the reflector ...
attached mail follows:
Kevin Cameron x3251 wrote:
> > From michael.rohleder@motorola.com Tue Nov 26 11:13:02 2002
> >
> > 'const' is an ANSI-C keyword and does prohibit modifications of the related parameter during compile time. A compilation error is
> > provided by the compiler when you try to modify such a parameter in the C code. This is the only thing I am interested in.
> >
>
> Yes, but that only makes sense if both SV and C share the same function prototype. If the
> prototype in SV is in SV style that may not be possible, it would only be meaningful if
> the SV compiler produced a header file for the C compiler to use. I'm not sure I want
> to force that - I'd leave that up to the vendors for now.
Hmmm. I am not sure that I get your point here. Let me try to find out whether we are on the same plate:
a) When we want to permit direct access to parameters passed from the SV side to C, then we must have a crystal clear defined mapping from
SV types to C types (specifying that integer maps to long, real to double and so on and so on ...). Since some of the data type names are
different, I can very rarely use a SV prototype on the C side; at least not in the case where there are non-inputs (since neither the
keywords input,output,or inout are understood, but input can be omitted) or data types named different than in C.
b) According to a) we HAVE TO specify a mapping from SV types to C types. Whether this is automated by a header file generation capability
or not, this is an implementation detail.
c) My request is that the direction property (input, output, inout) gets reflected by a 'const' keyword in case of an input port in this
mapping. Reason for this is that this permits the compiler to do some check whether an input parameter is being modified. That this is
illegal is already noted in Andrzejs proposal.
So the request is for another entry in the mapping information that we need to specify in the LRM anyway. I don't understand why this
request forces at all some prototype generation? We have to specify the appropriate prototype for a given function declaration in SV, and I
just want to extend this with const for obvious reasons.
Regards,
-Michael
> > For C linking this keyword has no effect at all. In case of C++ linking const will be included in the name mangling scheme. The result
> > would be a different function name with or without this specifier. This is nice, but not a requirement from my side.
> >
> > -Michael
> >
> > Kevin Cameron x3251 wrote:
> >
> > > > From: "Michael Rohleder" <michael.rohleder@motorola.com>
> > > >
> > > > Hi all,
> > > >
> > > > Since today is the deadline [ and we Germans always need to have the last word ;-) ] I would like to enter another proposal I
> > > > already said once, but forgot to include in the ISSUE list:
> > > >
> > > > Provide all parameters declared as INPUT (and only them) with the const keyword on the C side of the API. By doing so the compiler
> > > > on the C side can validate that the corresponding C value is not being overwritten.
> > >
> > > That only works with C++, C linking ignores argument types (and attributes).
> > >
> > > I think "const" is available if you want to use it.
> > >
> > > Kev.
> > >
> > > > IMHO it makes sense to use such built-in functionality whenever it is possible -- especially at no cost.
> > > >
> > > > -Michael
> > > >
--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 Nov 27 2002 - 10:03:15 PST