c or assembly to use when size is important?

[Godzil]

Now goes to superscalar architectures like the latest generation of x86,

Nobody in the x86 world worries about code size and efficiency any more - if performance lags you just throw more hardware at it!

That's completely false, and I spoke about the x86 because it's the most common one, but that's also true for the PowerPC. There are still plenty of domain where they care about performances, like in Video Games (not all developers for sure, but there are still some that really care)

A friend of mine have created his own company to make a particle effect middleware, it's made to run on multiples devices from the PC, to all the gaming consoles that clients may want and that include various CPU architecture, like the PowerPC CELL. We were chatting about performance of code at some point, and he clearly tell us (he is quite good at assembly, and an expert in x86 assembly) that complex architecture like the modern highly powerful x86, PowerPC etc.. each time you wan't to do something large by hand in assembly the bigger problem is that you code will be correctly optimized in a specific run situation, but considering the was a modern CPU is working (instruction reordering, pipelining, etc..) it's almost impossible to do a large assembly code base, and it's preferable to leave that part to the C/C++ compiler, and only optimise in assembly when really needed in a small portion of code that need to be really optimized (like forcing the use of vectorization instruction etc..)

For him (and he made a lot of thing in assembly in the past) it was absolutely out of question to make something completely in assembly because of the complexity of modern architectures that just make that jobs almost impossible to handle and think about all the cases. It's nearly impossible to properly counting the cycles on theses architectures for exemple

[Jeroen3]

To answer the original question. C can also be very compact.
You just need to write it correctly, and tickle the toolchain's C-spots. 

- Enable the optimiser to make operations consisting of two constants/literal turn into one constant.
- Enable the optimiser so the compiler uses the general purpose registers as stack.
- Do not link in unused code. Tell to linker to skip those (often default).
- Tell the compiler Main() is a special function that never returns, this will make the compiler skip stacking.
- Do not use stack, hint the compiler using the "register" keyword for certain variables, such as "i".
- Do not use C functions in a memory limited device. The stacking frame is wasted time and space.

I've programmed C for an attiny 10, got to around 800 bytes for a digital filter on 1 adc channel in a low voltage/not-charging warning indicator for motorcycles/batteries.
Could have done it in assembly, but that takes too long.

[legacy]

I have written a PSX-PAD interface for HC11 used in serial bootstrap mode (which means you have 512byte of ram, byte, not Kilo byte)
written in assembly, it took 2 weeks of work
written in assemble (PIC32), it took 2 days (including test bench)

[0xdeadbeef]

There is still need for assembler code today like for certain types of exception handlers, interrupt jump tables or support for very specific opcodes (like counting the number of bits, atomic read/modify/write, vector instructions and the like).

For mere performance reasons, I would not bet that a typical programmer will write faster and/or more compact code in assembler than in C. While actually even the best optimizing compiler might do dumb things like reloading registers that still contains the correct value and stuff like this, a good compiler will also do some optimizations that a normal programmer will not think of. Like performing a masked shift with some ultra-weird opcode that you're not even aware of. With a simple CISC architecture, this was not so much of a problem, but typical RISC controllers tend to have a rather weird instruction set where one opcode might have ten or more mnemonics.

Besides, the more complex the CPU, the more dangerous and less effective it gets to program it in assembler. If you have to consider pipeline effects, parallel execution, cache and stuff like this, it gets more and more difficult to beat a compiler.

[Kalvin]

There is still need for assembler code today like for certain types of exception handlers, interrupt jump tables or support for very specific opcodes (like counting the number of bits, atomic read/modify/write, vector instructions and the like).

Quite often the compiler may provide non-standard extensions and functions which will generate code for those specific op codes and cases you just mentioned. The source code may not be directly portable to another architecture or may not compile using other compiler, but one may not need to write assembly code.

It may be possible to play with macros and/or conditional compilation, and make source code more portable ie. using the optimized functions and keywords when compiling to the specific architecture and using the specific compiler, and using non-optimized version of the functions when compiling to another architecture and/or using another compiler.

[gmb42]

There is still need for assembler code today like for certain types of exception handlers, interrupt jump tables or support for very specific opcodes (like counting the number of bits, atomic read/modify/write, vector instructions and the like).

Quite often the compiler may provide non-standard extensions and functions which will generate code for those specific op codes and cases you just mentioned. The source code may not be directly portable to another architecture or may not compile using other compiler, but one may not need to write assembly code.

These compiler extensions are usually called intrinsic or built-in functions.

[dannyf]

Does the assembly lang. win if it comes to the memory and program size always ?

Depends on how good of an assembly programmer you are: like any powerful tool, in the hands of a skilled master, it can produce master pieces. In the hands of a terrible, it can create terrible work too,

Assembly, for practical purposes, is great if you intend it for small / simple applications, or you really want to push the boundary. High level languages are the ones you pick if you care about speed (to market/final product), maintenability, cost, .... As MCUs get more and more powerful, and the software cost of development gets more expensive (in relative terms), you will see more done in a high level language like C - as it has been over the last 20+ years.

[0xdeadbeef]

Letting aside that of course intrinsics only cover the few cases the compiler vendor thought of (which are usually just a few), using intrinsics means trusting the compiler vendor without having the source code. This is a no-go in automotive/avionics.

There are of course also a lot of cases where intrinsics don't help you at all. Like writing a complex exception handler where you must not change certain registers, create certain assembler instruction in RAM, jump there, patch the return values to some original registers and crazy stuff like this. Been there, done that.

Or there are microcontrollers which don't use jump addresses in their interrupt vector table but you can put a few opcodes there. So you can either jump to the service routine or put the service routine in there. This is stuff where every opcode counts and you must be sure which registers are used or which status flags are set, so this is a place for assembler code.

