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

[Michael Bloom]

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)
>
> If you run out of memory, you are always in trouble...
That's why defensive coding is especially important with as memory space 
as TECO has
>
> 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 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.
> 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"
> There are pros and cons to both. But neither will cause you any weird 
> memory issues.
Yes, it's how you program that determines whether you reclaim memory 
that's no longer needed, or not.  Local Q-regs allow de-allocation to be 
automatic when you leave a macro, eliminating a source of coding errors 
that can result in "weird memory issues".  That was why I made a 
reference to "alloca()",  since local q reg's effectively allocate their 
space on the TECO program's execution stack.  With a C program,  if you 
allocate memory within a routine that you subsequently exit without 
without saving or freeing the allocated space,  you get a memory leak, 
but memory allocated with alloca() is automatically freed.  Same thing 
with Local Q-regs.  When you leave the routine they belong to, "poof" 
they are gone.

  michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20120709/082bca07/attachment-0002.html>