On 07/07/2012 10:09 AM, Johnny Billquist <[email protected]> wrote:
What is left is actually writing the code, something that seems to get
much less attention...
Johnny
Good point. I had written a message last night which considered this,
but did not get around to sending it. It also addressed hardware and
OS options, which are now moot, since an 11/03 running RT-11 has all
but been chosen. Here it is below, somewhat edited. I've chopped off
the tail end, which discussed Unix Teco
-------- Unsent Message --------
[ --- snip --- Message headers snipped -- snip -- ]
On 07/06/2012 15:05:38 EDT 2012, Richard legalize at xmission.com wrote:
In article <4FF6AE2C.6050104 at dslextreme.com>,
Michael Bloom <mabloom at dslextreme.com> writes:
> What aspect of the experiment requires a pdp-11 architecture?
Desire.
That's a legitimate reason. I do not understand the reason behind it,
but if that is a design requirement, so be it. (Although it does not add
any technical information that will help us help you).
Even so, with the limits you've chosen, here are a few considerations:
You will need enough memory to include the TECO executable, the program
written in TECO, and the Q-register data storage necessary for your
TECO program, all on top of system overhead. If using a late enough
version of TECO, it might be beneficial to make as much use of "local Q
registers" (those with two char names beginning with "."), so that you
don't unintentionally accumulate data that you no longer need. You
could think of them as a TECO equivalent to "alloca()". They are
documented in the V40 manual (dated May 1985), but I don't recall them
being present in V36, so I'm not certain when they were introduced.
TECO may not work reliably (except as an editor) without maxing out (to
the degree permitted on a PDP-11) the process address space. Under
RSTS/E, that would mean 48 KB (the remaining 16KB is needed for the TECO
run-time system) minus stack space. I do not recall what the exact
overhead might be with other DEC OS's.
For RT-11, you'll lose 8 Kb space reserved for device registers plus
the amount of space RT-11 itself occupies (4K maybe? Anyone remember?),
and of course the space needed for the TECO interpreter itself. A rough
guess might be 38Kb for TECO (16Kb for instructions, 6Kb for TECO's
private data, 4Kb(??) for TECO's stack), RT-11 and I/O space. That's
38Kb already used, leaving 26Kb left for your buffer, your own TECO
code, and your code's Q register variables .
If you need to do any 32 bit arithmetic, you'll need to write your own
32 bit arithmetic macros. (I'd suggest using 4 bytes of the text portion
of a Q-register for storing a 32-bit datum, rather than wasting the int
portion of two q registers (for anyone not familiar with Teco, there are
36 2-part Q-registers, data areas which can be used for 36 16-bit
variables plus 36 string variables and you can have executable TECO code
as the data in the string variables)). Using a late enough version of
Teco that also has "macro-local Q-registers" accessed as (for example)
Q.1 or Q.b, instead of Q1 or Qb) will greatly ease that limitation by
not limiting you to using just the global Q registers. V36 did not have
this feature. At least V39 and V40 do. (as does the "Almy" Unix TECO
version)
The maximum buffer size shrank from one TECO release to the next as new
features were added. And obviously, the more Q-register space you use
for code and data, the smaller the maximum buffer size will be at any
given time.
As you proceed during coding, it might be a good idea to periodically
check for memory leaks to prevent your server from crashing due to being
out of space. One way to do this is to check if the number of characters
that the buffer can hold shrinks after each EC command.
I don't know the HTTP protocol, so I don't know whether there is a
maximum response size, but for larger responses, you might need to build
part of the response in the text buffer, write it to the output stream,
replace the data in the buffer with the next part of the response, write
that out, and so on (probably using PW and HK commands after building
each part of the response).
[ Afterthought: it might be better to first build response header info
in the text buffer, use the A command to append the first "page" of the
reply, then write the served file using the EC command or one of it's
derivatives. (This approach would reduce the risk of running out of
memory). If you need to make modifications to the file data before
sending it, or if you need to send a trailer after the data, then you
might choose to page through the buffer with P commands before using EC. ]
[ --snip --the rest of this message talked about approaches that have
already been excluded, so I have snipped it ]
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
