| ??? 07/21/09 05:42 Read: times |
#167640 - One has to be prepared. Responding to: ???'s previous message |
David Prentice said:
Richard Erlacher said:
It means attention to detail at the lowest level, and that's where the process often breaks down. The reason I repeat, time and again, that one who can't program a task in ASM can't program it, is that ASM forces the programmer to concern him/herself with the lowest-level details. One who's learned to do it in ASM recognizes those low-level details and ensures that they're properly dealt-with before considering his work complete. It's easy to overlook lowest-level details when the language allows you to do that. RE I have been vaguely following this thread, and come to various conclusions: 1. RE has not used Keil C. (personally, I have only ever tried the evaluation) 2. RE has not written a full application in C of any flavour. Even the comments about SDCC do not ring quite true. 3. RE is an excellent ASM programmer of 8051 and probably several other obsolete micros. 4. RE has not ever "seriously" used a PIC, AVR, ARM, Renesas, ... Now, that's not quite the case. I've written a few pretty serious app's, a number of simulators and a couple of assemblers, linkers, and loaders, but that was back in the days when Turbo C was new. Prior to that, I used Turbo Pascal, when it was new. I've also written a few pretty neat simulators in Prolog with pieces in 'C'. All that was on the PC, and back in the mid-late '80's. I've only done a little 805x (Maybe 500k lines) programming, in ASM, since most (>90%) of my programming was on other micros, before Windows and much of it before the PC. I have fiddled with the PIC, disliked the AVR from the get-go, and haven't had to program the ARM because I had a software team. My role with ARM stuff has been mostly hardware and as project manager. Is Renesas a microcontroller? I thought it was a software house. I did look at their compiler at one time. Different architectures and platforms suit different applications. However fond one may be of one micro, it does not mean that it is always the ideal solution. Of course one's preference is to use the familiar platform if at all practical. I've painstakingly avoided the Intel processors after the 8048 because of Intel's fondness for making signals that should have been negative-going, the other way around, e.g. RESET, NMI, IRQ, etc. Having those signals referenced to a variable supply during power-on always seemed silly to me. My work has been mainly with Zilog, and Motorola architectures, with a few others thrown in, but mostly Motorola (now Freescale). I did use TI DSP's some of the time. There's practical reason for my antipathy toward Intel's parts, though. I see no problem with mentioning HLL's or other micros. It may well be that the sheer topic invites an elegant 8051 solution.
A clearly thought out design is far more important than a messy ASM code. You can't assume that just because it's ASM, it's messy, nor can you assume that just because it's HLL, it well-structured and well organized. And those cell-phones with a limited market life evolve into the next generation. That's exactly why they're never going to improve. If only they'd fix the %$#@! things ... Code re-use becomes essential as systems get bigger. Einstein would struggle with porting or maintaining systems of that size in ASM. I've seldom had an 805x app much larger than 5k lines, aside from table space, though some of those have had difficulty fitting in 32kB. Once you've bought the extra code space, you might as well use it. David.
I've been preaching some of this stuff, not so much the 'C' vs ASM argument, but the "understand your processor and hardware, and system requirements, before writing code" stuff. It's just simple preparation. RE |
