>> 1 and 3 are not really that different, so you're down to two examples. >> C is OK for newer embedded systems (microcontrollers), older ones are >> what they are and ASM may well be the way to go. But even there, ASM >> is often just the lazy way rather than the more economical way. > > perhaps you haven't programmed many microcontrollers. usually the > volumes are high and the per unit cost is very important so you end up > with very simple parts with very little ram/flash. the one i worked on > earlier this year had low speed usb interface, 2 gp registers, 256 bytes of > ram > and 4k of flash. > Well, I look at the AVR and all I see is a form of "bloat" I could have sold my mother-in-law (had I had one) for a few years back. It may not be the paragon of design forsyth would beg for, but it sure is cheap and vast. How much more it would cost than what you chose instead is difficult to determine. To me, it seems PIC users are the masochists.
> i found it easy enough to program in assembly, but i don't think you'd > get very far with c. i just don't think you could fit things into memory. > Oh, well, I recall a C compiler for the 8051... Are you sure you could drive a USB port in assembler? It sounds ridiculously difficult in C, to my mind. And, for the record, I do enjoy the challenge of tight assembler coding, but more like I enjoy running a middle distance than as a means to an end. >> I have a feeling brucee will point out that the gain in efficiency in >> using ASM is insufficient to justify the additional costs in >> complexity and error potential. > > i don't understand the assumption that the only reason to use assembly is > cycle efficiency. > > also, could you explain why this is "lazy"? or why assembly is more > complicated? > Because it's very thin. You have thousands of instructions to keep track of, some of which are not exactly the ones you ought to have used. Because inverting a test is sometimes not as obvious as you think (not everyone knows the instruction set backwards) and, most importantly, because all the "clever" optimisations you added are utterly incomprehensible to the poor sod that comes along to debug or alter your code. I was tought a long time ago that the most important feature of good programming is readability and assembler certainly has none of that built into it. > clearly, an assembly is more difficult to wield than c. but you don't > use them for the same thing. > Well, many would disagree. It has been stated with good cause that C is a portable assembly language. If you believe as I do that Unix's great step forward was coding the kernel in C almost entirely (I learnt assembler on the Univac 1100 series, the OS was entirely written in assembler and so were the few compilers it came with), then the role assembly plays is bound to be restricted to the few features that cannot be expressed directly in C. > this absolutist argument that c is teh bomb. asm suks is silly. it's like > arguing bicycles and ferraris. which one you need (and which one gets > you there faster) depends on what you're doing. > Nah, you read us all wrong. Assembler is what the engineers chose for us to use. I found the Intel x86 assembler totally frustrating because I had cut my teeth on the Univac. I eventually became familiar with it (thank you IBM for publishing the BIOS code for the PX/XT), but there's no way I could have or would have followed Intel into the i386 and later instructions set. I do know that what Plan 9 does in splitting the compiler and loader differently from the "obvious" boundary of C code and assembly code is very sensible and far better suited to a programmer. Certainly, the loader now needs to contain a lot of savvy about the target architecture (curse those engineers once again!), but it's a specialised location for it and only a few boffins need to get involved in it. What we are all talking across each other about is that our benchmarks have grown bloated, specially software in common use. GCC leading the pack, we have enormous "packages" to perform tasks that would be better done with a handful of minute tools instead. But the obsession with combining and controlling everything within one place is blinding us to the fact that we are creating complexity purely out of habit. That's the "lazy" I mentioned earlier, it is easier to do it with that tiny, sharp scalpel, than to sharpen the chisel first that would save you effort in innumerable future operations. When the scalpel is an existing assembler and the chisel is GCC, I sympathise entirely, but that does not make assembly code superior to C. Etc. I could go on and perhaps I ought to, but it's too easy for me to get lost in a topic. ++L
