25 Oct
2004
25 Oct
'04
2:28 a.m.
Paul Koning wrote:
Jerome> PIC is standard in the USR since it moves
up and down in
Jerome> memory ALL the time. So I do not understand why you even
Jerome> mention the PIC aspect, let alone that something special
Jerome> needed to be done, although perhaps with overlays, something
Jerome> extra was required. On the other hand, device drivers which
Jerome> execute their overlays within the USR buffer do that all the
Jerome> time.
Memory is a bit rusty, but I think what I did was to define an overlay
buffer (probably one or two blocks long) essentially as part of RMON.
So displacements from overlays to RMON would be constant, no matter
where RMON was loaded. Taking advantage of that saves space, because
you can reference RMON data and code without having to do it PICly --
just use PC relative addressing. However, that requires an assembler
that can be told "this code might link at X, but it will execute at
RMOVBF".
Jerome Fine replies:
MACRO-11 is extremely flexible and as long as the person
writing the code is able to tell MACRO-11 that the code
is in a different PSECT, MACRO-11 behaves correctly.
Based on what you are saying, since the buffer resides in
RMON, even though the code still MUST be PIC since
RMON loads into a variable address range (because the
resident device driver is always located at the top of memory -
and is variable in size dependent on which device driver is used),
the linker is able to figure out differences between different
PSECTS since that aspect is part of how PDP-11 instructions
work. The KEY point is that the linker can't figure out an
actual address, but must use execution time code based on
the current PC counter. Macros such as .Addr help a lot!
None of the above is saying that your statements about
PIC are incorrect, only that all of the USR and RMON
are that way in any case.
The more important question I have not asked is how
many words of memory (or blocks within the USR
less the extra buffer in RMON) were saved. For those
RT-11 users who are not aware, the USR is always
an exact multiple of 512 bytes or an even number of
blocks. Not sure why, but that is the way the code
needs to be. For RT11FB, the USR is always 10 blocks
while for RT11XM, the usual size is 12 blocks. How
were those figures changed?
PLUS, since the USR in RT11XM is resident, there
must have been a time penalty. Was that a problem?
Jerome> The only aspect I see a being a REAL
difficulty is that it is
Jerome> on hard copy. Any idea how many pages.
2-3 inches of line printer output?
That seems about 100 to 150 pages which is
not excessive. I would certainly pay to have
them duplicated and mailed via snail mail if you
were willing.
What I am MOST interested in is how you managed
to handle NON-contiguous files. Since the CSWs
(Channel Status Words) for each open file have
no method of "seeing" more than one file segment,
was there a limit to the number of file segments
allowed and where was the information stored?
ALSO, for programs which needed to .SAVESTATUS
and .REOPEN files, where and how was the extra
information saved? I would think that the data
for the segments was actually a pointer, but that
would then require the information to be saved
somewhere and that part I do not understand!!!!!
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.