Your findings are more likely to be a comment on the person who wrote the assembly than they are on the language or processor used.
I've taken 150KB PIC assembly programs and rewritten them into 100KB C programs that have more functionality and better performance than the original code. The only conclusion that I can draw from that is it's possible to write bad code in any language.
-- John W. Temples, III
it
Another conclusion is that it is a lot easier to write bad code in assembler.
Nobody in his right mind uses assembler for application level stuff and even for most what is below it. It is a total waste of time, which is better spend at improving more quality/functionality/performance etc.
ASM is dead.
-- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)
Which only proves you can write ineffecient code even in assembler.
Like I said, if you don't know the answer you have no business writing embedded code.
Ian
No, you are probably working at the bleeding edge of performance and unit cost.
The only important thing is to use the best tool for the job. Why deny yourself a hammer and nails just because you have screws and an electric screwdriver. Remember the nail gun.
Ian
You are of course entitled to your opinion. Unfortunately there are a large number of products out there that prove you wrong.
Ian
Or perhaps that ANY typical code can benefit from a 'top down' rewrite, after it is finished ?
Assembler code tends to 'grow over time', with more focus on details and 'don't break it' caution - so it is no real surprise that projects can shrink when re-coded.
common sense: use the highest level tools that will get the job done.
-jg
I'd rather prefer it to be a comment on the person who wrote the C code ;-)
Looks like you are talking about source code and not object code. Would be more interesting if you managed to reduce the object code for the PIC by programming in C.
It then follows that you do want to write in C and not in assembler partially answering the original question.
Maybe PIC programmers are ghouls ?
Webster: "An beeing that is supposed to feed on the flesh of dead things" "A person who performs horrible acts or enjoys loathsome things"
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Actually it was more of a bottom up exercise to understand the customer code, and why it did not work.
I think the most interesting thing about it was that it was possible to do such a shrink on a program less than 1 kB. If a 1 kB program is best written in C, then asm has no future...
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Like Brookes said "Plan to throw one away; you will anyway".
--
Grant Edwards grante Yow! ... or were you
at driving the PONTIAC that
visi.com HONKED at me in MIAMI last
Tuesday?
Brooks.
Not sure where that "e" came from...
--
Grant Edwards grante Yow! My LESLIE GORE record
at is BROKEN...
visi.com
No, those are executable code sizes.
Not only was the executable code size reduced, but also the amount of hardware. The assembly code didn't fit into the 128K PIC and used external EEPROMs to store its UI data structures (hence its 150K total size), and used a second small PIC to decode an RC5 stream. The C rewrite eliminated the EEPROMs and did the RC5 decoding, eliminating the second PIC.
-- John W. Temples, III
In article , Frank Bemelman writes
Well that is plain wrong.
Wrong again.
Replaced by what?
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Such a sweeping statement needs to be qualified, lest the novice think they do not need to learn assembler.
Certainly, one should not code a whole project in assemler, without having a very good reason for doing so.
However, using In-Line assembler, or Assembler modules, or reading assembler listings to optimise/debug code are all expected skills from an embedded designer.
I liked the approach Freescale took with their new RS08, where they effectively kept throwing stuff overboard, until the device could (just) run a HLL. They have also got some lading edge hardware in their, like sub uA oscillator, and a ~1uA regulator, so they can do 1.8-5.5V.
-jg
shhh...Don't tell the ASM haters that they are wrong! They will take it personally :).
-Isaac
Anyone who writes 150K of PIC assembly should really be in an asylum.
Ian
The problem of writing such large programs in assembler, for any platform, is that you can not constantly keep the whole system in your mind and do global optimisation for the whole program all the time.
IMHO, when the program size is only a few KiB, you can constantly be on the alert in assembly programming, but for programs larger than that, things get too complex for the human mind and the code quality starts to deteriorate.
--- There are of course similar problems in high level languages. In large programs, with multiple compiled modules linked to a single executable, each independently compiled module needs to have consistent interfaces and assume that it can be loaded to any address by the linker and may require extra code for page/segment handling etc. However, if all sources could be compiled at once and directly generate an executable file, much of the redundant can be eliminated.
The same apply to functions in a compilation unit in which a lot of work is required to pass parameters to functions. However, if the compiler supports in-line functions, all (in-line) functions used only once can be expanded by the compiler, before it starts to optimise and generate binary code.
With a very modular programming style and a compiler that does not do explicit or automatic inlining, the generated code from the high level language can be very bloated.
Paul
And I've taken code (written by me) that was around two thousand lines of AVR assembly, and re-written it in C. The resulting object code was maybe twice the size, and the critical sections were 5 to 10 times slower. It still made sense, because the resulting C code was to be used in a bigger application where the rest was in C. But for the original simple system, a swap from assembly to C lead to significantly higher average current in the card.
There are things you can do in assembly that you can't do in C. There are things you can do better in assembly than C. There are types of code that are easier and clearer to write in assembly (assuming you are not dealing with PIC assembly) than in C. There are other types of code that a half-decent C compiler will compile more efficiently than hand-written assembly, since the compiler does not need to have to generate maintainable and debugable assembly. And it will all depend on the compiler and the target.
C is a better all-round choice than assembly for the majority of embedded programming, but it's certainly not *always* the best choice.
The motor-antenna on my Mazda 323F stopped working a couple of weeks ago, it only made very unhappy noises. I bought a new antenna and replaced it. Just for fun, I took apart this 10 year old antenna, to see what cutting edge of unit costs meant in those days. I found a 3"x4" PCB with a nice H-bridge on it, a cmos 4000 family chip, and a little microcontroller with external resonator. And about a dozen or two of other smt parts, resistors and caps.
A simple cell phone these days has more processing power than the first PC's....
Good point, well said. No harm in keeping memories ;)
-- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)
"Chris Hills" schreef in bericht news: snipped-for-privacy@phaedsys.demon.co.uk...
code.
likely
entirely
It is just a guess.
30 years ago, >99% of embedded programming was done in assembler. Today it is probably less than 1%.I don't know. The image in my crystal ball is still blurred. I expect that it will become much less of a job to turn an idea into a product.
We already see that chip vendors also provide the tools to program their stuff. We also see that they include large libraries/drivers to support the goodies that are integrated on the controller chip. The glue we use doesn't need to be C. In 15-20 years, the glue will be a scripting language, something like php or whatever the toolchain for your chip offers.
But there will always be a few folks around who refuse to go with the flow, which inspired me to make that comment about the +75 retired guys.
-- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)
I'll rephrase it then so it is a little clearer for you.
'Unfortunately there are a large number of products out there, DEVELOPED IN THE LAST COUPLE OF YEARS, that prove you wrong'
IAn
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.