Opinions on Rowley CrossWorks for ARM

David Brown wrote:
> Chris Hills wrote:
>> Paul Curtis <plc@rowley.co.uk> writes
>>
... snip ...
>>>
>>> You can't argue with an BSI or ISO test certificate, no.  Can
>>> you point me to such a certificate for the compilers you
>>> advocate?  One of them?
>>
>> You can start with the Plum Hall and Perennial test suites?
> 
> I tried a quick google for "Plum Hall IAR", and looked at the
> first link:
> 
>   http://www.plumhall.com/cqs/tr/trackrecord.html
> 
> It would appear that IAR is a customer of Plum Hall, as is Red Hat.
> That by no means implies that gcc is certified by Plum Hall, but it
> does look like they take test suite testing seriously.
> 
> Another interesting find from google:
> 
>   http://gcc.gnu.org/ml/gcc/1998-07/msg00656.html
> 
>> Off line I should be interested in a serious discussion on compiler
>> testing.

The problem with the gcc test suite is that it is geared to the gcc
'standard', rather than the ISO standard.  A test suite should be
open-source, and there should probably be several of them (with
some commonality), one each for C90, C99, and C0X.  The tests
should be clearly tied to the standard.  There are several classes
of tests needed, i.e. conformance, detection of errors, and
quality.  The last will be controversial.

The unfortunate experience with the Pascal test-suite is a
warning.  This was excellent, but handed over to some British firm
(I forget the name) and basically lost.  It included portable means
of selecting individual tests, and of running an overall check. 
Thus GPL licencing is essential.  

The results should be very useful, even when systems fail.  For
example, where a compiler is aimed at a PIC many things are simply
not feasible.  Running the suite would point out those constructs
to the user, who can then avoid using them.  Maybe a sourceforge
project would be appropriate?  Such a suite would obviously be poor
at the start, but should mature.  The first task would be a method
of organizing the tests.  The Pascal suite is an excellent
example.  There should be no pressure to include C++ in the
testing, that is an entirely separate issue (and language).

Xposted from comp.arch.embedded to comp.lang.c and comp.std.c

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

David,

Your points were well taken.

It has been a couple years since we have done a significant amount of comparative testing of GCC vs commercial compilers. The conclusion at that time in some of the large platforms GCC was competitive (Not necessarily best but competitive) in the small
embedded processors GCC was losing ground against commercial offerings. We found that there was a large number of people that thought that GCC was good enough or used it because the educational institutions they attended used it. The tracked costs for GCC
was significantly higher than perceived costs. Supported distributions aka Rowley CrossWorks have lower overall costs than build your own from sources route.

w..



David Brown wrote:

> Walter Banks wrote:
> >
> > David Brown wrote:
> >
> >> Another interesting find from google:
> >>
> >> http://gcc.gnu.org/ml/gcc/1998-07/msg00656.html
> >
> > Interesting comments. Standard test suites are an eyopener
> > when first run on any compiler for the first time. They find
> > a lot of things, most come as a complete surprise.
> >
> > w..
> >
>
> The mail linked above is from 1998 - I have no idea how much test suite
> testing has been done on more modern gcc versions, or how gcc's own test
> suite compares with the big commercial suites.  I'd be curious to know,
> although I don't think it would influence my decisions on which compiler
> to use at any given time (I fully expect any compiler to work correctly
> for common code constructs, I manually check the assembly for awkward
> code such as volatile accesses or interrupt code, and I don't care what
> the compiler thinks of code worthy of the IOCCC, since I don't write
> such code).

CBFalconer wrote:

> For example, where a compiler is aimed at a PIC many things are simply
> not feasible.

I am curious, what for example?

w..

Walter Banks wrote:
> CBFalconer wrote:
>
> > For example, where a compiler is aimed at a PIC many things are simply
> > not feasible.
>
> I am curious, what for example?
> 
> w..

Some PICs only have three levels of stack.

Leon

On 4 Nov 2006 00:30:24 -0800, "Leon" <leon.heller@bulldoghome.com>
wrote:

>
>Walter Banks wrote:
>> CBFalconer wrote:
>>
>> > For example, where a compiler is aimed at a PIC many things are simply
>> > not feasible.
>>
>> I am curious, what for example?
>> 
>> w..
>
>Some PICs only have three levels of stack.

The only problem I can think of is saving the (code space) return
address into the data address space RAM. 

Usually even Harvard architecture have some means of transferring data
between code and data space, if these PICs do not have such feature,
implementing C would be problematic. As long as an indirect jump can
be performed, the situation is not hopeless.

Paul

Paul Keinanen wrote:
> "Leon" <leon.heller@bulldoghome.com> wrote:
>> Walter Banks wrote:
>>> CBFalconer wrote:
>>>
>>>> For example, where a compiler is aimed at a PIC many things are
>>>> simply not feasible.
>>>
>>> I am curious, what for example?
>>
>> Some PICs only have three levels of stack.
> 
> The only problem I can think of is saving the (code space) return
> address into the data address space RAM.
> 
> Usually even Harvard architecture have some means of transferring
> data between code and data space, if these PICs do not have such
> feature, implementing C would be problematic. As long as an
> indirect jump can be performed, the situation is not hopeless.

Not a PIC.  The only access to the return stack is the return
instruction.  As I set, not feasible.  And there is not enough
memory to allow creating an interpreter.

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>

CBFalconer wrote:

>   The only access to the return stack is the return
> instruction.  As I set, not feasible.  And there is not enough
> memory to allow creating an interpreter.

You mean something like the parallax basic stamp.

Leon wrote:

>
> > > For example, where a compiler is aimed at a PIC many things are simply
> > > not feasible.
> >
> > I am curious, what for example?
>
> Some PICs only have three levels of stack.
>

At least one C compiler built a soft stack on those parts. We chose to
seem that as a part limit with aggressive function chaining.

Paul Keinanen wrote:

> >> I am curious, what for example?
>
> The only problem I can think of is saving the (code space) return
> address into the data address space RAM.

Close it can be done but it requires some application planning.

> Usually even Harvard architecture have some means of transferring data
> between code and data space, if these PICs do not have such feature,
> implementing C would be problematic.

Data can be transferred from ROM to data space and in some parts
the ROM can be written from the application parts

w..

Leon wrote:

>
> > > For example, where a compiler is aimed at a PIC many things are simply
> > > not feasible.
> >
> > I am curious, what for example?
>
> Some PICs only have three levels of stack.
>

At least one C compiler built a soft stack on those parts. We chose to
see that as a part limit and partly compensated with aggressive function
chaining.