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

[Johnny Billquist]

On 2012-07-08 13:58, Michael Bloom wrote:
> 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.

They came after V36. But they are not strictly needed, as you can push 
down Q-registers yourself if you want to play with them without 
affecting someone else.

> 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.

If you run out of memory, you are always in trouble...

> 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 .

Plenty of space for normal stuff. TECO code does not use a lot of memory.

Just checked TECO V40 under RSX, and it claims to use 36 Kbyte. That is 
both code, data, stack, and then 12K set aside for user buffers.

> 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)

Not sure when and why you'd need 32-bit arithmetic, though...

> 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.

Right.

> 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 doubt you'll ever have TECO leak memory. However, you can run out of 
memory, so cleaning up your Q-registers, especially if you know they 
might store lots of data, is a good idea.
(TECOs memory handling is rather simplistic, not to mention well tested 
by now, which is why I doubt you have any memory leaks.)

> 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).

Yes. And that is pretty common to do with TECO under all circumstances.

You will normally start by reading in a request, parse it, generate a 
header, and then dump out a file as a response. The first part is pretty 
small in terms of memory usage.
Dumping out a file is something TECO can do all day long without a problem.
You can either do it page by page yourself, or let teco do it.
There are pros and cons to both. But neither will cause you any weird 
memory issues.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol