Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

hardware is still coded with machine/assembly language for efficiency, speed, etc.

Status
Not open for further replies.
KISS,

I will match my skill as a Assembler programer to what C does any day.

Ratch

Ok. Lets write a FFT algorithm and see who has the fastest "time to market".
 
Yep, the Amiga was pretty decent. I did buy the A1000 after all. They did, in fact use a small floppy drive, but they used composite video as output.

Not at all, they included composite video as an added bonus, but the main output was high quality RGB, and the sound was stereo digital at quite acceptable quality. Bear in mind this was back when a PC ran DOS only, had B&W text only graphics, and made beeping noises only :D

The floppy was a standard 720K 3.5 inch one, which pre-dated the later 1.44M ones.
 
Ok. Lets write a FFT algorithm and see who has the fastest "time to market".

hi T,
I would not disagree that using 'C or Basic' its quicker and easier to write a program, but I thought the discussion was about program 'efficiency' when using assembly, ie: tight code and optimum execution speed.

E.
 
Last edited:
hi T,
I would not disagree that using 'C or Basic' its quicker and easier to write a program, but I thought the discussion was about program 'efficiency' when using assembly, ie: tight code and optimum execution speed.
E.
Yes but that is just a bit like picking the car with the best looking wheels and ignoring the rest of it.

HLL optimization can also remove dead/unused/unreachable code.

Face it guys if you want to talk fastest/smallest we need to compare the worlds best ASM programmers to the worlds best HLL optimizers. Given that the ASM programmer is expected to write readable and maintainable code there is no contest on which will be faster and smaller.
 
Last edited:
Yes but that is just a bit like picking the car with the best looking wheels and ignoring the rest of it.

Sorry, I do not see the comparison in using that analogy,:confused:

E.
 
The point I was trying to make is that efficiency and speed alone are sufficient to judge a language.

OK, but surely you would agree a well written assembly program would require less program memory than a 'C' written program and it will also execute the code faster.?

I use Visual Basic for programming the PC, I changed over from 8086 assembly when 'bigger' and faster PC's became available.

If I compare the size and speed of an 8086 versus Basic there is no contest, the assembler wins hands down, also in the case of PIC's.

I understood the discussion was about program efficiency not programming efficiency.?
 
OK, but surely you would agree a well written assembly program would require less program memory than a 'C' written program and it will also execute the code faster.?

Absolutely. No competition. But do you really need fast and efficient code to run a washing machine? I rather have fast and efficient development tools and make some profit.
 
Absolutely. No competition. But do you really need fast and efficient code to run a washing machine? I rather have fast and efficient development tools and make some profit.

T.
I agree absolutely with that statement.

I use Visual Basic for PC programming for that very reason, not because its tighter or faster.

E.
 
Absolutely. No competition. But do you really need fast and efficient code to run a washing machine? I rather have fast and efficient development tools and make some profit.
I would say this is only generally true.

There are all sorts of application where a computer out do humans. Code optimization is one of them but it does not exist in all HLL compilers.
 
Last edited:
I would say this is only generally true.
Yes, that is why we are running 16+ pages of this topic. There is no one true answer.. in general. This is fun though.
 
Last edited:
Face it guys if you want to talk fastest/smallest we need to compare the worlds best ASM programmers to the worlds best HLL optimizers. Given that the ASM programmer is expected to write readable and maintainable code there is no contest on which will be faster and smaller.

No, no contest - the assembler will still be smaller and faster.

Just because the assembler C produces is unreadable doesn't mean it's small or fast, just that it's as small and fast as the compiler can produce.
Even optimised C code is still much larger and slower than assembler.
 
The problem with this thread is that it is A vrs B and does not allow for the possibility of HLL code with hand optimized ASM bits if needed.

If one expands our perspective to include pipelined and cached processor there are are additional optimizations centered on these features that few ASM programmers would attempt.

We need to keep in mind that in non small programs proper program design contributes more to the programs performance then optimization. With poor program design neither ASM or HLL is good. Optimized trash is still trash. If we compare an optimized trash C program to a well coded ASM program the ASM wins etc.

Nigel said:
Just because the assembler C produces is unreadable doesn't mean it's small or fast, just that it's as small and fast as the compiler can produce.

A good optimizer has a bag of 'dirty tricks' that the good human programmer can not use. The optimizer will not overlook an opportunity to make an optimization.

If there is a tick or technique used by ASM coders I expect it has made it way into the best optimizers bag of tricks.

I doubt there been much improvement in the skill level of the best ASM programmers in the past 40 or so years. On the other hand code optimization has been steadily improving and is still doing so.

However in most cases these good optimizers are not available or not used. But at the limit of what exists the optimizer wins.

EDIT: Anyone interested in learning about optimization should find this interesting (I did)
 
Last edited:
Probably should have read this entire topic before posting but as someone who uses both languages, and has transistioned between the two over a looong period, I guess my two cents...

Some C compilers, such as C18 and mikroC produced assembly I was relatively impressed with. It wasn't too big, but inevitably much much larger than my assembly efforts - less buggy too! Almost all cases the C code (after degubbing) was obviously quicker to write and debug, although on one project the debugging confused me so much I ended up writing ~1200 lines of assembly instead - which destroyed my soul. That worked much faster, allowed me to drop the clock speed, and save power. Where time is of the essence, mikroC's built-in peripheral libraries can make a relatively complex system a snap do write and debug in under an hour, including graphic LCD routines, and general test hardware.

These days, low pin count 16F's, or 12F's, I'll still write assembly 50% of the time as I generally use those for timing generation, or more complex tasks where program space is at a premium. For 18F's, I/we are spoiled by 32kwords of program space and up to 40/60MHz - so the compiler can do a crappy job and I don't care :)

