Hi All,
I see three potential solutions to this issue and potentially
all of the extensions as extensions that we should consider for
the next revision.
1)
The first thing I think read what Ernst wants is
protected types. Protected types do exactly what he
is asking for.
The only issue I see is whether users will like the use
model for protected types. I note though that usage
of protected types is very similar to how other languages
use classes.
If you need some usage examples of this, see the CoveragePkg
that I have released at: http://www.synthworks.com/downloads
2)
The ADA like extension that Andy suggests also addresses
this. When I looked at ADA private types, it was never
clear to me why they actually introduced a private section
rather than using the package body as the private part.
It does not seem like a huge language change (at least from
a syntax point of view) if we allowed incomplete types that
were initially specified in the package declaration to be
completed in the package body.
3)
I also see the method Chuck suggests as a potential solution for
some problems.
To facilitate using this, I would think it would be nice to pass
the package that defines the types to be refined as a generic.
However, currently the only packages that we can pass as a generic
are generic packages. What I think we would need as an extension here
would be a concept of abstract packages. An abstract package would be
one that was allowed to specify incomplete types and subprogram declarations
that would be required to be implemented by any package that was
mapped to the abstract package in a generic instantiation.
The package I created for randomization, RandomPkg uses a separate package
RandomBasePkg in this way. RandomBasePkg defines what the RandomSeedType
is and the functions that use random seed type, uniform, seed hashing
functions, and seed read and writing procedures. You can also find
RandomPkg and RandomBasePkg at:
http://www.synthworks.com/downloads
We can talk about this further in tomorrows meeting if people who
are interested in it attend.
Best,
Jim
> -------- Original Message --------
> Subject: P1076.1 standard packages
> Date: Tue, 8 May 2012 08:02:31 -0700
> From: Ernst Christen <christen.1858@comcast.net>
> To: Jim Lewis <Jim@SynthWorks.com>
>
>
>
> Jim,
> I hope all is well. Unfortunately I don't have the bandwidth to attend the P1076 meetings, but being on the reflector keeps me at least informed. I had a change of affiliation recently after Lynguent
> went out of business, and I am with Mentor Graphics now working on their AMS products.
> You may remember that in P1076.1 we are in the process of developing two packages that you said could also be of interest to the P1076 standard: table-driven modeling and vector/matrix operations. In
> that context you mentioned that at some point the packages should be reviewed by ISAC. We are not quite that far along, but a question has come up that we want to resolve before moving further, except
> that AFAIK ISAC no longer exists. The issue is this.
> The TDM package is organized into two sets of subprograms. Routines in the first set, typically called during elaboration, read data from various file formats, while routines in the second set are run
> time functions to do the appropriate interpolation. The elab time functions do all consistency checks on the data, and they transform the data into an organization optimized for quick run time
> performance. The table data is then assigned to an object, typically a constant, that is passed as an actual to the runtime function. The issue now is that different implementations may have different
> ideas about how to optimize the run time performance, which will likely require different data layout. To address this issue we have been considering to declare just the name of the type in the
> standard, but not the data layout, similar to how it's done for universal_integer and universal_real: type XYZ is record implementation_defined end record; The result would be that the constant acts
> like a handle to the data without giving the model access to the data except through functions in the package.
> I wonder what the successor of ISAC would think about such an approach to define an opaque data type. Is there a better way to address this issue?
>
> Regards.
> Ernst
> --
> Ernst Christen, christen.1858@comcast.net on 5/8/2012
>
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed May 9 09:44:12 2012
This archive was generated by hypermail 2.1.8 : Wed May 09 2012 - 09:44:38 PDT