dgary@ecsvax.UUCP (07/05/84)
title: DeSmet C internals - interesting discoveries newsgroups: micro.ibmpc, net.micro.pc, net.lang.c The following summarizes my most important discoveries about Mark DeSmet C's I/O routines: 1) exit(), putchar(), getchar(), puts(), ci(), co(), and csts() are permanent parts of the startup code and you will save no space by writing your own. The startup code also contains some of the memory management stuff. 2) bind includes all .o files listed on the command line in the output .exe file, even those containing no routines needed by the main program. 3) When .o files are combined into a library (.s) file, each of the original .o files is treated as an indivisible unit. If (and only if) bind needs a routine from a library, it brings in the whole unit. Moral is to keep your .o files small and collect them into libraries. 4) The CREAT2.C file on the "Hacker" disk ($25 from CWare, reviewed in a separate posting) contains DOS 2.x routines. Compiling CREAT2.C and using bind foo.o ... creat2.o will produce an .exe file that will only work under DOS 2.x. It may or may not be smaller than one linked without creat2, depending upon whether you use printf(). Anything that uses printf(), scanf(), or even sprintf() or sscanf() seems to drag in the whole DeSmet i/o library (including the bisexual DOS 1&2 routines and probably his memoirs) and will be a minimum 6K. A program to print "Hello" will be 1.5K using puts(), 6K with printf()! Programs doing file I/O that use CREAT2 and avoid printf() can save as much as 3.5K. 5) The documentation is right: getchar() can't handle redirected input very well. (This is because DeSmet uses the "old" DOS calls for getchar(). The ISETUP.A file on "Hacker" shows a conditional DOS 2.0 call, but it is commented out with no indication why.) You can get working redirection by using the macro "#define getchar() getc(stdin)". For several reasons, including space, I'd suggest going to this only when I/O redirection is actually anticipated. Try it. 6) Like a lot of very fine programmers, DeSmet would not last 4 seconds in a spelling bee against a parakeet. The publisher is CWare, PO Box 710097, San Jose, CA 95171-0097; phone (408) 736-6905 9am-1pm Pacific time for orders or technical questions. As usual, I have no connection with this firm except as a customer.
nather@utastro.UUCP (Ed Nather) (07/10/84)
[]
One discouraging thing I have encountered using DeSmet C is the *very*
slow I/O when using stdin and/or stdout. To test this, I compiled the "copy"
program from page 15 of K & R using DeSmet C, and then ran it on a 4100
character file. It managed to copy the 4100 characters into another disk
file on hard disk in 47 seconds (!). I compiled the same exact code on the
Computer Innovations CI-C86 compiler, then ran it on the same 4100
character file. Time: 4 seconds, 12 times faster than DeSmet.
I'd like to see DeSmet successful, since his price is right and you get a
lot of bang for your buck. But you have to wait a lot for I/O.
--
Ed Nather
{allegra,ihnp4}!{ut-sally,noao}!utastro!nather
Astronomy Dept., U. of Texas, Austin