Cygnal / SDCC performance data here

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