> In ASM you can have the most wonderful, clean piece of code, yet a small > illusive bug will bring it to it's knees. And finding that bug can be a > real nightmare even for the person that wrote the code. In a lot of cases > an experienced ASM programmer will get 99.99% of the code working properly > very quickly and it's the last 0.01% that causes all the problems. Have you ever seen a C code where a using a single "=" instead of "==" caused a serious bug? A many sr. reviews the code but no ones spotting that? Have you ever seen a variable with a wrong size / signed-unsigned etc silently compiled but caused problem? Hard to spot these too. Or a semicolon after an if or a while? A missing zero termination or an improperly used / calculated pointer? These are just couple of common mistakes popped into my mind, but look at the PC side or even bigger servers. Most of the problems including exploitable codes, buffer overflows etc are existing because of the C language (and because of architectural reason but that's another subject). And again, this "statistic" with the 99.99% of the code working properly, that is again a non-language related issue (including asm). With ASM using macros you can reduce the chance of a mistake and increase the maintainability of the code. I do not like writing down a snipplet twice, I rather put it into a macro and instantiate it using parameters. When something turns out just have to fix it in one place. And if that macro is in a collection INC file then all the project automatically can be fixed at once. Just like any other language you would do including C# / COM object / .NET or an Activex, whatever you use. The two things are considarable for me is the existing libraries and downloadable examples, and the other thing is what Wouter pointed out. He said it is easier to write down this: z = sin( x->a[ 9 ] + y[ i ]->b ) then thinking in reverse polish logic and using macros/functions and low level instructions to pick up the data. I do not know, for me it is no problem to pick up any languages quick, used C just too many years, used Pascal for quite a few years too, even SQL sometimes but my favourite is still Assembly no matter what platform or operating system (or without os) used. I can't tell you why, probably it is much more fun, or maybe because I could fit into a 10F202? :-) Tamas On Fri, Mar 7, 2008 at 5:55 PM, sergio masci wrote: > > > On Fri, 7 Mar 2008, Olin Lathrop wrote: > > > sergio masci wrote: > > > It is far easier to > > > make a HLL program work even when it is a mess than it is to make an > ASM > > > program work when it has an illusive bug. > > > > I completely disagree. A mess in any language is a mess, and worse than > > clean and well documented code in another language. > > Unless the other language is ASM :-) > > I have seen very big horrendous programs written in C that were easily > fixed by compensating for a problem rather than fixing the underlying > cause. You don't even need to take my word for it, just go and grab some > opensource code (prefably a big project) that is at least 5 years old and > still actively being "improved" by a lot of people. You will find that > every so often someone will take it on themselves to re-write what has > become a horrible mess and in the process produce a new package. > > In ASM you can have the most wonderful, clean piece of code, yet a small > illusive bug will bring it to it's knees. And finding that bug can be a > real nightmare even for the person that wrote the code. In a lot of cases > an experienced ASM programmer will get 99.99% of the code working properly > very quickly and it's the last 0.01% that causes all the problems. > > > > > > Source level single stepping HLL code is a walk in the > > > park compared to single stepping ASM. > > > > This is again completely contrary to my experience, at least with MPLAB, > > MPASM, and C18. Debugging C18 with MPLAB is a very frustrating > experience, > > whereas the MPLAB debugger works very nicely on MPASM code. > > Modern high level debuggers make debugging C more like debugging > interactive BASIC used to be. You can set watch points on *variables*, > breakpoints on *statements*, conditions to look for. You can step through > the source code one statement at a time and look at the consequences. > There is no need to combine the values of seperate memory locations on > paper to see what the value of a variable is, no need to try to decode > stack relative locals yourself. > > If you are having such a bad time debugging C18 programs I would suggest > that the debugger is at fault. > > Yes you can easily single step through machine code using something like > MPLAB, but this is nothing like single stepping though source statements > in a HLL. It requires far more time and great attention to the smallest > detail - you're virtually running the simulation in your head and > comparing it to what the program is actually doing. Let's be fair, > it's a lot easier to simulate a single complex HLL statement in your head > than the equivalent tens if not hundreds of ASM instructions :-) > > I offten advise people NOT to try to learn to program in C on an MCU > because it is far more difficult than learning on a PC. > > Regards > Sergio > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- Rudonix DoubleSaver Did You Know that DoubleSaver is Smaller and More Powerful FailSafe Device than Any Other You can Get? http://www.rudonix.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist