On 07/08/2012 09:22 AM, Johnny Billquist <b...@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
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
