Subject: Re: [sv-cc] [Fwd: Re: Version 2 of DPI LRM]
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Mar 12 2003 - 11:28:14 PST
> DOUG wrote:
[I took the liberty to permutate quotations - Andrzej]
> We should give specific examples of common programming practices [...]
I'd rather make money myself selling tutorials or brochures on this subject :-)
But seriously, I believe it would be beneficial for the will-be users of DPI
to see good examples of DPI applications. The examples that would show
what can be achieved via this interface, what are the recommended coding
styles or useful and not-so-obvious tricks. But this would go beyond the scope
od LRM, I'm afraid. The purpose of LRM examples is to illustrate the correct
and legal usage of the defined construct rather than to teach how to use
them smartly. The language is a tool. How to use it smartly and efficiently
is a skill and a know-how.
> [...] common programming practices that would break compatability,
They seem pretty obvious ... And not SV specific.
Besides, there are workarounds for many of them. The knowledge of them is
more a know-how than a part of the standard.
> To re-iterate the request John and I made in the meeting, I think
> it is important that we more precisely define the bounds of source
> compatability in the LRM.
I believe there is enough precision there.
The bottom line is very simple (and presented in LRM):
- if an application can be compiled without any vendor-provided include
files, it is binary compatible
- if an application can be compiled without vendor-provided include files
other than sv_src.h, then it is source compatible
- if an application requires vendor-provided include files other than sv_src.h
to be successfully compiled, then it is not source compatible
Shall we enumerate the situations that require a complete knowledge of a data
type rather than the knowledge that a type is an obscure pointer?
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 11:29:05 PST