c or assembly to use when size is important? - Page 1
Forum section: electronics / general

author: nour
author_rank: Frequent Contributor
timestamp: November 19, 2015, 09:25:04 pm
content: I want to know which is better if the memory size is very critical for meI have compiled blink led example for atmega8a in both assembly and c the first one half the size of the second one!!is it always the same?Does the assembly lang. win if it comes to the memory and program size always ?

author: ataradov
author_rank: Super Contributor
timestamp: November 19, 2015, 09:43:48 pm
content: If it is just a blinky, then ASM will always win. But if you are actually doing something real, then C wins hands down.But you need to understand how C compiler works and what code can be efficiently translated and what can't. It is better to spend time making your embedded C skills better than optimizing one single program in ASM, since you will have to do the same for the next project again.

author: Bassman59
author_rank: Super Contributor
timestamp: November 19, 2015, 09:57:57 pm
content: Quote from: nour on November 19, 2015, 09:25:04 pmWithout seeing what libraries are linked in, and what is involved with the startup, nobody can tell you why the C version was larger.-a

author: KL27x
author_rank: Super Contributor
timestamp: November 19, 2015, 10:20:00 pm
content: QuoteThe C code may include some (currently) unused framework/format that allows it to be scaled/integrated within a larger code. Sometimes the "best" way to write a code is not the smallest code space, when you allow for future code changes/usages.One you start making your Atmega8a do other things while blinking the LED without changing that blink rate, you will find out how much you need to modify and add to that simple code you wrote. Maybe you will go back and figure out a way to make your LED code more flexible and more adaptable, so it can be used in a larger variety of situations. That will be a bigger code. You might come up with a standardized delay routine to use with the LED blink code. And that will take up space, too, initially. But when the code reuses that delay routine many times, it will end up saving space. You might also integrate a polling-based interrupt into the delay routine that can scan for and act on variables, based on how a register is preconfigure prior to the delay call. And now you're starting to see why C code might look inefficient when compared with a simple LED blink code.It is very easy to write assembly for simple tasks. As the code becomes more complex, it becomes very difficult to maintain. So in theory, assembler can always be made at least as efficient and potentially much more efficient than straight compiled C. But in practice, this is often not the case. And memory is cheap, so don't worry too much about code efficiency.C libraries are like a box of standard legos. Assembly is like a pile of plastic dust with which you can build anything. But if you do not take care to make your assembly blocks fit together, they are single-use, only, and wll require a lot of extra work/code to make them work together. Sometimes a weird custom piece might be greatly beneficial. But a lot of the time it is simply easier to use a 10 or 20 of the regular blocks to get the same result in a way that is more maintainable.

author: Brutte
author_rank: Frequent Contributor
timestamp: November 19, 2015, 11:02:44 pm
content: Yet another marketing guy that advertises avr assemblers this time..Wasn't that "up to 800% improvement!!" last time?Prove your statement. Post the code, switches, linker options of that 4k blown to 8k. Or was it 4 bytes blown to 8 bytes really?QuoteWhat is the volume? 1e5? 1e6? I am sure you got decent discount at that "very critical" quantities... Would you reveal some details of the deal or is it confidential (a.k.a. "I need a tank controller for my fish")?

author: BradC
author_rank: Super Contributor
timestamp: November 19, 2015, 11:05:22 pm
content: Quote from: ataradov on November 19, 2015, 09:43:48 pmTwaddle. A good programmer will *always* be able to out-code a C compiler in assembler. Now, whether you *should* is an answer for another question, but to say that a C compiler will win a size contest against ASM implies a programmer who does not know his/her architecture.

author: ataradov
author_rank: Super Contributor
timestamp: November 19, 2015, 11:08:28 pm
content: Quote from: BradC on November 19, 2015, 11:05:22 pmWell, we need to put a constraint on time it takes. I routinely work with a project that compiles to ~160K binary file.And it is a well written code with no bloated libraries. Good luck writing all that in assembly.And also, the code is 100% portable between ARM and AVR. So good luck doing it twice.

author: KL27x
author_rank: Super Contributor
timestamp: November 19, 2015, 11:23:22 pm
content: Agreed, there's a point where it becomes impractical not only to write, but to maintain.Technically, a good assembly coder can always theoretically beat a C compiler for a given, specific, application, regarding code space and execution speed. But that entire code might become a complete pile of dog turds when one additional requirement/change is needed, which wasn't initially accounted/allowed for. The further you go to optimize the code efficiency, the more likely you are going to end up with a code that is unadaptable.

