| ??? 08/18/09 13:25 Read: times |
#168378 - That's not how it works Responding to: ???'s previous message |
Per Westermark said:
Richard Erlacher said:
A competent ASM programmer can do the job, given a reasonable macro-assembler and the same experience that a 'C' programmer would require, just as fast... How can you say that, if you haven't spent significant time (with competent here, I assume someone who have spent year(s) in the relevant field) writing both assembler and C applications for the similar type of problem? I can say that because much of the code I've worked on was written in ASM 20-30 years ago and the product is still in operation being used as intended, and simply required a bit of upgrading to add or support additional equipment or features. I've spent plenty of time with HLL's, just don't use HLL with micro-controllers. A macro may be good for copy-paste problems. But when you implement real algorithms, the regular lines of code suitable for copy-pasting, macros or similar normally represents a tiny fraction of the time needed to implement the algorithm. It's just like instantiating a function. It's not just copy-and-paste, though folks who've never used a macro-assembler wouldn't know that. The C compiler is not comparable to a strange macro assembler, where a C expression will map to a fixed code expansion. What do you mean by "strange" macro-assembler? Do you simply mean one with which you're not familiar? Isn't it the same when you switch compilers? And maintenance costs are representing a big part of the total costs for a product that is expected to live for a number of years and receive regular feature updates. Few embedded applications are just sequences of lookup tables with hardly any code in-between. And a number of studies have shown that the amount of work needed to understand source code depends on the amount of text needed to implement an algorithm. One C source line can map to many assembler lines, giving a higher code density - more work done in relation to the effort needed to understand the code. So you believe that moving from an 805x to a M68-something or a PIC would simply be a matter of plugging the same code into a different compiler? I guarantee you that wouldn't be so easy if you've used Keil's product. BTW, the purpose of tables isn't just to take up space, but to avoid having to implement complex algorithms that can be solved with table-lookup, which is often the case. It's always larger but MUCH faster, and extremely easy to debug. It's not easier to implement in HLL than in ASM, though. Don't forget the microcontroller task: Examine inputs (including current context) and take appropriate action. What simpler method than table-lookup could there be? Current context defines which tables are used, and current inputs determine which entries in the tables are used ... most often there's no stack usage, and minimal code space consumed. RE |
