[Simh] smallest pdp-11 that can run TECO and sockets(*)?

[Michael Bloom]

On 07/07/2012 10:09 AM, Johnny Billquist <bqt at softjar.se> 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  ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120708/397eed11/attachment-0002.html>