<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 07/07/2012 10:09 AM, Johnny Billquist <a class="moz-txt-link-rfc2396E" href="mailto:bqt@softjar.se"><bqt@softjar.se></a>
wrote:
<blockquote
cite="mid:mailman.26.1341688062.1319.simh@trailing-edge.com"
type="cite">What is left is actually writing the code, something
that seems to get much less attention...
<br>
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-western">
<br>
Johnny
<br>
</div>
</blockquote>
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<br>
<br>
<br>
-------- Unsent Message --------<br>
[ --- snip --- Message headers snipped -- snip -- ]<br>
<br>
On 07/06/2012 15:05:38 EDT 2012, Richard legalize at xmission.com
wrote:
<blockquote cite="mid:4FF78182.8010109@dslextreme.com" type="cite">In
article <4FF6AE2C.6050104 at dslextreme.com>,<br>
Michael Bloom <mabloom at dslextreme.com> writes:<br>
<br>
> What aspect of the experiment requires a pdp-11 architecture?<br>
<br>
Desire.<br>
</blockquote>
<br>
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).
<br>
<br>
Even so, with the limits you've chosen, here are a few
considerations:<br>
<br>
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.<br>
<br>
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. <br>
<br>
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 . <br>
<br>
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)<br>
<br>
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. <br>
<br>
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. <br>
<br>
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). <br>
<br>
[ 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. ]<br>
<br>
[ --snip --the rest of this message talked about approaches that
have already been excluded, so I have snipped it ]<br>
</body>
</html>