Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!MITCH.ENG.SUN.COM!wmb From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley) Newsgroups: comp.lang.forth Subject: Re: size of C Message-ID: <9101140254.AA12027@ucbvax.Berkeley.EDU> Date: 12 Jan 91 19:19:49 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Mitch Bradley Organization: The Internet Lines: 48 > 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