Saturday, October 5, 2013

Variable Dictionaries

When the program is run, the values for the variables need to be initialized (numbers to zero, and strings to empty).  If all three data types of variables are stored in the same dictionary, the initialization routine would need to check the data type for each variable before initializing its value.  This is not necessary if a variable dictionary contains a single data type, in which case it just has to loop through and initialize a single value type.  The variable dictionaries will not hold the actual variable values.  The run-time module will allocate and own the arrays with the values.

For now, no other information is needed in the variable dictionaries.  The variable name is stored as the dictionary key, and the data type is implied by which dictionary contains the variable.  Therefore at this moment, the base dictionary class is sufficient for the variable dictionaries.  However, eventually addition information will need to be stored with the variable.

To complete the implementation of the variable dictionaries, three dictionaries, one for each data type, were added to the program unit class with the associated allocation and access functions.  Encode and operand text routines were implemented for each of the three data types.  These routines call the add (for encode) or string (for operand text) routines of the variable dictionary for the associated data type.  These functions were placed in a the new basic.cpp source file, which will also contain the run-time routines for the variable and variable reference codes along with other miscellaneous functions (the two rem functions were also moved into this file).

Finally, pointers to these functions were placed in the six table entries for these codes (variable and variable reference times the three data types).  Several new statements were added to encoder test #1 so that there are more than one variable of each data type.  The expected results file for this test was updated for the variable names that are now in the output along with the output of the new statements.

[commit 2843b44761]

Operand Text / Remark Operands

Next up was to retrieve the text for the operand (comment string) of the remark command or operator from the dictionary using the index that is stored in the program code.  The recreator also needs to do this, therefore, a mechanism was implemented to allow for the getting the text for the debug output, which will later be used for the recreator.

A new operand text function pointer was added to the table entry.  This function is only needed for codes that have an operand, and an access function was added for this pointer.  These functions have arguments for the pointer to the current program unit (to access the dictionaries) and the operand.  The rem operand text function was implemented to get the text of the remark for an operand (an index) by passing it to the new dictionary string access function (gets the text from the key list member).

The program line text routine was renamed to debug text since it is only used for generating text for test output.  Also, since this routine needs access the program unit for the dictionaries to look index values, it was moved to the program unit class.  Since the program line class was only created to add the text routine to a QVector, this class was removed and  QVector<ProgramWord> is now used.

The operand debug text (renamed) routine outputs the index of the operand along with the value of the operand, and needed to output the text of the operand.  To get the pointer to the operand text function, it would need to be passed the code for the operand and would need the table instance.  Instead, this functionality is handled by the debug text routine and the resulting text is passed to this routine to add the word index and operand index values.

The debug text routine also needs the table instance, so a table reference was added to the program unit class.  This routine will also be called when encoded debug text is integrated into the program view of the GUI.  The test routine called this routine with a program line (now a program word vector), however, when used for the program view, a program word vector would need to be extracted from the program unit code vector.  This would require a vector to be copied from part of the total program code vector.  To prevent this copy, the debug text was modified to take a program word pointer and a count of the number of words in the line.

Some minor cleanup of the table entries were performed on a separate commit (placed function pointers on their own lines, corrected the camel casing of the rem encode routine, and fixed a comment).  The expected results file of encoder test #1 was updated for the remark comments that are now in the output.

[commit f5fe1efa4f] [commit bf9264bafb]