[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[Johnny Billquist]

On 2015-01-01 17:11, Mary Ann Horton<mah at mhorton.net> wrote:
>
> The move was from termcap to terminfo.  Termlib was the library for termcap.

Doh! Thanks for the correction. Finger fart.

> There were two problems with termcap.  One was that the two-character
> name space was running out of room, and the codes were becoming less and
> less mnemonic.

Ah. Yes, that could definitely be a problem.

> But the big motivator was performance.  Reading in a termcap entry from
> /etc/termcap was terribly slow.  First you had to scan all the way
> through the (ever-growing) termcap file to find the correct entry.  Once
> you had it, every tgetstr (etc) had to scan from the beginning of the
> entry, so starting up a program like vi involved quadratic performance
> (time grew as the square of the length of the termcap entry.)  The VAX
> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and
> was shared among dozens of timesharing users, and some of the other
> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.
> It took forever to start up vi or more or any of the termcap-based
> programs people were using a lot.

Hum. That seems like it would be more of an implementation issue. Why 
wouldn't you just cache all the entries for the terminal once and for 
all? terminfo never came to 16-bit systems anyway, so we're talking 
about systems with plenty of memory. Caching the terminal information 
would not be a big memory cost.

Thanks for the insight.

	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

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[Warner Losh]

> On Jan 1, 2015, at 9:21 AM, Johnny Billquist <bqt at update.uu.se> wrote:
> 
> On 2015-01-01 17:11, Mary Ann Horton<mah at mhorton.net> wrote:
>> 
>> The move was from termcap to terminfo.  Termlib was the library for termcap.
> 
> Doh! Thanks for the correction. Finger fart.
> 
>> There were two problems with termcap.  One was that the two-character
>> name space was running out of room, and the codes were becoming less and
>> less mnemonic.
> 
> Ah. Yes, that could definitely be a problem.
> 
>> But the big motivator was performance.  Reading in a termcap entry from
>> /etc/termcap was terribly slow.  First you had to scan all the way
>> through the (ever-growing) termcap file to find the correct entry.  Once
>> you had it, every tgetstr (etc) had to scan from the beginning of the
>> entry, so starting up a program like vi involved quadratic performance
>> (time grew as the square of the length of the termcap entry.)  The VAX
>> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and
>> was shared among dozens of timesharing users, and some of the other
>> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.
>> It took forever to start up vi or more or any of the termcap-based
>> programs people were using a lot.
> 
> Hum. That seems like it would be more of an implementation issue. Why wouldn't you just cache all the entries for the terminal once and for all? terminfo never came to 16-bit systems anyway, so we're talking about systems with plenty of memory. Caching the terminal information would not be a big memory cost.

BSD solved this problem that way: parse /etc/termcap and put all the entries into termcap.db. :)

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150101/ae4a3d87/attachment.sig>

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[Mary Ann Horton]

Quoting Warner Losh <imp at bsdimp.com>:


>>
>>> But the big motivator was performance.  Reading in a termcap entry from
>>> /etc/termcap was terribly slow.  First you had to scan all the way
>>> through the (ever-growing) termcap file to find the correct entry.  Once
>>> you had it, every tgetstr (etc) had to scan from the beginning of the
>>> entry, so starting up a program like vi involved quadratic performance
>>> (time grew as the square of the length of the termcap entry.)  The VAX
>>> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and
>>> was shared among dozens of timesharing users, and some of the other
>>> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.
>>> It took forever to start up vi or more or any of the termcap-based
>>> programs people were using a lot.
>>
>> Hum. That seems like it would be more of an implementation issue.  
>> Why wouldn't you just cache all the entries for the terminal once  
>> and for all? terminfo never came to 16-bit systems anyway, so we're  
>> talking about systems with plenty of memory. Caching the terminal  
>> information would not be a big memory cost.
>
> BSD solved this problem that way: parse /etc/termcap and put all the  
> entries into termcap.db. :)