author: nour
author_rank: Frequent Contributor
timestamp: November 19, 2015, 11:48:18 pm
content: Quote from: Brutte on November 19, 2015, 11:02:44 pm!!!!!!!!what are you taking about?I own a lot of atmega 8 and I have done some programming on the atmega 32 and I know that libraries consume a lot of space which will always contain a lot of stuff that I would never needand I want to use atmega8 to do some stuff that may not be very efficient to use c libraries with end of the story

author: BradC
author_rank: Super Contributor
timestamp: November 19, 2015, 11:48:32 pm
content: Quote from: ataradov on November 19, 2015, 11:08:28 pmNo, actually we don't. The question asked was purely about size and nothing to do with time or practicality.I'm not disagreeing with the points you make. I wrote and maintained about 25k lines of 68hc11 asm code for a number of years. It turned into somewhat of a headache, but the reality was when we translated it into C there was no way it could be made to fit into the available memory space. If we'd started with a C target in mind, we might have had the option to use a different processor with more memory, but then that would have exceeded the project budget and we may not have got a project into the market. Sometimes requirements trump code.I'm just disagreeing with your statement that on a large or complex project C will beat out ASM for size, because it's incorrect.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 20, 2015, 12:02:25 am
content: Quote from: Bassman59 on November 19, 2015, 09:57:57 pmEven without seeing any of the code, it's a pretty safe bet that the C version was larger due to libraries and the startup. The gap often narrows as the project gets more complex because the assembler program then also needs startup and library code similar to what the C compiler included.Quote from: nourC compilers and assemblers both produce native machine code, so theoretically a highly optimized compiler could produce the same code as an assembler. The difference is that the C compiler decides for itself what code to produce, whereas in assembly languageyoudecide. A highly skilled assembly language programmer can probably beat the compiler every time, but will take longer to do it if the project is complex.If the MCU still has memory spare and execution speed isn't critical then you might as well use C, as you can then code faster and take advantage of existing libraries and code ported from other platforms. If the code gets too large you have several choices:-1. Refactor the code and/or think of ways to make it use less space.2. Change to a chip with more memory.3. Rewrite the program in highly optimized assembler.Option 3 is not usually practicable, due to the enormous amount of effort required.If you want to wring the last drop of performance out of an MCU with limited resources then it's best to program it in assembler from the start. The project I am currently working on uses an ATmega1284 to replace the character generator ROM in an 8 bit computer. 98% of the ATmega's 128k ROM is used for character patterns and the entire 16k RAM is used for video display. All variables are held in registers, and no stack is allocated (no interrupts or subroutine calls allowed!). This would be absolutely impossible in C!

author: KL27x
author_rank: Super Contributor
timestamp: November 20, 2015, 12:25:06 am
content: QuoteIf you're doing very simple things, then assembly could very well be the best way to get it done.If you are going to be doing more complex things, you may wish to modify your libraries, removing the functions you are not using?Going too far down either road can get quite time-consuming to manage. This is why most of us end up buying more memory and/or processor speed. Barring super high volume, it is often cheaper to buy more memory than to do more programming.

author: westfw
author_rank: Super Contributor
timestamp: November 20, 2015, 07:23:50 am
content: QuoteSure. Eventually. If they're willing to spend full attention on every piece of the code.QuoteAnd the big question is: "IS the memory size very critical?" That seems to less and less the case, these days. For less than $1 extra I can go from "not enough memory for trivial tasks" to "more object code than I'd care to write assembler for."Perhaps you meant "cost is very critical", but that's a different question that should take into account SW development and maintenance expenses as well as chip price.

author: MarkF
author_rank: Super Contributor
timestamp: November 20, 2015, 08:46:16 am
content: For ease of development and maintainability, you want to write your code in C or some other high level language. Then if you run into size or speed issues try to tweak or optimize it. You may be able to re-write the offending sections to improve performance and memory usage. Code written in assembly will give you the fastest execution time and best usage of memory if written well. You have to worry about every detail with assembly and that control is where the savings comes in.I've developed 100s of thousands of lines of code professionally in many languages; various assembly, Fortran, Ada, C and C++. Granted it has been almost 35 years since I've written assembly. But at that time it wasn't any harder to write assemble than it is to write C++ today. It's all in the time you've spent becoming familiar with a language and the processor you're coding for.It really all comes down to how good of a coder you are in the language you're using.

