Hello Wilco,
Ok, got me there. If it really does produce machine code that runs in under 30 cycles on a 16-bitter it is indeed as good.
Once when I asked a C-programmer that I needed something like this and gave him a rough sketch in assembler he frowned and said he'd have to sow that in as inline assembler. Looks like he could have done it in C.
Hey, now I am slowly warming up to C even though I am a HW guy :-)
-- Regards, Joerg http://www.analogconsultants.com
Hello Frank,
Yeah, Wilco showed me.
Not dead at all. There are cases where you must be sure to control something in x machine cycles plus/minus zero. But that would be more like using the uC as a logic chip.
Ok, ok....
-- Regards, Joerg http://www.analogconsultants.com
No most of these were written first in highly optimized assembler. It is a good idea to have a C version of all your assembler code and so I created C versions and got code just as fast/small.
Nowadays I first design an algorithm in C, test it and optimise it to the limit. Then write it with source line per instruction and check whether the code is efficient enough. In most cases it is, but for the last 10% I translate to assembler.
This way of writing assembler code is actually much quicker than writing assembler code from scratch. The result is faster too...
I you agree that he proved that, it follows that any piece of assembler code can be written in C and be *just as efficient*.
Wilco
"Joerg" schreef in bericht news:IlVWg.21517$ snipped-for-privacy@newssvr14.news.prodigy.com...
Generally speaking, my dear. I know about cases where a 74HCT74 beats every processor no matter how clever you program it.
Hey, I shouted *years* ago on this newsgroup "asm is dead". Seems there is a little bit more concensus now.
Now I could start shouting about C is dead, use C++ instead, but I think that is too much for today.
-- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)
Thanks Walter. I'd suggest you take the automatic validate output, and put this on your web : a good example of a 'picture' is worth a thousand words.
This would be very useful to many users. Those looking at new cores, and those looking to soften the boundary between ASM and HLL. In-Line ASM is OK, but it can be cumbersome, and your examples allows users to code in 'high level assembler' if they want to.
-jg
Hello Frank,
Check out stuff like the AUP series. That really rocks.
I don't know anything about C++ so I can't comment. However, about 20 years ago I was told in similar fashion by numerous engineers that the CD4000 logic series is dead. I am still designing new stuff with it and they even came out with small packaging :-)
Then we were told that stick shift in cars would be dead by the early
70's yet I had now problem buying one in 1997 and could purchase a new one today if I wanted to.-- Regards, Joerg http://www.analogconsultants.com
Hi Joerg,
actually compilers typically come with optimised math functions, apart from variable read/write there is not much to improve there. The main disadvantage of C is that it is human unfriendly, compared to a good and flexible enough assemler with sufficiont library code at hand it compares like a hieroglyph based language to an alphabet based one. The x10 factor does not come out of what the compiler does alone, I never said that; it comes mostly of what the human does using it. Some assemblers are not as good as C - say, native RISC like PPC - but others are. I am clearly biased to my VPA, which looks much of the time like a 68k/CPU32 assembler, although it has long since gone much beyond that, and can do complex things which a C compiler would likely not be able to do (I put some examples at
the macro complexity achievable in combination with a DPS command_script can be seen in vpasttbq.sa , the rest show just some examples, the .txt being listings with generated ppc native code).
As for smaller projects, (several kilobytes of code), I can hardly see how C can accellerate that, they will take between 2 and 4 weeks to program either way. If something can be done within a day ot two in C and one does not have the libraries to match that in assembly, well, then I would justify C, but we are talking projects, not playing around.
I sure get that, my question is is really life that tough ... :-) :-)
Dimiter
------------------------------------------------------ Dimiter Popoff Transgalactic Instruments
------------------------------------------------------
Joerg wrote:
And I don't - especially when it is about compiling several nops linked with a few meaningless instructions, as it is in his example.
My factor of 10 is an overall figure, including the human language factor. Perhaps we can compare some actual code, can you locate some .gif compressor or decompressor written in C? I'll then come up with my assembly (68k, targeted at CPU32) and VPA (same code, targeted at PPC) versions, for a comparison (they convert a plain bitmap file into a .gif and vice versa). Everything else is just general talk, engineering is a lot about the details, though.
Dimiter
------------------------------------------------------ Dimiter Popoff Transgalactic Instruments
------------------------------------------------------
Wilco Dijkstra wrote:
I wouldn't call ASM dead - Walter's example shows that it has got more accessible : another usefull choice, as well as InLine ASM ...
All uC HLL users certainly should KNOW assembler.
Perhaps if you meant 'Vendor assembler mnemonics', and Label: JMP Label, then yes, that subset of assembler is being used less.
-jg
Not true, even now C is much bigger than 2 times code space. The biggest difference shows up in small projects where it can easily reach the times 10 factor.
Read up on Keil C for the 8051, among others.
Generally embedded programmers use a very small subset of the C language and available libraries (as compared to a Windows application programmer) so it's advantages as a high level language are greatly diminished in the embedded world.
I think the above example shows why there are such different takes on the C vs ASM issue, some people are just very good at and enjoy writing assembly and are poor in C and should stick with assembly, and some people are excellent C programmers and poor assembly programmers and should stick with C.
Once you excel in either one, excellent product will follow regardless.....
As usuall no details, so no way to make any real evaluation.
==> A recent example is Triac drive for a consumer application. Will softstart a motor when a key is pressed, fits into 600 byte of C and 700 byte of assembler, simply because the assembler programmer could not see the woods for all the trees. He implemented several state machines for different cases and could not see that if you take a top level view, they were really similar, so you could implement in one state machine. This lack of top level view is a side - effect of assembler programming and needs to be taken into account when you do a comparision. The alternative is to spend much, much more time.
Whats a mobile phone accessory?
==> Look at the home pages of the various mobile phone vendors, Sony-Ericsson, Nokia, Siemens-Benq etc, and you will find out.
Thats right, you spend your time using the free version, then you find your project doesn't quite work without you having to buy the the full compiler.
==> No, there are many projects that will work within 4 kB limits and other projects that will not fit. A mobile phone accessory is not something that continously grows. You develop code, and then thats that. Very few updates.
never happy but too far in to back out.
Ha Ha , nicely ducked.
That doesn't prove anything as you well know.
You make a statement which I know is false. I am telling you that I know it is false... I have no *urge* to prove it to you, though...
-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
"Generally" to me means most of the time, except in some very special cases. You cannot do a rotate with carry in C for instance unless you have an intrinsic.
-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
I think the only way to be productive is to write in C, and then try to figure out if it is realistic to get it into a smaller part or not. If you run out of memory you first try to modify your algorithm. Assembler should always be the last resort. I have never found that I needed more than one or two subroutines in assembler in any of the applications I worked on. I never found that I could get such a significant benefit in code size that I would spend my precious time on assembler.
-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
And you think that
__delay_cycles(320);
is inferior to any of your attempts in assembler
A compiler could conceivably also do
__start_timeout(); __wait_until_timeout(320);
using intrinsics that counts the number of clock cycles used by and then adds code to ensure that the complete code fragment executes in 320 clock cycles. I am not aware that it exists, but it would be a good thing. There are compiler technologies which will be able to figure out your execution time even if you have loops as long as the entry condition is known by the compiler.
-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Yeh, he translated from assembler to C and back again, what does that prove.
==> He proved that ANY program you can write in assembler, he can write in C... This is enough to prove you wrong for anyone which understands even the basic rules of logic
-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Try running it on a better processor like the AVR ...
-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
messagenews:452ac796$ snipped-for-privacy@dnews.tpgi.com.au...
messagenews: snipped-for-privacy@m73g2000cwd.googlegroups.com...
Know the tools. If a particular compiler adds 10X to a small project, look at the start up code. You are allowed to edit it.
"Joerg" schreef in bericht news:FSVWg.21521$ snipped-for-privacy@newssvr14.news.prodigy.com...
I like 'm as well. 4000 logic still exists because it has such a nice wide operating voltage, for starters. Given its features, there is no alternative, so it is here to stay for a while.
There's a difference between me saying something is dead and others saying something is dead ;)
-- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)
I said 'generally', several times.
In C versus ASM, the ASM camp always throw in those examples where a very speedy/tight piece of software is needed. Such are more a matter of being smart rather than the language you use. In most cases (if not all) it is only a very small portion of your project. When writing that portion of software, and only when the compiled result is not satifying, it is time to have a look at the compiled result. And you have to know a little bit about what you are working with. Using 32 bit longs on a
8 bit uP results in long and slow code. Since it is such a hassle to work with 32 bit longs in assembler for an 8 bit uP, such mistakes are not made in ASM. In ASM you are more aware of that. Once you are familiar with you compiler and target, you don't have to check that often anymore.A *lot* less than less.
-- Thanks, Frank. (remove 'q' and '.invalid' when replying by email)
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.