The compiler up until now did not support direct WRITE of scalar variables; this was flagged as a implementation restriction. Other compilers (FPC for example) support this; they output the name of the scalar value (much the same way as our compiler does it for the type BOOLEAN).
Here is a short example program with direct WRITE of scalar values:
|
To support this, the compiler must build a table of the scalar names in the constant section.
Because I already did some work involving the constant section when adding the static variables, I knew what to do (the big picture).
So I added DFC instructions to the constant section, when parsing a scalar type definition, including a table of offsets and lenghts, so that the new scalar write function (a new CSP which I called WRX) will find the string corresponding to the internal scalar value. BTW: the internal scalar values are assigned from 0 to the maximum value by the compiler. The offset of this static table is recorded in the type informations, so that it can be retrieved from there, when needed; same goes for the CSECT name of the constant section. This is needed, because the scalar variable may be accessed at deeper levels, but the constant array resides where the type definition is.
This was kind of easy, but what made things really hard this time: there was an error in the code generation, which had nothing to do with this extension, but it took me a long time to find and to repair it.
Even code like the following
|
where R is a real value and ST is a static variable (or part of a structured const) has this sort of problem, because the base address of the constant section was loaded very early into a "wrong" register. But WRITE absolutely needs the 3 parameters in the registers 2, 3 and 4 - otherwise the code generation crashes.
This is a flaw of the PCODE translator PASCAL2, and I fixed it (this time) by adding some logic to the routine FILESETUP, that is: if the parameters appear in the "wrong" registers, some LRs are generated and the needed registers are freed this way. This is not perfect, because it generates unnecessary LRs, but it works for the moment.
After this modification, all was ok (even the OLD errors), and I only had to add the new standard function WRX to the Pascal monitor (which involves some ASSEMBLER work).
When all was completed, the test program (see above) produced the following output:
|
BTW: you can see from this example that values outside the range of the scalar type do not produce abends, but instead WRX writes the hex value of the scalar (4 digits), prefixed by WRX: