UNBCIC@BRFAPESP.BITNET (01/09/91)
> 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?
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (01/09/91)
> > Printf() is notorious for including a lot of formatting code. ...
Most C implementations only include the library routines that are
actually used. The problem with printf() is that it is supposed to be
able to handle a variety of different number types, including floating
point numbers. The determination of which format to use at any given
time is made by a string argument that can be constructed at run time.
Therefore, the linker usually does not know whether or not the floating
point libraries are going be be needed or not, and the implementor often
chooses to err in the safe direction.
In the C "wrapper" programs that I use for interfacing Forth to various
operating systems, I avoid printf(), instead using puts(). If I need to
display numbers, I write my own "puti()" routine.
The trend in operating systems is going toward shared libraries, so the
size of printf() is beginning to cease to matter, as a single copy of the
library is shared among all the processes in the system.
Mitchcwpjr@cbnewse.att.com (clyde.w.jr.phillips) (01/11/91)
In article <9101100302.AA08161@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: > > > Printf() is notorious for including a lot of formatting code. ... > > Most C implementations only include the library routines that are > actually used. The problem with printf() is that it is supposed to be > able to handle a variety of different number types, including floating > point numbers. The determination of which format to use at any given > time is made by a string argument that can be constructed at run time. > Therefore, the linker usually does not know whether or not the floating > point libraries are going be be needed or not, and the implementor often > chooses to err in the safe direction. > > In the C "wrapper" programs that I use for interfacing Forth to various > operating systems, I avoid printf(), instead using puts(). If I need to > display numbers, I write my own "puti()" routine. All this says is that efficiently coded ( sizewise ) "C" is nonstandard. What good is a standard "C"? About as good as a standard FORTH! > > The trend in operating systems is going toward shared libraries, so the > size of printf() is beginning to cease to matter, as a single copy of the > library is shared among all the processes in the system. Isn't this the essence of a well factored FORTH? The basis for shared code is adequate factoring to allow all "custom" versions to utilize the most standard words/subroutines? > > Mitch --Clyde
chip@tct.uucp (Chip Salzenberg) (01/11/91)
According to cwpjr@cbnewse.att.com (clyde.w.jr.phillips):
>What good is a standard "C"? About as good as a standard FORTH!
Hardly. Printf() and friends need not be huge. The fact that many
implementations do a poor job of factoring withing the system library
says much about the implementors but little about the language.
--
Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
"If Usenet exists, then what is its mailing address?" -- me
"c/o The Daily Planet, Metropolis." -- Jeff Daiellwmb@MITCH.ENG.SUN.COM (Mitch Bradley) (01/13/91)
> Printf() and friends need not be huge. The fact that many > implementations do a poor job of factoring withing the system library If you exclude the floating point conversion formats, printf() isn't very large. The difficulty of factoring printf() is that the linker doesn't know which arguments are going to be passed to printf() at run time, so it must include code to support all possible output formats in every program. The real catch here is the floating point output formats, especially in systems that attempt to automatically and transparently support several different choices of floating point hardware, as well as software floating point in case there is no floating point chip on a particular machine. "Generic" floating point libraries can get rather large. Some implementations try to infer whether or not floating point printf() support is needed by whether or not floating point values are declared within the program, passing the information to the linker through some magic symbol (e.g. FLOATUSED). Even this has problems; suppose I write a program that accepts a hex number and a format string from the user, displaying the bit pattern represented by the number according to the user-supplied format string. Of course, there are ways around this, but then the implementor has to document the "funniness", etc. There is an analogy with Forth here. printf() is an interpreter; the format string it interprets may be constructed at run time, thus the implementation must carry around support for the complete language that it interpreter. Similarly, a Forth application that allows the user to type in arbitrary Forth commands must include the full interactive interpreter and all the supported words, whereas a "sealed" application that happens to written in Forth may be "target compiled" or "turnkeyed", removing any words that are not used by the application. > says much about the implementors but little about the language. It may say that a particular language feature is tricky to implement, to the extent that many implementors don't do a great job of it. If the market for something is big enough, then there will be enough economic activity and competition to result in good implementations, despite any difficulty. That's why there are a lot of truly great PC applications, despite the weaknesses of the processor architecture. Forth is so easy to implement that even relative novices can do it; this is both a strength and weakness. Mitch