EmbeddedRelated.com
Forums
Memfault State of IoT Report

Cygnal / SDCC performance data here

Started by Richard April 13, 2004
I updated the microcontroller performance comparison data over the weekend
to include a Cygnal / SDCC combination.

As always - I think the data is useful for comparison, but it does not claim
to be particularly scientific.
http://www.FreeRTOS.org/PC


In article <BDMec.72850$Id.52905@news-binary.blueyonder.co.uk>, Richard
<nowhere@nospamthanks.com> writes
>I updated the microcontroller performance comparison data over the weekend >to include a Cygnal / SDCC combination. > >As always - I think the data is useful for comparison, but it does not claim >to be particularly scientific. >http://www.FreeRTOS.org/PC
Hi, Intresting. I loked at the Cygnal (8051 ) version. The numbers are meaningless for 2 reasons:- 1 There is no source code provided. 2 The setup says " Peep hole optimization was turned off as it caused compilation errors. All other optimization was left at default." So the compiler is buggy and unstable. Without the source code no one has any idea what you are actually measuring. Try drhystones, whetstones and the Paranoia tests , publish the source and then the numbers might mean something. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> Intresting. I loked at the Cygnal (8051 ) version. The numbers are > meaningless for 2 reasons:- > > 1 There is no source code provided. > > 2 The setup says " Peep hole optimization was turned off as it caused > compilation errors. All other optimization was left at default." So the > compiler is buggy and unstable. > > Without the source code no one has any idea what you are actually > measuring. > > > Try drhystones, whetstones and the Paranoia tests , publish the source > and then the numbers might mean something.
The C source code executed on each microcontroller is exactly the same so the numbers just give a comparison between the microcontrollers - not any absolute result. I don't want to provide the exact source code because comparing performance is a massive topic for which there are many arguments and counter arguments on any number of issues, and I don't want to get into all that. I take the readings for my own purposes and make them available in case they are of interest to others - but like I said I don't make any claims that they are rock solid.
> I don't want to provide the exact source code because comparing performance > is a massive topic for which there are many arguments and counter arguments
WITH the sourcecode, the numbers are subject to argument. WITHOUT the sourcecode, the number are worthless. You might as well take the clock speed, divide by the average number of cycles per instruction for the given core, and multiply by the data bus width.
"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message
news:608b6569.0404130704.3d07a0f0@posting.google.com...
> > I don't want to provide the exact source code because comparing
performance
> > is a massive topic for which there are many arguments and counter
arguments
> > WITH the sourcecode, the numbers are subject to argument. > > WITHOUT the sourcecode, the number are worthless. You might as well > take the clock speed, divide by the average number of cycles per > instruction for the given core, and multiply by the data bus width.
And then play "guess how many waitstates" :-D

Memfault State of IoT Report