Trailing-Edge
-
PDP-10 Archives
-
decuslib20-02
-
decus/20-0057/change.inf
There are 2 other files named change.inf in the archive. Click here to see a list.
Changes to FASBOL for VM monitor June 1978
--------------------------------
The version of FASBOL supplied by DECUS does not work on our KI10 under the
6.03 monitor. This is because all our users run virtual.
FASBOL needs a way of trapping assignments to input-output "variables" in
order to do I/O. It does this by giving these variables addresses in the
top 1K of core (locations 777000 - 777777) and at the same time ensuring that
these addresses are illegal. It then enables for APR traps and catches the
I/O assignment when the program does an illegal memory reference.
In the good old days this just meant that FASBOL programs couldn't use all
256K of the address space; but under a VM monitor it has disasterous effects.
The system puts the page fault handler up in the last 1K of core. This means
that a FASBOL output assignment doesn't cause an illegal memory reference trap,
instead it simply writes on the page fault handler. Similarly an input
assignment doesn't cause a trap - it just reads nonsense.
I can see various ways to get rid of the problem:
1. Don't use a page fault handler. The system will not bring in a page fault
handler unless the user exceeds his physical guideline or physical l imit,
so if these are high enough there is no problem. However this is very
inconvenient for our system, since we use VM as much as possible in order to
save space. Also a FASBOL program which grows may suddenly go virtual and die.
2. Alter FASBOL so that it does its I/O differently. This is the best
solution, but it requires the most work.
3. Alter FASBOL so that it puts its I/O "variables" somewhere else - for
example in the next-to-last K. This should work, although the user must not
use VMDDT (which also gets put there). However the constant 777000 appears
in various places in the FASBOL library, and I dared n ot try to alter it.
This also makes a dirty piece of program even dirtier.
4. Put the page fault handler somewhere else. If a page fault handler is
loaded with the program then the monitor will not bring in its own.
This is the solution I have chosen. I have adapted a page fault handler
so that it can be part of the FASLIB library.
The modifications are as follows:
- Add a new module PFHSNO to the FASLIB library
- Add a new switch P$VM to SDDNDF. This should be set for VM systems.
- Add a subroutine call to the initialisation code in SDDSYS so that
it calls the page fault handler initialisation routine.
- Add a subroutine call in the EXIT routine in SDDPRM, so that the
page fault handler gets reinitialised when the program is restarted.
The resulting FASBOL programs run slower, but they are smaller.
For example a FASBOL compilation:
Old system - 76p core 10 secs 700 kilo-core secs
New system - size varies 40-70p 15 secs 450 kilo-core secs
(I don't understand how the machine arrives at these KCS totals.)
In this case the kilo-core cost is actually reduced, even though the
cpu time is increased.
Nigel Derrett
Computer Sci ence Department
Aarhus University