author: amyk
author_rank: Super Contributor
timestamp: November 20, 2015, 08:53:50 am
content: This is true more for transitions from higher-level languages (e.g. C++ to C), but one effect I've noticed when porting code to a lower-level language is that it tends to encourage finding a simpler solution, involving writing less code, so the effort increase is actually not as bad as it would seem compared to "emulating" a more optimising compiler. The fact that it's a lower-level language where generating code takes more effort forces you to reconsider your strategy; you may find a much simpler solution as a result.

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: November 20, 2015, 09:14:42 am
content: i think some refuse to follow evolution , i can't see a single reason for ppl that keep using assembly, most MCU now have a lot of memory even for small application, at low prices you just have to choose the right one. C will always be the better language if you need to make things fast and stable.any family of µC i have seen have a full range of memory size chip using the same package, so just move to the next one and save your time.

author: grumpydoc
author_rank: Super Contributor
timestamp: November 20, 2015, 09:53:27 am
content: For anything complex correct choice of algorithms and data structures is usually more important than implementation language (within broad bounds, of course).Ease of maintainance is generally proportional to lines of code so assembler looses out badly because it takes so many more lines of code to do anything.A good C programmer ought to be able to get close to the code density offered by assembler. If large libraries or start-up code is bloating the result it should be possible in a decent development environment to elide those and provide your own ifreallynecessary. After all if you were writing in assembler you would have to do just that.Occasionally you do need to drop to assemler - eg to use individual instructions the compiler won't generate, low level bit twiddling or hardware access sometimes need it as well.As a software engineer I have quite often rewritten assembler code in C because the assembler was an unmaintainable nightmare. I have never run out of hardware resources in doing so or made anything noticably slower.

author: Kjelt
author_rank: Super Contributor
timestamp: November 20, 2015, 11:39:52 am
content: Quote from: hamdi.tn on November 20, 2015, 09:14:42 amAgree except there are exceptions for instance with large bit multiplations with a carry.C does not support carry with multiplications so if you ever need lets say a 256 bit multiplier (for instance for ECC) you know you can get 10 times more speed doing it in assembly.Still better get some hardware support for it and get 1000 times speed increase

author: Kalvin
author_rank: Super Contributor
timestamp: November 20, 2015, 04:20:05 pm
content: Quote from: BradC on November 19, 2015, 11:05:22 pmWhen using simple devices and architectures, yes. But when one starts using superscalar architecture with parallel execution units, the compiler can produce more optimized code. Of course the programmer can obtain the same result dedicating enough time and effort. Maintaining and debugging the manual produced code will be a total nightmare, though.

author: Howardlong
author_rank: Super Contributor
timestamp: November 20, 2015, 05:31:59 pm
content: Quote from: hamdi.tn on November 20, 2015, 09:14:42 amIn certain edge cases, such as number crunching DSP and when there are memory configurations unknown to the compiler, it is often possible to write assembly language that runs two or three times faster than a C compiler will generate, even after giving the compiler lots of hints and help like code and data placement, manual loop unrolling, idioms and intrinsics. But dropping into writing assembly language at pinch points is certainly becoming rarer and rarer. I read what the compiler generates just as much as I ever did though.You only need to experience some of the supposed optimised examples of the Cortex CMSIS DSP code to realise that there's still work to do.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 20, 2015, 09:02:38 pm
content: All the comment you've made are true for domaine like programming a micro-controler or small CPU. Now goes to superscalar architectures like the latest generation of x86, or the weird Cell CPU, most of the time, if not all the time, the C compiler will outperform in speed (and probably in size) the result of a good Asm programmer. The problem with Assembly is that there are some architecture that are too complex to handle them directly by hand, and an ASM solution that works better in a specific case could be dramatically worse in all other cases, a good C compiler should be aware of all of that point, and will take care of that for you. That does not mean that for specific situation, you can't do better than the compiler, but in most situation, even an expert Assembly programer will not do better.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 21, 2015, 02:58:33 am
content: Quote from: Godzil on November 20, 2015, 09:02:38 pmOff topic. The 'latest generation of x86' is mostly programmed in higher level languages which are much less efficient than either C or assembler. Why? Because they are more portable and convenient, and the machines are powerful enough to get away with it. Nobody in the x86 world worries about code size and efficiency any more - if performance lags you just throw more hardware at it!http://githut.info/Top active languages:-1. JavaScript2. Java3. Python4. CSS5. PHP6. Ruby7. C++8. C

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: November 21, 2015, 09:21:47 am
content: True, for some exception ASM is better, still C compiler offer to integrate ASM code within a c code, so you certainly don't have to write the whole thing in ASMQuote from: Bruce Abbott on November 21, 2015, 02:58:33 ami don't pretend to know any thing about this but first time i read about java being on the top.

