Comments on: Insects of the computer world

By: GregK

GregK — Sat, 04 Apr 2009 15:39:00 +0000

Indeed I confuse column’s there is not RAM record in second column!I am Sorry.It is good that my holiday just started, seems in time .

By: Miro Samek

Miro Samek — Sat, 04 Apr 2009 15:28:00 +0000

Greg,I think you confuse the QF-nano codesize column with RAM consumption. My table does *not* contain any RAM footprint data, because as you correctly observe, compiler cannot do much about the RAM consumed by the application.I also experienced the phenomenon you described that a small change in the source code resulted in a disproportionate change in the generated code-size, when the highest-levels of optimizations were used with the IAR compiler. Actually, I have examined the generated machine code and found out that IAR has very aggressive common-expression elimination policy. In the case of the QF-nano framework, there is a repetition of a portion of the scheduler code. The repetition could be eliminated by using explicit “goto” statements, which I didn’t want to do, because it violates MISRA rules. But the IAR compiler noticed the commonality in the source, and generated code as if the gotos were there. This is pretty cool. This also explains why a small change in the code destroys or creates sometimes the opportunity to eliminate a common expression (the common part becomes smaller or bigger, depending what you do).In summary, really tight code is the result of cooperation between the compiler and the linker. Either one alone cannot do a really optimal job. Some of this cooperation is missing in the GNU toolchain. Commercial compilers are apparently getting better in this respect.–Miro

By: GregK

GregK — Sat, 04 Apr 2009 13:48:00 +0000

It is very interesting subject, and there is something alarming me in this table.Every test with IAR’s tool is quite good. just look at ATmega results with IAR and GNU tools. It is huge different! Some time ago I have worked with IAR and MSP430, after some strange thinks when code size rapidly change size of 30% during small change! I realize (and proof) that IAR’s linker absolutely brilliant remove unreferenced functions from end code (including nested references from function called function etc..), as well as unreferenced variables from RAM (any size, also big buffers) if not referenced or volatile. In additional IAR’s compiler is really good commercial compiler, specially designed for such job like squeeze code size.When I started work with tools based on GCC I can not find such feature in linker, only compiler can remove unreferenced static functions and variables from module scope.Supposedly every line of IAR’s tool have that feature.TMS320 c2000 result looks also really not bad. I know from experience (actually some DSP architecture) that compilers from TI has nice feature: with the highest level optimization compiler treat all modules in project like one file! what give compilator the same possibility to remove all unreferenced stuff from code (RAM and ROM), it is a little different approach to IAR’s tool where that was done on linking stage.My doubts are: if this test is really relevant if we compile only framework, without project what really use this framework. I do not know how this test looks so it is my doubts.Everything apart of IAR’s and TI’s tools looks really poor.Is really strange that IAR can save 810-650 = 160B of RAM in the same project. it is huge amount of RAM! in this case!!What normally we can observe in changing level of optimization and/or switching compiler is simply change ROM size with really, really small change in RAM size, if any (do not consider stack of course). How IAR saved 160B of ram in ATmega project is really enigma for me .

By: Miro Samek

Miro Samek — Thu, 26 Mar 2009 14:38:00 +0000

Poor code density is bad in every way you look at. If you worry about flash ROM data retention, the probably of flash failure is proportional to the die area taken by the flash (assuming equivalent process technology, which must be pretty much the same for all silicon vendors if they want to stay competitive). So the probability of bits falling off the flash is roughly 5 times worse in PICmicro-based MCU than MSP430-based MCU implementing the same functionality in software.

By: GregK

GregK — Thu, 26 Mar 2009 14:18:00 +0000

I have just read your comment from embedded.com, quote:”(…) In this context, the ROM size versus cost for an 8-bit PIC looks like a great bargain, but remember that 1KB of ROM in the PIC is really worth only as much as 200 bytes of ROM in MSP430.”I wonder how it change if we consider long term usage of ROM, what about 1bit data corruption in flash memory after let’s say 5years. 1bit is enough to break down all program.In the same flash technology we have 4/5 more probability that our chip will be useless after X years.(I do not know too much about silicon, is this consideration relevant or not?)

By: Miro Samek

Miro Samek — Thu, 26 Mar 2009 13:33:00 +0000

Yes, Greg brings up an important point. I have been using the Student Edition of the MPLAB-PIC18 compiler, which does *not* allow most optimizations.But still, even if the code size were to improve 100% (which I doubt), PICmicro would still be the second worst CPU from the whole pack as far as code density is concerned. It is just mindboggling how bad the old 8-bit PIC is…PIC24 is a newer 16-bit ISA and according to my claim should fare much better than the old 8-bit PIC. In fact, one of the posts to the discussion forum at Embedded.com provides some benchmark data for PIC24. Please check the comments to the “Small is Beautiful” blog at http://www.embedded.com/design/215801305.

By: GregK

GregK — Thu, 26 Mar 2009 09:19:00 +0000

PIC18 is not modern architecture, I think (I am not expert) there is not fully support for stack in RAM.But You did not provide optimalization options what is very important, special in PIC18.I wonder how it looks on PIC24, I believe it will be much better then PIC18, special with -Os options. If I know how You did this test I can try do this for PIC24.

By: Bryce Schober

Bryce Schober — Mon, 09 Mar 2009 22:35:00 +0000

Wow, that’s pretty eye-opening!and:s/EQP-nano/QEP-nano/s/framework writing in C/framework written in C/