A C test suite (was: Opinions on Rowley CrossWorks for ARM)

[CBFalconer]

David Brown wrote:

Chris Hills wrote:

>Paul Curtis <pl*@rowley.co.ukwrites

.... 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>

[Walter Banks]

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..

[Leon]

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

[Paul Keinanen]

On 4 Nov 2006 00:30:24 -0800, "Leon" <le*********@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

[CBFalconer]

Paul Keinanen wrote:

"Leon" <le*********@bulldoghome.comwrote:

>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>

[Walter Banks]

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.

[Walter Banks]

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.

[Walter Banks]

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..

[Walter Banks]

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.

[Walter Banks]

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..

[Robert Adsett]

In article <45***************@bytecraft.com>, wa****@bytecraft.com
says...

>

CBFalconer wrote:

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

I am curious, what for example?

I seem to recall some of the minimum translation requirements would be
an issue. Isn't there a minimum maximal length string restriction?

Robert

--
Posted via a free Usenet account from http://www.teranews.com

[Robert Adsett]

In article <45***************@yahoo.com>, cb********@yahoo.com says...

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.

I rather like the idea. Does this mean you are volunteering to start
it? :)

Robert

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Robert Adsett wrote:

In article <45***************@yahoo.com>, cb********@yahoo.com says...

>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.

I rather like the idea. Does this mean you are volunteering to start
it? :)

If I were 20 years younger and in good health, I would. As it is I
can only offer advice. Been a lot a places, and seen a lot of
mistakes. The health can, I hope, be fixed.

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

[Robert Adsett]

In article <45***************@yahoo.com>, cb********@yahoo.com says...

Robert Adsett wrote:

I rather like the idea. Does this mean you are volunteering to start
it? :)

If I were 20 years younger and in good health, I would. As it is I
can only offer advice. Been a lot a places, and seen a lot of
mistakes. The health can, I hope, be fixed.

Here's hoping. Been through, a thankfully light, dose of that myself.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

[Joe Wright]

CBFalconer wrote:

Robert Adsett wrote:

>In article <45***************@yahoo.com>, cb********@yahoo.com says...

>>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.

I rather like the idea. Does this mean you are volunteering to start
it? :)

If I were 20 years younger and in good health, I would. As it is I
can only offer advice. Been a lot a places, and seen a lot of
mistakes. The health can, I hope, be fixed.

We don't get younger so you can forget that one. :-) I do hope you
regain your good health. Hang in there. Older is usually better, when
you consider the alternative.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Heathfield]

Robert Adsett said:

In article <45***************@bytecraft.com>, wa****@bytecraft.com
says...

>>
CBFalconer wrote:

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

I am curious, what for example?

I seem to recall some of the minimum translation requirements would be
an issue. Isn't there a minimum maximal length string restriction?

In C90, the implementation must support a minimum of 509 characters in a
logical source line and in a character string literal. 509 is also the
minimum value for the maximum number of characters produced by any single
fprintf conversion.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Walter Banks]

Robert Adsett 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?

I seem to recall some of the minimum translation requirements would be
an issue. Isn't there a minimum maximal length string restriction?

Good point combined with Richard's comment on fprintf. It is possible
to implement around this limit on processors like the PIC but I do not
know of anyone (including us) who have done so..

w..

[kyle york]

Greetings,

CBFalconer wrote:

Paul Keinanen wrote:

>>"Leon" <le*********@bulldoghome.comwrote:

>>>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.

Indirect calls and/or jumps are trivial on the 16 (& I think 12 & 14)
series so I don't see the problem. It's also fairly trivial to ignore
the call/return stack by passing the return address as a hidden
parametert to a function.

About the only problem I see is with only a single indirect register
allowing recursion is difficult.

>

--
Kyle A. York
Sr. Subordinate Grunt
DSBU