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

[Johnny Billquist]

On 2012-07-09 17:29, Michael Bloom wrote:
> On 07/08/2012 09:22 AM, Johnny Billquist <bqt at softjar.se> wrote:
>> On 2012-07-08 13:58, Michael Bloom wrote:
>>> 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 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.
> The whole point is avoiding the need to push Q-registers.  It is all too
> easy to make a mistake when pushing Q-registers that costs you a lot of
> debugging time. If you don't push Q regs, you never have to pop them!
> If you have local Q regs, there is little legitimate use for
> pushing/popping them other than to rapidly copy both parts of one q-reg
> to another q-reg (it's a good idea to use q-regs as two member structs,
> when you can)

Right. Just pointing out that local Q-registers came after V36, and that 
there is another solution for the same problem if you happen to be 
running pre-V40. Having the language help you is a good thing though. I 
agree.

>> Not sure when and why you'd need 32-bit arithmetic, though...
> I'm not sure either, since, as I've already admitted, I don't know the
> HTTP protocol.  But I did want to make a suggestion about long
> arithmetic,  just in case HTTP packets _did_ contain 32 bit fields upon
> which arithmetic might be performed.  With a heads up about this,
> Richard can look for places where this might be needed, and plan
> accordingly. It's always beneficial to strategize how to deal with
> problems prior to dealing with them, rather than just jumping in to
> code, and then figuring out how to "handle each bridge as it is
> encountered".

I can't remember seeing anything that really needs 32-bit arithmetic in 
the protocol.

>> 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.)
> Of course, TECO itself is robust,  but . . .
>
> I was not referring to *TECO* leaking memory, but rather the program
> running /within/ TECO, which may  append to q register space,   push
> q-regs without popping them, or make memory disappear in other ways. If
> you've ever written a reasonably large TECO program (such as the DECUS
> 11-737 package that I previously mentioned),  you've got a good chance
> of having experienced trying to debug a TECO memory leak.  This is the
> kind of place where defensive programming really shines.  As one of my
> college profs was known to say "The main prerequisite for debugging is
> ''bugging''. And especially with a language that so resembles line noise
> as TECO does, avoiding "bugging" takes care.

Leaking memory, to me, implies that it is lost. Just being sloppy and 
not freeing up memory you have allocated and still keeps track of is not 
the same as leaking memory. But yes, keeping your memory usage under 
control is also a good thing.

>> 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.
> I was assuming that Richard planned to take use of the TECO data
> manipulation facilities,  not just use it as a glorified "cat"

Well, the HTTP protocol is almost more or less just a glorified cat...
There isn't that much to it, really.

	Johnny