On 2012-07-08 13:58, Michael Bloom wrote:
On 07/07/2012 10:09 AM, Johnny Billquist <b...@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: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
