Class types that have both implicit construction and
an explicit constructor can blend the implicit and
explicit construction into the "new" function defined
by the user. This doesn't change the behavior any, but
removes a function call and related scope.
Add properties to the classes, and elaborate expressions that
have class properties. Describe class object property references
all the way down to the stub target.
defparam assignments found inside a generate block were being stored
in the enclosing module scope. They should be stored in the generate
block scope.
Also removed the genvar list from the PGenerate class, as this is
already declared in the base LexicalScope class.
Currently, localparam declarations inside generate blocks are
elaborated after any nested generate constructs are elaborated.
This prevents the localparams being used by the nested constructs.
Reversing the elaboration order fixes this bug.
Added: basic vpiPort VPI Objects for vpiModulkes
vpiDirection, vpiPortIndex, vpiName, vpiSize attributes
Since ports do not exist as net-like entities (nets either side
module instance boundaries are in effect connect directly in
the language front-ends internal representation) the port information
is effectively just meta-data passed through t-dll interface and
output as a additional annotation of module scopes in vvp.
Added: vpiLocalParam attribute for vpiParameter VPI objects
Added: support build for 32-bit target on 64-bit host (--with-m32
option to configure.in and minor tweaks to Makefiles and systemc-vpi).
Making the scope type NESTED_MODULE was just plain wrong, because
it didn't really encapsulate the meaning of program blocks OR
nested modules. So instead create nested_module() and program_block()
flags and use those to test scope constraints.
An important advantage of program blocks is its ability to nest
within a module. This winds up also allowing modules to nest, which
is legal but presumably less used feature.
A NetScope object currently has two lists of parameters, 'parameters'
and 'localparams'. However, user-declared localparams are stored in
the 'parameters' list, and 'localparams' is only used for adding
genvar values to the parameter list. There seems no good reason to
maintain separate lists, as the lists are merged before being passed
to the target DLL. This is most likely a hang-over from older code.
This patch extends the compiler to support all specparam declarations
allowed by the 1364-2005 standard. For compatibility with other
simulators, it allows specparam values to be used in any constant
expression, but outputs a warning message and disables run-time
annotation of a specparam if it is used in an expression that must
be evaluated at compile time.
When a conditional statement is unnamed, it doesn't create a scope
and we get into "direct" generate scheme elaboration. This direct
elaboration needs to handle case generate schemes.
This is a cleanup in preparation for better support of range lists.
(cherry picked from commit 8f7cf3255acad55841f8b3725e3786ef49daad68)
Conflicts:
PTask.h
elab_scope.cc
elab_sig.cc
parse.y
pform.cc
pform.h
pform_types.h
Signed-off-by: Stephen Williams <steve@icarus.com>
This patch fixes a few more bugs in the enumeration code.
It add support for saving the file and line information to make
diagnostic messages better.
It updates some of the compiler warning messages to use the file
and line information.
It passes if the enumeration type is signed all the way to the
code generators.
It fixes the parser to correctly have the range after the signed
designation for the vector types.
It adds a warning that vvp does not currently support a negative
two state enumeration value.
This patch allows the compiler to perform early elaboration
of functions if they are encountered in expressions that are
elaborated before the function would normally be elaborated.
This makes the function available for constant evaluation.
Suitable error messages are generated if a function that is
used in a constant expression is not a valid constant function.
This patch changes the method used to signal that a constant expression
is being elaborated from flags stored in global variables to flags
passed down the call chain. It also generates more informative error
messages when variable references are found in a constant expression.
The compiler currently performs parameter expression elaboration before
performing parameter overrides. This means that the information needed
to correctly determine the expression type and width may not be available
at the time elaboration is performed. This patch reworks the code to
delay elaboration until after all overrides have been performed. It
also provides a new -g option that controls how the width of parameter
expressions is calculated when the parameter itself is unsized.
This gets the enumeration type through to the ivl_target API so
that code generators can do something with it. Generate stub
output with tgt-stub, and generate the proper vvp run time to
make simple enumerations work from end to end.
The pform propagates the parsed enum base type information
to the elaborator so that the base type can be fully elaborated.
This is necessary to get the types of the enumeration literals
correct.
This patch covers more than it should. It removes many of the -Wextra
warnings in the main ivl directory. It also makes some minor code
improvements, adds support for constant logicals in eval_tree (&&/||),
adds support for correctly sign extending === and !==, it starts to
standardize the eval_tree debug messages and fixes a strength bug
in the target interface (found with -Wextra). The rest of the warnings
and eval_tree() rework will need to come as a second patch.
Stephen Williams
Cary R
Arun Persaud
Martin Whitaker
Andrew Stevens
Martin Whitaker