Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!BRFAPESP.BITNET!UNBCIC
From: UNBCIC@BRFAPESP.BITNET
Newsgroups: comp.lang.forth
Subject: Size of C (Sorry for the last non-edited message)
Message-ID: <9101082223.AA21564@ucbvax.Berkeley.EDU>
Date: 8 Jan 91 21:13:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 35

> Try recoding your 'hello world' program using a call to the
> print to screen interrupt in the bios.
I can't if I want portability (I, if I'll use C, I want). Could write it with
putc, I know...

> Printf() is notorious for including a lot of formatting code. The libraries
> you use determinea lot about how big your program is in C. How big would
> your floating point wordset be in FORTH if it had equivalent functionality
> to the QuickC library?

See, when I can, I prefer to work with Turbo Pascal, because it puts in your
program only what you need. The main problem here is that, although there is
nothing in the standard that says that C need to link all the library, the
compilers in the market usually does. And the libraries are BIG.

Well, I don't think of this as a problem. If I am working in C, size definitly
don't bother me. If size is problem, I work with TCOM, a Target Compiler, by
Tom Zimmer, that produces really small code (in fact, the main problem using it
it's that it only produces COM files). And if some day someone begin to produce
threaded C (with the size effects), then I'll chose to write my own C in Forth,
and have both of them.

> I guess the point is this: C can be small too, if you take the correct
> steps.

No, that's not the point. The point is that programs in C are, almost ever,
very big.

                              (8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET

P.S.: By the way, you can say to the target compiler where to generate the
code... If think it wouldn't be hard to write an overlay manager for it.
Anyone?