I should point out that, for AVR's, the assembly language confused me so much, I went straight to C, and given virtually the same code, the winAVR C compiler generated code was much smaller, and quicker. But I guess thats because the hardware is optimised for it.

I prrrrobably just echo'd what has been said already. But I swear this topic comes up every few months somewhere :)
 
The problem with this thread is that it is A vrs B and does not allow for the possibility of HLL code with hand optimized ASM bits if needed.
...

At least a couple of us did allow (to combine both).

Even good optimised C will never approcach the small code size and speed of assembler. If you look at the ASM generated by the "C optimiser" it is C optimisation, NOT assembler optimisation.

The difference is; in assembler optimisation the code is very structured in overall layout and process, and even structurerd down to the finest detail, like re-using one bit in WREG.

C optimisation is totally different. C optimisation usually sets aside some variables as a "C stack" and puts commonly used variables there, which can "optimise" certain large math processes. But the down side is lots of data swapping between the real registers and the C stack registers. I've seen plenty of examples where the "optimised" C generates 20 ASM instructions for a line of C, but after turning optimisations off and maybe re-writing that C line it is down to 6 or 8 ASM sinstructions.

The use of a "C stack" in PIC and AVRs is especially counter-optimising, as the embedded chips all have global registers. C stack optimising is better in larger apps where there is short term fast RAM or local working registers (PIC32?) that can use the C stack, instead of ASM working with the large slow memory.

So when working with a PIC where all RAM vars can be directly accessed, turning "optimisation" OFF can often result in a 10% or more improvement is code size and speed!
 
Mr RB said:
At least a couple of us did allow (to combine both).
I was talking about the title.

As the complexity of a processor increases the ability of a human to write optimal code decreases.

I expect there are examples in favor of both. That makes the title wrong.

Even if the title were right about optimizers vrs human ASM coding it is far to expensive to write most programs in ASM. It also takes more time to code a program in ASM so that impacts the time to market in a bad way.

The ASM rules attitude is very dated. It is time for people to move into the current century.
 
3v0, this is one of the reasons ARM has become so popular, it's far less complex than the year after year additions to the instruction sets of x86, and are supplemented by codec chips for things like video and audio. The possible complexities of ASM in the real world can be partially relegated by multi-cores, that is the way the world is going. This isn't just good because it's good for ASM programmers but even C programmer benefit.

Tightening the belt right now will give us multiple generations of more powerful software on the SAME hardware! Look at how the complexities of rendering ability of the PS3 have evolved since it first came out, as a specific example. And this is not because programming the raw hardware is any easier but because game engine makers have optimized their software to the hardware through repeated iterations.
 
I was talking about the title.
...

I apologise, I misunderstood your point there. :)

...
As the complexity of a processor increases the ability of a human to write optimal code decreases.
...
Even if the title were right about optimizers vrs human ASM coding it is far to expensive to write most programs in ASM. It also takes more time to code a program in ASM so that impacts the time to market in a bad way.

Agreed and also agreed. I too use C for 90+% of tasks, to reduce development time. However not all projects are large and complex, and sometimes it is more important to squeeze the better/smaller/faster performance from limited hardware and so in that specific case ASM is much better.

So I disagree with you about the thread title, I think the thread title is essentially correct that;
1. hardware is still coded using assembler = correct
2. that is done for efficiency, speed etc = also correct

I agree with you in princicple that it is better just to stick with a higher language than ASM (ie C) and go for the increased productivity, but that agreement is general, it applies to the broad range of hardware from PC down. But this forum is largely for electronics and most coding that is discussed is for small PIC/AVR applications where the micro needs to provide real-world hardware perfomance and maximum speed from a minimal micro is critical. So in relation to that, ASM is far from dead it is still often the very best choice, either a full ASM application or sections of inline ASM within the C code.

One of the recent problems emerging from classroom trained embedded programmers is that they have the attitude to "just code it in C and throw someones libraries in" and they think they have a top performance commercial application.
 
This is what I know.

In industry programming effectiveness and efficiency comes down to what will make the most money. In competitive markets that is severely tempered by time to market. If you come in 2nd with a product you have wasted your time and money. I have seen a product killed when the competitor announced a vapor ware product.


Long production runs favor spending more on development to reduce unit cost.

To my knowledge the longest production runs are autos, home appliances, and toys.

It looks like the automotive people have gone with C and developed their own C standard, MISRA.

As for home appliances I am unsure. One would expect movement to a HLL as complexity increases. Where they are or at what rate I am uncertain.

As for toys I think this may be one market where ASM can make some big bucks.

Time to market maybe driving both appliances and toys to a HLL. Once a product has been released it can be recoded in ASM using a less expensive processor if the sales support it.
 
Hi

I would like to ask some related questions here without disrupting, hopefully, the interesting discussion going on here.

1: Now I understand that when small file size and efficiency are highly desirable then the assembly is the way to go. But I still don't really get why the code in C takes more space and is slow when compared to a code in the assembly to do the same job. We can say that the C takes circuitous route to reach the destination while the assembly takes the shortest route available. But what's the reason for the C to take a longer route? How can we analogize it better?

2: In a book about MCU 8051 I use it says that one should get a C compiler with good optimization... What does it mean? When I was learning C++ I used Code::Blocks compiler which is also considered a good compiler for the C. Can't I use the same compiler to compiler C code written, say, for 8051 MCU? I see there is an offshoot of C which is called embedded C.

3: In the post above 3v0 mentioned MISRA C. It says that MISRA C is a development standard. What does it really mean? Isn't MISRA C different from C? Is it a different language, or C with some adds-on.

Please help me with the queries above and I'm not a programmer but have some experience with C++. Thank you.

Regards
PG
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top