Internal Program – New Design

Using a pure reverse polish notation format for the internal program, the code for the command would be at the end of the line.  When running the program, the codes before the command code leave the arguments of the command on a stack, which are then available when the command token is executed.  However, for some commands like PRINT and INPUT, there would be several intermediate codes intermixed in the line that perform part of the command (for example, print a value, input a value, etc.).

I thought that using a less than pure RPN format would be easier to translate to and recreate from, where the command code would be first followed by the other codes and ending with an end of statement code (end-of-line, colon, ELSE, etc.), which would kick off the command.  There would still have been intermediate codes in the line, specifically the commas and semicolons that separate the other arguments of the commands.

When encountering these codes during run-time, they would call back to the command, which would look at the code and the type to decide how to process the value that are on the stack.  These separator codes would have required type information (double, integer or string) in the their sub-code field.   This would have complicated the run-time code.  Note the decisions that would need be made at run-time.  This would not be ideal as the goal is to make decisions before run-time so the code can be executed as fast as possible.

In any case, upon further contemplation, I decided that a pure RPN format would be best, but with a slightly different format for the intermediate codes needed for some commands, which would be the result of decisions made during translation.  Plus translation will be easier with the new command centric translator, which will be described in the upcoming posts along with the specific details of the various commands.