To back up people wanting to create C (and other language) back end interpreters, the assembly and interpreter functions of the current pint module get broken up. The code assembled in the code store array is output to a file, and the result loaded into a further module which will become pint.pas. The assembler code goes into a new module, passm.pas. The code format will be "extended Intel hex". The reason for this is that it has to be maintained in ASCII, since the code only deals with text file external files. This then maintains compatibility with the existing code.
The prerequisites for this are #43 (stack direction) and #49 (constants move to top of code). These changes simplify the code down to a single contingous block for the transfer and load.
This has the effect of dramatically simplifying the code required for the P-machine, since pint.pas no longer needs to also assemble the code, and will enable writing portable backend interpreters.
samiam95124
commented
2 years ago
To back up people wanting to create C (and other language) back end interpreters, the assembly and interpreter functions of the current pint module get broken up. The code assembled in the code store array is output to a file, and the result loaded into a further module which will become pint.pas. The assembler code goes into a new module, passm.pas. The code format will be "extended Intel hex". The reason for this is that it has to be maintained in ASCII, since the code only deals with text file external files. This then maintains compatibility with the existing code. The prerequisites for this are #43 (stack direction) and #49 (constants move to top of code). These changes simplify the code down to a single contingous block for the transfer and load. This has the effect of dramatically simplifying the code required for the P-machine, since pint.pas no longer needs to also assemble the code, and will enable writing portable backend interpreters.