LPC900/80C51 Compiler Toolchain

In news: snipped-for-privacy@phaedsys.demon.co.uk timestamped Sun, 24 Jun

2007 23:01:17 +0100, Chris Hills posted: "[..] [..] much better compression [..] I have seen several programs that the Keil 2/4/8k limited compilers could get to run on a 51 that the unlimited SDCC could not. The problem is when they want to add "just one more feature" without changing the whole design. For example... smart cards and mobile SIMS and many other things. Especially when by law you need to add something to an old system or to change some IO because they are new sensors. Ideally you would scrap the whole system and start again to ad a small change to an end of life product."

If you intend to have some spare memory then the smallest output from the compilers is not necessarily the most important criterion.

"[..] I do find it strange that people are arguing so strongly for using second rate tools in their profession."

Who has argued for using second rate tools in their profession? Provide exact references to justify that claim.

"What would you think of a doctor, dentist, aeronautical engineer who argued the same?"

Microcontrollers running software are used by such people. Should they use instead things such as FPGAs because FPGAs are better? FPGAs are used by such people. Should they use ASICs instead because FPGAs are inferior? Electronics can suffer from electromagnetic interference. Should such people not use electronics?

Chris Hills said in news: snipped-for-privacy@phaedsys.demon.co.uk in the thread "Re: What's more important optimisations or debugging?" on 2007 June 4th: "[..]

Note some safety critical systems do not permit optimisations."

Chris Hills said in news: snipped-for-privacy@phaedsys.demon.co.uk in the thread "Re: What's more important optimisations or debugging?" on 2007 June 13th: "[..]

[..] disable all compiler optimisations."

Does Chris Hills berate people for disabling all optimizations?

Regards, Colin Paul Gloster

There are optimisations done at all stages. The front-end can do some optimisations (like turning "x = y + 2*4" into "x = y + 8"). Then the code is turned into an intermediary representation, and some optimisations are done during this "middle-end" part (like turning "x = y + 2; z = y + 2;" into "x = y + 2; z = x;"). Then comes the back-end which does the code generation, and some optimisations are applied after that (like turning "jsr foo; ret" into "jmp foo").

There are a few reasons for using unoptimised code, that I can think of. One is that it is easy for source code debugging (not assembly level debugging - that is easier with a bit of optimisation). Another is, as you say, during testing and development of the tools themselves.

Would you *please* learn to use a newsreader? You have some interesting things to say, some of which warrant response, but have such an absurd quoting "style" that it is impossible to hold a proper thread of conversation with you.

Gcc 2.9x for the ARM was very poor, as pretty much everyone knows. Many proponents of closed source alternatives are so happy about this that they make all sorts of claims of generating code that is several times faster than gcc's code, when they really mean the early ARM gcc.

That's total and utter drivel - certainly regarding gcc, but also regarding any other compiler I have ever used.

With modern compilers (gcc or otherwise), there is seldom good reason for hand-optimising your assembly unless you are taking advantage of specific features that your compiler is unaware of. It is often more useful to compile to assembly, study the assembly, and then modify your source code to get better results.

... snip ...

You are confused as to the use of an 'SP'. This is a stack pointer, which is altered whenever a value is pushed or popped. It can't be constant, so the compiler has to keep track of it. You are probably thinking of a 'BP', or block pointer, which normally holds specific SP values such as the value on function entry.

--
 
 
 
                        cbfalconer at maineline dot net

David Brown wrote: ** to Colin Paul Gloster, top-posted **

I second that motion.

--
 
 
 
                        cbfalconer at maineline dot net

Stack frames are only needed for functions that are re-entrant. If a function does not need to be re-entrant quite a bit of execution time and ram bandwidth can be saved by having compile time allocation the auto/local variables in some overlaid ram space.

Regards

Walter Banks

-- Byte Craft Limited Tel. (519) 888-6911

email snipped-for-privacy@bytecraft.com

Paul Taylor wrote:

I agree.

w..

The down side to debugging with optimization off is that the code that is shipped is not the code with an experience base that has been debugged.

The optimizations that make a difference are not easily turned off or on without a serious impact on overall tool implementations.

Walter Banks

-- Byte Craft Limited Tel. (519) 888-6911

email snipped-for-privacy@bytecraft.com

In article , CBFalconer writes

Strange for me to agree with both David and CBF at the same time but I have been asking Paul to change his style of quoting to something that is readable.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

