> 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.
Received on Mon Oct 25 2004 - 09:28:10 BST