author: ataradov
author_rank: Super Contributor
timestamp: November 21, 2015, 09:23:06 am
content: Quote from: hamdi.tn on November 21, 2015, 09:21:47 amI'm guessing Android is to blame here.

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 11:28:59 am
content: Quote from: Godzil on November 20, 2015, 09:02:38 pme.g. a MIPS soft core which has no hw handlers for pipeline-hazards, so you have to manually check for conflicts and fix them (instructions swapping)the easiest "dump solution" is abusing of NOP-stuffing (useful for delayed branch, but … it means you are deliberately wasting the code density)e.g. m68k is a piece of cake in assemblye.g. with PowerPC you must care about the correct use of EIEIO&C instructions when you have shared ram and/or memory mapped devicese.g. with 68hc11 you'd better write in assembly than in C because it's a stack machine (and gcc fixes the jam forcing soft register)

author: Godzil
author_rank: Frequent Contributor
timestamp: November 21, 2015, 11:40:25 am
content: Quote from: Bruce Abbott on November 21, 2015, 02:58:33 amThat'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

author: Jeroen3
author_rank: Super Contributor
timestamp: November 21, 2015, 03:01:48 pm
content: To answer the original question. Ccanalso 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.

author: legacy
author_rank: Super Contributor
timestamp: November 21, 2015, 03:16:58 pm
content: 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 workwritten in assemble (PIC32), it took 2 days (including test bench)

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 21, 2015, 03:33:38 pm
content: 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.

author: Kalvin
author_rank: Super Contributor
timestamp: November 21, 2015, 03:41:11 pm
content: Quote from: 0xdeadbeef on November 21, 2015, 03:33:38 pmQuite 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.

author: gmb42
author_rank: Frequent Contributor
timestamp: November 21, 2015, 05:32:57 pm
content: Quote from: Kalvin on November 21, 2015, 03:41:11 pmThese compiler extensions are usually calledintrinsicor built-in functions.

author: dannyf
author_rank: Super Contributor
timestamp: November 21, 2015, 06:56:18 pm
content: QuoteDepends 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.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 21, 2015, 06:58:45 pm
content: 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.

author: fcb
author_rank: Super Contributor
timestamp: November 21, 2015, 08:02:50 pm
content: If absolute size is the only consideration, then in general assembler will be more efficient/smaller.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: November 21, 2015, 08:09:10 pm
content: Quote from: Godzil on November 21, 2015, 11:40:25 amStill off topic.QuotePerformance 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 platformthat consists of an ATmega644 with 64k ROM, 4k RAM andnographics chip. Could they have done it without assembler?Andhere's another gaming machinethat uses a PIC24EP512GP202. What language do you think it was programmed in, and why?

author: Howardlong
author_rank: Super Contributor
timestamp: November 21, 2015, 08:49:20 pm
content: Quote from: Bruce Abbott on November 21, 2015, 08:09:10 pmI 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.

author: timb
author_rank: Super Contributor
timestamp: November 21, 2015, 08:51:04 pm
content: 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

author: Godzil
author_rank: Frequent Contributor
timestamp: November 21, 2015, 08:54:21 pm
content: Quote from: Bruce Abbott on November 21, 2015, 08:09:10 pmGaming 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.Quote from: Bruce Abbott on November 21, 2015, 08:09:10 pmI 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.

author: Kalvin
author_rank: Super Contributor
timestamp: November 21, 2015, 08:57:24 pm
content: Quote from: Godzil on November 21, 2015, 08:54:21 pmThe PIC24-family has a 16-bit architecture, and the XC16 compiler produces very good code for it.

author: Howardlong
author_rank: Super Contributor
timestamp: November 21, 2015, 09:59:41 pm
content: Quote from: Kalvin on November 21, 2015, 08:57:24 pmCorrect, 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.

author: MT
author_rank: Super Contributor
timestamp: November 21, 2015, 10:15:33 pm
content: 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 MSP430yeahoo forum (main place to go in early MSP days) because i wrote everything in assembler! They said i was a dinosaur a fool and Cwas the only sane and decent approach, but i though it was a neat little CPU and simple assembler friendly.QuoteNice!

author: gmb42
author_rank: Frequent Contributor
timestamp: November 21, 2015, 10:31:33 pm
content: Quote from: 0xdeadbeef on November 21, 2015, 06:58:45 pmI 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?

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: November 21, 2015, 11:42:31 pm
content: Quote from: gmb42 on November 21, 2015, 10:31:33 pmOf 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.

author: ralphd
author_rank: Frequent Contributor
timestamp: November 22, 2015, 05:28:49 am
content: 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.

author: Godzil
author_rank: Frequent Contributor
timestamp: November 22, 2015, 01:08:32 pm
content: Quote from: gmb42 on November 21, 2015, 10:31:33 pmThey 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.