You certainly don't want to just do your debugging and testing on some low-optimisation test version. But source level debugging of unoptimised code can be a useful aid when your code is not working as expected. You can single-step through code reliably, and view each variable with values that match their values at the source code level, and thus can see what is going on in a different way. It's an aid, but it is not an alternative to testing and debugging the code you will actually ship.

Oh well. It is a strange world. :-)

--
 
 
 
                        cbfalconer at maineline dot net

No. If you remove the frame pointer and don't change anything else, you're left with a constantly changing stack pointer. This makes it harder to access variables on the stack. For example, if the SP+offset addressing mode has a limited offset, you may be able to use that addressing mode only if the offset is small enough. Additionally, as David said, most debuggers can't deal with these changing offsets (Dwarf3 can describe this, but few debuggers support this format, let alone the builtin interpreter that can do this stuff).

The solution to this is to use fixed size stackframe across the whole function - ie. SP does not change. This is always possible as you can reserve space for function arguments at fixed offsets from SP and store them rather than push. The advantage is that you avoid having to adjust SP to undo pushes, which further improves the saving.

Although the fixed-size frame optimization is orthogonal to removing the frame pointer, the advantages (debugging is possible and code usually more efficient) mean that they typically go together.

Wilco

I meant code that doesn't contain any inefficiencies on the critical paths and making full use of the target architecture. Such code is usually compiler independent and will result in efficient code on most compilers, but of course not all compilers get close to what one could write in assembler. As an example, I often make use of ARM's conditional execution by writing if (x != 0 && y != 0) z++; and expect it to avoid branches:

CMP x,#0 CMPNE y,#0 ADDNE z,z,#1

The 40% extra code was due to not recognising cases like the above (using 2 extra branches) and other ARM specific instructions. There was also code that tested these optimised functions, and GCC generated only 5% worse code here. Unfortunately the size or performance of the test code didn't matter...

Wilco

"Usually compiler independent"? On what standard are you depending? Is this a documented optimization for a particular ARM compiler, or was this discovered by trial and error with a particular compiler?

BTW, using an xscale-elf-gcc --version 4.02 that I have hanging around, I get the following:

---- arm.cpp --- int f(int x,int y,int z) { if (x != 0 && y != 0) z++; return z; }

-----------------

# xscale-elf-gcc -c -O2 arm.cpp # xscale-elf-objdump --disassemble arm.o arm.o: file format elf32-littlearm

Disassembly of section .text:

00000000 : 0: e3500000 cmp r0, #0 ; 0x0 4: 13510000 cmpne r1, #0 ; 0x0 8: e1a00002 mov r0, r2 c: 12820001 addne r0, r2, #1 ; 0x1 10: e12fff1e bx lr

Since your "if (x != 0 && y != 0) z++;" was out of context, this was the closest I could come in 2 minutes time ;-)

In the context of a larger function where the compiler has more visibility into the context ymmv.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Thanks for the clear description

:-)

Paul.

IMO you are designing some ugly code generators. For example, consider the addressing code need to push versus a dedicated store. Something like one byte for the push, and three up for the store.

--
 
 
 
                        cbfalconer at maineline dot net

That's very much dependent on the cpu architecture. On some architectures, storing data at (SP + offset) takes exactly the same time and space as a push - on others, it is significantly different. On superscaler 32-bit RISC cpus it is likely that the (SP + offset) store will be faster, as a push which changes SP will lead to stalls. On an AVR, the push is a single instruction which is much smaller and faster as there is no (SP + offset) mode.

And for some types of function, trying to use a single fixed-size stack frame will make a real pig's ear out of the code, and result in lots of wasted stack space - a frame pointer really does give better code for some functions.

As with anything in this field, unless you are going to give specific and tight limits on the processors and the type of code, any generalisations like this are going to be wrong.

Oh bugger! I am going to have to agree with you again :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

It's possible to temporarily increment the stack pointer and then push the arguments so you get the best of both worlds. This is never worse than pushing first and later incrementing SP. Also note that on many CPUs the first few arguments are passed by registers, so the cost of storing stack arguments is less important in such cases.

Indeed, and many RISCs don't even support push/pop.

Actually on AVR push has the same size and speed as the (base + offset) addressing mode. Usually the Y or Z register is used as the actual stack. SP only supports push/pop/call/return, so it is useless for general parameter passing or local variables. Using a frame pointer would be a very bad idea as it takes many instructions to set up and uses up another 2 registers.

You can always find functions where it is worse of course, but omitting frame poiners and fixed size frames are better on average on many CPUs. Optimization is all about improving things on average.

Wilco