On Thu, 6 Mar 2008, Olin Lathrop wrote: > sergio masci wrote: > > It's hard to > > justify taking 10 to 20 times longer to produce a program > > I wasn't going to get into this food fight, and was going to silently ignore > that the HLL folks are making the implicit and sometimes incorrect > assumption that assembler takes longer to write. This statement however is > so far into the rediculous zone that I can't let it go. > > Asm only takes "10 to 20 times" longer to write if you compare a good HLL > programer with a incompetent assembly programmer. My own experience, mostly > with Microchip C18, is that it probably takes 20% to 50% longer to do the > same thing in C18 when you look at the full end to end time, including > debugging. I haven't got any hard numbers to back that up, but that's just > a feeling from doing a few mixed MPASM/C18 projects. Maybe it's partly a > perception due to the high hassle factor (C18 does some very stupid things > with FSRs, the data stack, and subroutine linkage that effect the whole > project) and that bugs are much harder to track down in C18. Maybe it's > partly because the C18 code I had to deal with was poorly written and poorly > documented (a old version of the Microchip TCP/IP stack) and had some > serious bugs that were difficult to track down, which isn't helped by the > fact the MPLAB debugging for C18 is much worse than for MPASM. But > debugging is a real and legitimate part of a project, so C18 looses by a > definite margin for me. > > About the only time I can see C to be a win is for lots of wide arithmetic. > It's definitely easier to write a single equation in C than to write all the > various math library calls. However, this kind of code is a rarety in PICs, > and even when it does crop up is just a small part of a project. Writing > that one module in C and dealing with all the restrictions and uncomfortable > conventions that imposes on the whole project is hardly worth it. If it > only takes 10 minutes to write the math calls in assembler, then the best > the compiler can save is 10 minutes. When it comes to low level bit > twiddling, MPASM is easier to begin with. Olin I do not doubt that what you are saying is true with regard to your own personal experience and maybe my "10 to 20 times" is a little off BUT by your own admission you are not an expert HLL programmer you are an expert ASM programmer. Of course your figures will be more biased towards ASM programming. Also you need to take into account that the average programmer will never be a GURU ASM programmer no mater how many year s/he spends programming in ASM. It's like playing chess, you might get good at it but how many masters are there? Also, my figure is scaled, based on my personal experience and my experience of the average ASM and HLL programmer. 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. If I write a stupid expression in a HLL involving the wrong sized variable I will get a stupid result, but in ASM it will most likly crash the app in some strange manner at some later time. Source level single stepping HLL code is a walk in the park compared to single stepping ASM. Then you need to take into account the size factor. BIG HLL programs are far easier to complete than BIG ASM programs. AND lets be fair there are some very big MCUs out there that can take some very BIG programs. Back to the chess metaphor: just knowing some clever moves wont guarentee that you can win the game. Ok so you can generate a few lines of ASM to twiddle some bits faster than you could do the same in a HLL. But it's not about a few lines. Ok so you have this really impressive library of code and macros that will do complex things for you in ONLY a few lines of ASM, but that is exactly what a HLL is doing for you except that a decent compiler will also track simple problems that the assembler is not geared to handle. If you had to employ someone else for a fraction of your salary you wouldn't expect him/her to be as good as you but you'd expect them to deliver and you wouldn't want to waste your valuable time debugging their code. So it makes sense that you would use a tool that would catch their simple mistakes for you. This reminds me of a project I worked on many years ago using the NEC7502 (a 4 bitter). My project leader at the time convinced the boss that we didn't need the NEC assembler. He wrote a bunch of macros for the 8080 assembler that we already had. Each macro was supposed to generate the same machine code as the NEC opcode it was named after. There was this one opcode that was used to perform a jump within a 32 byte page. I had been working on the project for weeks, then one day I started getting some strange problems. After a LOT of work I eventually discovered that this branch macro didn't work correctly when the destination was exactly 32 bytes from the branch and on a page boundry. Ok my time was cheap then but we missed a deadline to get a batch of MCUs mask ROMed and the client was not happy. Regards Sergio Masci -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist