🚀 go-pugleaf

In article <257@BMS-AT.UUCP> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes:
>	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.

> >	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?

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
	guy@sun.com (or guy@sun.arpa)

> 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!
> ...
> 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".
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)