terminfo and curses
Stuart D. Gathman
from Motorola. We now have to work with a SysV 8000 which has the
"new and improved" curses and terminfo from AT&T.
We have gotten used to having to "compile" the terminal types.
We realize why the capability names are fixed (standardization).
BUT,
A 30K curses program on the 6350 is 60K on the 8000.
A non-curses program on the 8000 is typically 25%
smaller than the identical C code on the 6350
because of optimization.
We cannot use MINI_CURSES because it doesn't support
getxy() and inch(). We don't need attributes, but
if I can't read the screen, I have to keep my own copy! :-(
I thought the new curses was supposed to "nifty", "small" and "fast"?
"nifty" is a matter of taste.
"small" is a lie.
"fast"? It might possibly use less CPU, but it takes twice as long
to load the programs!
BTW,
We also ran curses/terminfo on a Motorola 290 with the
same results.
Is this true for curses/terminfo everywhere else?
--
Stuart D. Gathman <..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>
ricker
> A 30K curses program on the 6350 is 60K on the 8000.
>
> A non-curses program on the 8000 is typically 25%
> smaller than the identical C code on the 6350
> because of optimization.
>
1) I don't know about the differences between a 6350 and an 8000
but, do you know if the compiler is the exact same on both systems?
2) Terminal-independent code is most likely going to be larger than
terminal-specific code. Trade-offs ya know :)
Running terminfo/curses on an altos is not terribly depressing although of
course not perfect.
Guy Harris
> >
> > A non-curses program on the 8000 is typically 25%
> > smaller than the identical C code on the 6350
> > because of optimization.
> >
> 1) I don't know about the differences between a 6350 and an 8000
> but, do you know if the compiler is the exact same on both systems?
From his statements, it seems to me as if he knows that the compiler is, in
fact, NOT the same on both systems - and that it produces BETTER code on the
machine where the "curses" program is bigger!
> 2) Terminal-independent code is most likely going to be larger than
> terminal-specific code. Trade-offs ya know :)
What does that have to do with the price of eggs? He isn't comparing the
size of a piece of terminal-independent code with a piece of
terminal-specific code here. He's saying that the "curses" code
on the 6350 is smaller than the "curses" code on the 8000 - you can argue
that both versions of "curses" are terminal-independent (because they're
use the terminal databases "termcap" and "terminfo", respectively, to guide
their actions). He mentioned the non-curses program just to show that the
compiler is probably not at fault here - the program in question is bigger
on the 8000 because "curses" is bigger on the 8000.
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com (or g...@sun.arpa)
Guy Harris
>
> "nifty" is a matter of taste.
>
> "small" is a lie.
>
> "fast"? It might possibly use less CPU, but it takes twice as long
> to load the programs!
> Is this true for curses/terminfo everywhere else?
I tried building the 4.3BSD "mille" game with both old and new "curses", and
the new "curses" version was about 30K bigger. Comparing the
"termcap"-based "ex" version 3.7 with the "terminfo"-based "ex" version 3.9,
the "terminfo"-based version is about 9K bigger, so most of the 30KB
increase is probably due to curses. CAVEAT: Under SunOS 3.x, program text
and data sizes tend to get rounded up to 8KB boundaries, so there are rather
large error bars around these numbers.
Note, however, that the version of "curses" that was described as "fast and
small" was the System V, Release 3.1 version. The version I used above was
the System V, Release 2 version. The version that you have might possibly
be the S5R3 version, almost certainly isn't the S5R3.1 version (somebody
else may be able to change that "almost certainly" to "certainly" - I don't
think S5R3.1 is released yet); the odds are that it is the S5R2 version. I
infer from what Hansen said that the S5R3.1 version is much changed from the
older S5R2 version (I know there are a number of changes between the S5R2
and S5R3 versions). As such, you should wait until you see the S5R3.1
version before you argue with Hansen's claim that it's "fast and small".