clyde
HI-TECH team member
Reged: Oct 16 2003
Posts: 622
|
|
There is a new build of the HI-TECH C PRO for Silicon Labs 8051 available. See the "Testing adminstration" forum for download details.
We have spent some considerable time on performance improvements and testing. The results of the Dhrystone benchmark as used by Keil are as follows:
Code:
Dhrystone benchmark for C8051F120. Assumes a 22.1184 MHz crystal.
HI-TECH PRO for SiLabs V9.70 Beta build 2241:
compile like this:
c51 dhry.c time.c f120.c --chip=c8051f120
Resulting files are dhry.omf and dhry.hex
Results compared to Keil:
HI-TECH C PRO V7.70 Beta build 2241:
Memory Summary:
Program space used E10h ( 3600) of 10000h bytes ( 5.5%)
Internal Data used 8Fh ( 143) of E0h bytes ( 63.8%)
External Data used 1512h ( 5394) of 2000h bytes ( 65.8%)
Execution speed: 3753 dhrystones/sec.
Keil 8051 C compiler:
Program Size: data=15.1 xdata=5525 code=5743
Execution speed: 3300 dhrystones/sec
HI-TECH C generates 35% smaller code size, and the code runs 14% faster.
The attached file contains the full source code for the test.
Edited by clyde (Sat May 03 2008 05:19 PM)
|
JWaclawek
Tester
Reged: Apr 11 2008
Posts: 3
|
|
Impressive indeed.
I confess I did not dig deeper into the details yet, but the compiler used an unusually large amount of internal RAM (used 8Fh ( 143) of E0h bytes). The stack pointer is initialised even higher - mov sp,#0e5h - why?
This leaves a surprisingly small space for the stack.
Does this mean that the stack consumption is being calculated at compilation time and the internal RAM is adjusted so that the stack will never run out of space?
Jan Waclawek
|
Dan Henry
Guru
Reged: Oct 16 2003
Posts: 3387
Loc: Boulder, Colorado U.S.A.
|
|
Quote:
Does this mean that the stack consumption is being calculated at compilation time and the internal RAM is adjusted so that the stack will never run out of space?
I am not speaking for Mr. Stubbs, but if you use the -M option to generate a linker map file, you should be able to infer some toolchain intelligence with regard to stack size and position.
|
clyde
HI-TECH team member
Reged: Oct 16 2003
Posts: 622
|
|
Hi Jan,
yes, the compiler is using internal memory where possible instead of XDATA memory. This contributes to the speed and space improvements. Even more intensive use of internal memory is planned, which should further improve the dhrystone results.
Yes, the stack is calculated automatically. Although the positioning of the stack at the top of the internal memory is more of a side effect that a design choice, it does have the advantage during testing (at least on simulators) that any stack overflow is caught immediately.
The only time the automatically calculated stack is inadequate is if a recursive function is present. The --addstack option is required in that case, e.g. one of our tests is the Towers of Hanoi program, which requires --addstack=92 to allocate additional stack space. The compiler detects recursive function calls, but it's computationally impossible to determine at compile time how deep those calls will be at run time.
Of course recursive functions are almost never used in real embedded applications.
The stack required for interrupt routines etc. is calculated automatically and added to the main-line code stack requirement. The dhrystone test demonstrates that (timer interrupt).
Clyde
Edited by clyde (Sat May 03 2008 04:56 PM)
|
clyde
HI-TECH team member
Reged: Oct 16 2003
Posts: 622
|
|
Hey Dan, no need to be so formal....
Clyde
|
JWaclawek
Tester
Reged: Apr 11 2008
Posts: 3
|
|
Quote:
.... if you use the -M option to generate a linker map file....
Ooooh, thanks Dan, I was trying to figure out the symbol file, but this really makes a difference!
I suppose I should have been reading the fine manual by now... 
Jan
|
JWaclawek
Tester
Reged: Apr 11 2008
Posts: 3
|
|
Clyde,
thanks. Looking forward to more magic! ;-)
Jan
PS. What about embedded assembler, I suppose I would need to specify that's stack usage manually, too, is it?
Edited by JWaclawek (Mon May 05 2008 02:37 AM)
|
Dan Henry
Guru
Reged: Oct 16 2003
Posts: 3387
Loc: Boulder, Colorado U.S.A.
|
|
Quote:
I suppose I should have been reading the fine manual by now.
Be aware that it also is in the 'beta' stage and has some content missing.
|
Dan Henry
Guru
Reged: Oct 16 2003
Posts: 3387
Loc: Boulder, Colorado U.S.A.
|
|
Quote:
What about embedded assembler ...
Check the "C Language Features" / "Mixing C and 8051 assembler code" section of the manual. I just tried the #asm, #endasm, and asm() directives and they work as advertised.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
