Clarence Verge wrote: <snip> > > And I have to comment that the examples Cristian has provided here and > in a previous message obviously make a case AGAINST "C" by a programmer > familiar with that language. Possibly SO familiar that they are even > worse than the average "joe" would do. >
First of all, I have to say I'm not as devoted to C as you thinks. In my line of work I make use heavily of assembler, because I often have only 8 kbytes of code space and 256 bytes of data space to play with. This is the memory size of a AT89C52 microcontroller. Using Assembler is a matter of survival here. But there are some reasons for I still have to use of C. 1. Floating point calculus. (i.e the K thermocouple voltage - temperature curve is a 9-th order polynomial function with weird coefficients). 2. Short development time. I have to accept the compromises, otherwise... :-) 3. Portable code. I can reuse whole chunks of code written for 8051 in an application using AT90S8535, for example. See 2. Bear in mind that the C compilers intended for such small devices are very hard to be defeated by hand made assembler, when it comes to ordinary programming techniques. Also, the overhead due to the startup library code is very small (20-30 bytes). All standard library functions are usually written in Assembler, including the floating point library. This makes it possible to squueze 30 kB or more of source code into less than 8kB machine code. And interfacing with Assembler is very handy and well documented Don't ask me about their prices. A complete set of development tools (including cross-compiler, assembler,linker/librarian, IDE, simulators/debugers, maybe development boards), can reach thousands of bucks in price. Fortunately there are also cheaper solutions. See http://sdcc.sourceforge.net for a nice multi-target (Z80/8051/AVR/PIC) cross-compiler. > ...Possibly SO familiar that they are even > worse than the average "joe" would do. I have no idea how an average Joe would have written that programs. All I know is that using an approach similar to Pascal or Basic like this: #include <stdio.h> int main(void) { unsigned char sir[]="Hello World\n"; unsigned int i; for (i=0;i<strlen(sir);i++) // for i between 0 and string length putchar(s[i]); // print the "i"th character in string // i++ means "increment i after use" // \n means 0AH.(newline) // a string ends always with // 0 (null - not seen but it is there) } lead me to dozens of lines of assembly code on GCC (Linux). So, the key is how the programmer designs its code. The clasic "Hello World" was too simple. Both Gcc and your code make use of a ready made function here. Both you and make room in the memory for the "Hello world" string, the same way. Both of them pass the address of the string as a parameter to the respective function. The only differece is that "printf" needs the address of the string to be pushed onto the stack, while DOS INT 21H service 09 requests the address of the string to be loaded in DX (inside a bigger program it would be necessary to save the contents of DX before triggering INT 21H by ... pushing it onto the stack). (Note that INT21H is vectored to the DOS API function calls table. It works only in DOS. and real mode I don't know for sure, but when I was a student at the Polytechnical University in Bucharest back in 1991, BIOS INT10H service 13 was working, too. :-)) My goal was then to see how GCC handles loops. I "stretched" the "Hello World" program a bit, by making it print the string char by char in a tight loop. I made use of a single pointer, and tried a few variations to see which gives the tightest code. I noticed that the "for" loop gave worse results than the "while" loop. I took the two "while" based little chunks of code and sent them to the list for comparison (I'was a little selfish here, boring all the list members with that Computer Chinese and I apologize again). So, you see, I believe I am not unaware of how I write my code :-) I think GCC does a really nice job for a C compiler. I was impressed by the way it handles the stack, and the solutions it finds for handling local variables in registers. I noticed the way it increments/decrements pointers, considering the fact that 386 has a linear address space. I also noticed that the dedicated x86 string instructions were heavily used (gcc inlined the "strlen" function in the above example). > > And in learning ASM the newbie will (MUST) learn about the hardware > while the higher level language (C, Pascal, Forth, APL, Basic, Fortran > etc.) is just another exercise in grammar with no connection to the > root of the job. IMO.<g> It is very good to learn about hardware, in particular about microprocessors, but only when your line of work is related to these. I had to learn 8086 ASM at some point, even if I don't use it. Like I said before, I do use other kinds of assembly language. But I don't see the point in learning ASM, when his job is to develop, let's say, multi-tiered database applications. He'll face another sort of problems Cristian Burneci
