This will hopefully improve performance slightly, but also this
intended as a model for what to do when I get around to doing the
same thing to other data types.
Strings, when put into dynamic arrays, are treated as first class
types much line reals. Add the code generator and vvp support for
this situation. Also fix a bug distinguishing between character
selects from strings and select form arrays of strings.
This involves working out the code to get the base type of a select
expression of a darray. Also added the runtime support for darrays
with real value elements.
Implement through the ivl core to the ivl_target.h API.
Also draft implementation of creating and storing arrays
in the vvp runtime and code generator.
When string[x] is an l-value, generate code to implement something
like the string.putc(x, ...) method.
Also handle when string[x] is the argument of a system task. In that
case resort to treating it as a calculated 8-bit vector, because that
is what it is.
This also advances support for string expressions in general.
Handle assignments to string variables in the code generator by
trying to calculate a string expression. This involves the new
string object thread details.
In vvp, create the .var/str variable for representing strings, and
handle strings in the $display system task.
Add to vvp threads the concept of a stack of strings. This is going to
be how complex objects are to me handled in the future: forth-like
operation stacks. Also add the first two instructions to minimally get
strings to work.
In the parser, handle the variable declaration and make it available
to the ivl_target.h code generator. The vvp code generator can use this
information to generate the code for new vvp support.
This is a pretty trivial fix for the code generation of compressed
assign to a memory word. We generated incorect code for the stash
of the calculated word index, causing the assign of the result to
not work properly.
Now we have a code generator that can handle compressed assignments
as they have been re-imagined in elaboration. There are some cases
that are not yet supported, we'll patch them up in due course.
Stephen Williams
Arun Persaud
Cary R