That's essentially what terminfo's binary files are: a parsed, cached  
version of the source.

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[Erik E. Fair]

"terminfo" - that was the name I was reaching for and couldn't
quite remember (and google-fu failed me)!

The other BSD answer to the "searching /etc/termcap takes too long"
problem (and I recall it being noticeable on the heavily loaded
Cory Hall PDP-11/70 when you used a terminal whose entry was farther
from the top of the termcap file) was to put the termcap entry for
your terminal into the TERMCAP environment variable at login time,
which my .login does to this day - that puts it already in RAM,
ready to go, no banging on the disk required - you only pay for
the /etc/termcap (or, excuse me, /usr/share/misc/termcap in NetBSD
5 - it seems NetBSD 6 finally moved to a BSD-ified terminfo and I
should probably update my .login ...) search once.

	Erik <fair at netbsd.org>

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[Steffen Nurpmeso]

Warner Losh <imp at bsdimp.com> wrote:
 |> On Jan 1, 2015, at 9:21 AM, Johnny Billquist <bqt at update.uu.se> wrote:
 |> On 2015-01-01 17:11, Mary Ann Horton<mah at mhorton.net> wrote:
 |>> 
 |>> The move was from termcap to terminfo.  Termlib was the \
 |>> library for termcap.

 |>> But the big motivator was performance.  Reading in a termcap entry from
 |>> /etc/termcap was terribly slow.  First you had to scan all the way

 |BSD solved this problem that way: parse /etc/termcap and put \
 |all the entries into termcap.db. :)

I like the current approach of FreeBSD: having a super-minimalized
version in /etc and a completely outdated (compared to the termcap
that Thomas Dickey maintains) stale version in /usr/share.

--steffen

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[Peter Jeremy]

On 2015-Jan-02 11:13:28 -0800, "Erik E. Fair" <fair-tuhs at netbsd.org> wrote:
>your terminal into the TERMCAP environment variable at login time,
>which my .login does to this day - that puts it already in RAM,

But you pay for the size of $TERMCAP in every process you run.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150105/e0b501a8/attachment.sig>

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[John Cowan]

Peter Jeremy scripsit:

> But you pay for the size of $TERMCAP in every process you run.

A single termcap line doesn't cost that much, less than a KB in most cases.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
May the hair on your toes never fall out!  --Thorin Oakenshield (to Bilbo)

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[arnold]

> Peter Jeremy scripsit:
> > But you pay for the size of $TERMCAP in every process you run.

John Cowan <cowan at mercury.ccil.org> wrote:
> A single termcap line doesn't cost that much, less than a KB in most cases.

In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
have 32KB to start with.  (The discussion a few weeks ago about cutting
yacc down to size comes to mind...)

On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might
even be paged out, and BSD on the vax didn't have copy-on-write.

ISTR that the /etc/termcap file had a comment saying something like
"you should move the entries needed at your site to the top of this file."
Or am I imagining it? :-)

In short - today, sure, no problem - back then, carrying around a large
environment made more of a difference.

Thanks,

Arnold

[TUHS] termcap vs terminfo

[Mary Ann Horton]

On 01/06/2015 04:22 AM, arnold at skeeve.com wrote:
>> Peter Jeremy scripsit:
>>> But you pay for the size of $TERMCAP in every process you run.
> John Cowan <cowan at mercury.ccil.org> wrote:
>> A single termcap line doesn't cost that much, less than a KB in most cases.
> In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> have 32KB to start with.  (The discussion a few weeks ago about cutting
> yacc down to size comes to mind...)
>
> On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might
> even be paged out, and BSD on the vax didn't have copy-on-write.
>
> ISTR that the /etc/termcap file had a comment saying something like
> "you should move the entries needed at your site to the top of this file."
> Or am I imagining it? :-)
>
> In short - today, sure, no problem - back then, carrying around a large
> environment made more of a difference.
>
> Thanks,
>
> Arnold
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
Even with TERMCAP in the environment, there's still that quadratic 
algorithm every time vi starts up.

[TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]


> On Jan 6, 2015, at 5:22 AM, arnold at skeeve.com wrote:
> 
>> Peter Jeremy scripsit:
>>> But you pay for the size of $TERMCAP in every process you run.
> 
> John Cowan <cowan at mercury.ccil.org> wrote:
>> A single termcap line doesn't cost that much, less than a KB in most cases.
> 
> In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> have 32KB to start with.  (The discussion a few weeks ago about cutting
> yacc down to size comes to mind...)
> 
> On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might
> even be paged out, and BSD on the vax didn't have copy-on-write.
> 
> ISTR that the /etc/termcap file had a comment saying something like
> "you should move the entries needed at your site to the top of this file."
> Or am I imagining it? :-)

No, you aren’t. And iirc, we moved the HP terminal entries to the
top of ours since we got a VAX 11/750, but a bunch of HP terminals
instead of DEC ones for reasons that likely involved graft and fraud
in the procurement office :)

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/bd1cae2f/attachment.sig>

[TUHS] termcap vs terminfo

[arnold]

Mary Ann Horton <mah at mhorton.net> wrote:

> Even with TERMCAP in the environment, there's still that quadratic 
> algorithm every time vi starts up.

Please remind me which one you're talking about? If TERMCAP is
in the environment there's no need to hit /etc/termcap at all.

Or are you talking about something else?

Thanks,

Arnold

[TUHS] pdp11 UNIX memory allocation. Was: termcap vs terminfo (was: I swear! I rtfm'ed)

[Milo Velimirović]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

Bringing a conversation back online.
On Jan 6, 2015, at 6:22 AM, arnold at skeeve.com wrote:

>> Peter Jeremy scripsit:
>>> But you pay for the size of $TERMCAP in every process you run.
> 
> John Cowan <cowan at mercury.ccil.org> wrote:
>> A single termcap line doesn't cost that much, less than a KB in most cases.
> 
> In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> have 32KB to start with.  (The discussion a few weeks ago about cutting
> yacc down to size comes to mind…)

(Or even earlier than ’81.) How did pdp11 UNIXes handle per process memory? It’s suggested above that there was a 50-50 split of the 64KB address space between instructions and data. My own recollection is that you got any combination of instruction and data space that was <64KB. This would also be subject to limits of pdp11 memory management unit.

Anyone have a definitive answer or pointer to appropriate man page or source code?


Thanks,
Milo

[TUHS] pdp11 UNIX memory allocation. Was: termcap vs terminfo (was: I swear! I rtfm'ed)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

Depends the processor.   For the 11/45 class processors, you had a 17th
address bit, which was the I/D choice.  For the 11/40 class you shared the
instructions and data space.  So you had to use overlays and thunks at lot
sooner.

On Tue, Jan 6, 2015 at 2:57 PM, Milo Velimirović <milov at cs.uwlax.edu> wrote:

> Bringing a conversation back online.
> On Jan 6, 2015, at 6:22 AM, arnold at skeeve.com wrote:
>
> >> Peter Jeremy scripsit:
> >>> But you pay for the size of $TERMCAP in every process you run.
> >
> > John Cowan <cowan at mercury.ccil.org> wrote:
> >> A single termcap line doesn't cost that much, less than a KB in most
> cases.
> >
> > In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> > have 32KB to start with.  (The discussion a few weeks ago about cutting
> > yacc down to size comes to mind…)
>
> (Or even earlier than ’81.) How did pdp11 UNIXes handle per process
> memory? It’s suggested above that there was a 50-50 split of the 64KB
> address space between instructions and data. My own recollection is that
> you got any combination of instruction and data space that was <64KB. This
> would also be subject to limits of pdp11 memory management unit.
>
> Anyone have a definitive answer or pointer to appropriate man page or
> source code?
>
>
> Thanks,
> Milo
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/82cc6713/attachment.html>