Same is true for some startup code where you don't have initialized the stack or the RAM yet and must be sure the compiler does nothing that's not yet allowed (like putting variables on the unitalicized stack).

For everything else, trying to beat the compiler is usually more or less pointless. Typically code is slow because the developer was dumb, not because of the language it was written in. Or to put it in other words: thinking about a clever algorithm is usually better than trying to implement a not so clever one in assembler.

[fcb]

If absolute size is the only consideration, then in general assembler will be more efficient/smaller.

[Bruce Abbott]

I spoke about the x86 because it's the most common one, but that's also true for the PowerPC.

Still off topic.

There are still plenty of domain where they care about performances, like in Video Games (not all developers for sure, but there are still some that really care)

Performance perhaps, but not memory usage. The Latest PC games require up 12 Gigabytes of RAM! If performance lags then the routine answer is always more RAM,  faster CPU, bigger graphics card etc.

At the other end of the scale (and more relevant to this thread) here's a gaming platform that consists of an ATmega644 with 64k ROM, 4k RAM and no graphics chip. Could they have done it without assembler?

And here's another gaming machine that uses a PIC24EP512GP202. What language do you think it was programmed in, and why?

[Howardlong]

And here's another gaming machine that uses a PIC24EP512GP202. What language do you think it was programmed in, and why?

I absolutely love that guy's stuff, this sort of shoehorning was commonplace in the 80s when memory was sparse. Who'd have thought an entire floating boint BASIC in under 8KB? Integer BASIC in 2KB? You need about 150KB for Lua nowadays, purported to be a lightweight designed programming language especially designed for embedded systems. 

Like it or not all that smart stuff is swiftly becoming a forgotten art I'm afraid. In some ways it's good, we can now produce more maintainable code. In other ways it's shockingly wasteful on resources. What concerns me more is on the odd occasion when you do need to dig, the expertise to do that is rapidly evaporating.

[timb]

I've heard size doesn't mater. It's the motion of your programmatic motion that counts. Tapping dat ASM and giving her multiple OP-codes is what it's really about.


Sent from my Tablet

[Godzil]

Performance perhaps, but not memory usage. The Latest PC games require up 12 Gigabytes of RAM! If performance lags then the routine answer is always more RAM,  faster CPU, bigger graphics card etc.

Gaming consoles are not. Do you know how much memory a cell SPU have? or the CPU momory for a PS3 or an XBox 360? There are not 12GB or memory, even on the XOne and PS4.

At the other end of the scale (and more relevant to this thread) here's a gaming platform that consists of an ATmega644 with 64k ROM, 4k RAM and no graphics chip. Could they have done it without assembler?

And here's another gaming machine that uses a PIC24EP512GP202. What language do you think it was programmed in, and why?

I will object with the whole Arduino project where everyone develop on AVR chip... in C++.
And the PIC is absolutely not well suited for C languages so I don't agree with your examples.

[Kalvin]

And the PIC is absolutely not well suited for C languages so I don't agree with your examples.

The PIC24-family has a 16-bit architecture, and the XC16 compiler produces very good code for it.

[Howardlong]

And the PIC is absolutely not well suited for C languages so I don't agree with your examples.

The PIC24-family has a 16-bit architecture, and the XC16 compiler produces very good code for it.

Correct, while the 8 bit PICs aren't great for C, the 16 and 32 bit PICs are pretty reasonable.

Having said that, I'd still far rather code up in C rather than assembly nowadays on an 8 bit PIC. Things have changed, 15 years ago it was all assembly.

[MT]

When i wrote code (not much but some anyway) for the MSP430 back in the early MSP430 days i was ridiculed like hell on the MSP430
yeahoo forum  (main place to go in early MSP days) because i wrote everything in assembler! They said i was a dinosaur a fool and C
was the only sane and decent  approach, but i though it was a neat little CPU and simple assembler friendly.

And here's another gaming machine that uses a PIC24EP512GP202. Wha

Nice!

[gmb42]

Letting aside that of course intrinsics only cover the few cases the compiler vendor thought of (which are usually just a few), using intrinsics means trusting the compiler vendor without having the source code. This is a no-go in automotive/avionics.

I don't follow this.  You can look at the assembly produced to see what's happening.  How do automotive/avionics folks trust whatever else the compiler does, e.g. with a simple assignment?

Certain languages, e.g. ADA comes to mind, do have validation suites, but even then I don't think they cover the specific assembly code that's produced so how do they get trusted?

[0xdeadbeef]

I don't follow this.  You can look at the assembly produced to see what's happening.  How do automotive/avionics folks trust whatever else the compiler does, e.g. with a simple assignment?

Of course compilers are validated and there are regression tests for normal operations. Obviously it wouldn't be impossible to also validate intrinsics, but for portability, code reviews etc. its common to use self-developed libraries for math function, binary operations and the like.

[ralphd]

I find AVR assembler simpler and more straightforward than C.
There's no gotchas with order of expression evaluation.
No casting rules to worry about, no pointer arithmetic to remember.
I can easily detect math overflow/underflow and use the carry flag.
I can write functions that return multiple parameters (or act lime pascal's inout parameters) instead of makimg a struct.

That all said, most of the embedded code I write is in C for portability.

[Godzil]

Certain languages, e.g. ADA comes to mind, do have validation suites, but even then I don't think they cover the specific assembly code that's produced so how do they get trusted?

They are! The assembly code produced is also checked! To build avionics, or cars software you have to use a certified compiler, and to get that certification the output need to be proved.