On the ROM switching, it is documented, I think in the official manual, that when compiling, at least on a single processor system, the compiler is paged in and the BL-code interpreter is copied into RAM. It is done that way because the compiler (stored as BL-code) is bigger than the BL-code interpreter so it uses less RAM that way.
Compare with the BCPL system where the CINTCODE interpreter continues to run from ROM and the compiler has a small driver program that loads a series of passes in sequence from disc. The BCPL approach is prone to running out of memory as the compiler pass and symbol table or other intermediate representation of the program all need to fit in RAM at the same time.
Back to Pascal, there are two things that may contribute to the complexity of the language entry and ROM swapping:
1. No doubt it is intended that either ROM can be put in the higher priority slot, but the command-line environment is provided only by the editor/interpreter ROM so if the compiler ROM finds itself activated after a normal Break it will want to activate the opposite ROM.
2. When running in the tube processor, the compiler will need to be copied across the tube. There is no bulk-transfer call to move data from the I/O processor to the tube processor so the easiest way to do that would be for the interpreter ROM running in the language processor to copy the interpreter out of the way, activate the compiler ROM as a language, whereupon the OS will do the 16K copy quickly, then return control to the interpreter code.
It is also worth noting that the editor, in the editor/interpreter ROM has been disassembled previously - see a thread on here about editor source code.
Compare with the BCPL system where the CINTCODE interpreter continues to run from ROM and the compiler has a small driver program that loads a series of passes in sequence from disc. The BCPL approach is prone to running out of memory as the compiler pass and symbol table or other intermediate representation of the program all need to fit in RAM at the same time.
Back to Pascal, there are two things that may contribute to the complexity of the language entry and ROM swapping:
1. No doubt it is intended that either ROM can be put in the higher priority slot, but the command-line environment is provided only by the editor/interpreter ROM so if the compiler ROM finds itself activated after a normal Break it will want to activate the opposite ROM.
2. When running in the tube processor, the compiler will need to be copied across the tube. There is no bulk-transfer call to move data from the I/O processor to the tube processor so the easiest way to do that would be for the interpreter ROM running in the language processor to copy the interpreter out of the way, activate the compiler ROM as a language, whereupon the OS will do the 16K copy quickly, then return control to the interpreter code.
It is also worth noting that the editor, in the editor/interpreter ROM has been disassembled previously - see a thread on here about editor source code.
Statistics: Posted by Coeus — Tue Sep 24, 2024 10:49 pm