Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Should embedded systems compilers be trusted

Reply
Thread Tools

Should embedded systems compilers be trusted

 
 
Tomás Ó hÉilidhe
Guest
Posts: n/a
 
      04-20-2008

There are a few guarantees I exploit in the C Standard. For instance,
I might write

(unsigned)-1

to get the maximum value for an unsigned integer.

Also, I might rely on things such as:

memset(data,-1,sizeof data)

to set all bits in a chunk of memory to 1.

I'm using an embedded systems compiler now though and I'm hesitant to
trust it with things like this. I've already come across the following
quirks:

1) You can't define a variable as const unless it can be put in the
chip's ROM.
2) There's no stack used by default; you must define a function as
"reentrant" if you want a stack.

To the people here who have experience with embedded systems C
compilers, how do you feel about trusting its C compliance? Some
issues I'd be concerned about are:

1) int being at least 16-Bit
2) long being at least 32-Bit
3) Compliant conversion between signed and unsigned types

I'm using the PIC C compiler to program the PIC16F684 chip.
 
Reply With Quote
 
 
 
 
Barry Schwarz
Guest
Posts: n/a
 
      04-20-2008
On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás Ó hÉilidhe
<(E-Mail Removed)> wrote:

>
>There are a few guarantees I exploit in the C Standard. For instance,
>I might write
>
> (unsigned)-1
>
>to get the maximum value for an unsigned integer.


The standard guarantees that values for unsigned integers behave
nicely when they wrap in either direction. However, your code will
not work for an integer type wider than int. For C89 you probably
need (unsigned long) -1L and for C99 (unsigned long long) -1LL.

>
>Also, I might rely on things such as:
>
> memset(data,-1,sizeof data)
>
>to set all bits in a chunk of memory to 1.
>


This only works on 2s-complement systems.

>I'm using an embedded systems compiler now though and I'm hesitant to
>trust it with things like this. I've already come across the following
>quirks:
>
>1) You can't define a variable as const unless it can be put in the
>chip's ROM.
>2) There's no stack used by default; you must define a function as
>"reentrant" if you want a stack.
>
>To the people here who have experience with embedded systems C
>compilers, how do you feel about trusting its C compliance? Some
>issues I'd be concerned about are:
>
>1) int being at least 16-Bit
>2) long being at least 32-Bit
>3) Compliant conversion between signed and unsigned types
>
>I'm using the PIC C compiler to program the PIC16F684 chip.



Remove del for email
 
Reply With Quote
 
 
 
 
Robert Gamble
Guest
Posts: n/a
 
      04-20-2008
On Apr 20, 2:28 pm, Barry Schwarz <(E-Mail Removed)> wrote:
> On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás Ó hÉilidhe
>
> <(E-Mail Removed)> wrote:
>
> >There are a few guarantees I exploit in the C Standard. For instance,
> >I might write

>
> > (unsigned)-1

>
> >to get the maximum value for an unsigned integer.

>
> The standard guarantees that values for unsigned integers behave
> nicely when they wrap in either direction. However, your code will
> not work for an integer type wider than int. For C89 you probably
> need (unsigned long) -1L and for C99 (unsigned long long) -1LL.


What makes you think that?

--
Robert Gamble
 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      04-20-2008
Tomás Ó hÉilidhe wrote:
> There are a few guarantees I exploit in the C Standard. For instance,
> I might write
>
> (unsigned)-1
>
> to get the maximum value for an unsigned integer.


This is required behaviour for unsigned integer types.

> Also, I might rely on things such as:
>
> memset(data,-1,sizeof data)
>
> to set all bits in a chunk of memory to 1.


That function need not be available on a freestanding implementation.
If it is available though, the behaviour should work as you describe.

> I'm using an embedded systems compiler now though and I'm
> hesitant to trust it with things like this. I've already come across
> the following quirks:
>
> 1) You can't define a variable as const unless it can be put in the
> chip's ROM.
> 2) There's no stack used by default; you must define a function as
> "reentrant" if you want a stack.
>
> To the people here who have experience with embedded systems C
> compilers, how do you feel about trusting its C compliance? Some
> issues I'd be concerned about are:
>
> 1) int being at least 16-Bit
> 2) long being at least 32-Bit
> 3) Compliant conversion between signed and unsigned types
>
> I'm using the PIC C compiler to program the PIC16F684 chip.


Rather than asking if the code will work on possibly non-conforming
implementations, wouldn't it be better to get (or build) yourself some
conformance tests and only use compilers that _are_ conforming?

If the source is to be compiled by the client, then I suggest you
charge significant amounts of money for any service contract
you enter into based on whether they are using a conforming
compiler or not.

--
Peter
 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      04-21-2008
On Sun, 20 Apr 2008 15:21:23 -0700 (PDT), Robert Gamble
<(E-Mail Removed)> wrote:

>On Apr 20, 2:28 pm, Barry Schwarz <(E-Mail Removed)> wrote:
>> On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás Ó hÉilidhe
>>
>> <(E-Mail Removed)> wrote:
>>
>> >There are a few guarantees I exploit in the C Standard. For instance,
>> >I might write

>>
>> > (unsigned)-1

>>
>> >to get the maximum value for an unsigned integer.

>>
>> The standard guarantees that values for unsigned integers behave
>> nicely when they wrap in either direction. However, your code will
>> not work for an integer type wider than int. For C89 you probably
>> need (unsigned long) -1L and for C99 (unsigned long long) -1LL.

>
>What makes you think that?


For sake of discussion, let us assume a 16 bit int and a 32 bit long
and the common UINT_MAX and ULONG_MAX for these sizes.

The statement
unsigned long x = (unsigned)-1;
will set x to 65535 (the value of the right hand side) which is
0x0000ffff, hardly the maximum value for this unsigned long.


Remove del for email
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-21-2008
Jack Klein <(E-Mail Removed)> writes:
> On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás Ó hÉilidhe
> <(E-Mail Removed)> wrote in comp.lang.c:

[...]
>> I'm using an embedded systems compiler now though and I'm hesitant to
>> trust it with things like this. I've already come across the following
>> quirks:
>>
>> 1) You can't define a variable as const unless it can be put in the
>> chip's ROM.

>
> This is not a quirk. C does not define things like "ROM" or "RAM".
> You told the compiler that you wanted to define an object that would
> not be changed. The compiler obligingly put it into memory where it
> could not be changed. What's your objection?


Suppose I want to define the following (inside a function):

const time_t now = time();

Or substitute for some other function for time() if it's a
freestanding implementation that doesn't support <time.h>.

"const" in C means read-only. It sounds like the C-like compiler
being described treats "const" as meaning truly constant, i.e.,
capable of being evaluated at compile time. If it requires
const-qualified objects at block scope to have constant initializers,
it's not a conforming C compiler.

[...]

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Robert Gamble
Guest
Posts: n/a
 
      04-21-2008
On Apr 20, 11:59 pm, Barry Schwarz <(E-Mail Removed)> wrote:
> On Sun, 20 Apr 2008 15:21:23 -0700 (PDT), Robert Gamble
>
>
>
> <(E-Mail Removed)> wrote:
> >On Apr 20, 2:28 pm, Barry Schwarz <(E-Mail Removed)> wrote:
> >> On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás Ó hÉilidhe

>
> >> <(E-Mail Removed)> wrote:

>
> >> >There are a few guarantees I exploit in the C Standard. For instance,
> >> >I might write

>
> >> > (unsigned)-1

>
> >> >to get the maximum value for an unsigned integer.

>
> >> The standard guarantees that values for unsigned integers behave
> >> nicely when they wrap in either direction. However, your code will
> >> not work for an integer type wider than int. For C89 you probably
> >> need (unsigned long) -1L and for C99 (unsigned long long) -1LL.

>
> >What makes you think that?

>
> For sake of discussion, let us assume a 16 bit int and a 32 bit long
> and the common UINT_MAX and ULONG_MAX for these sizes.
>
> The statement
> unsigned long x = (unsigned)-1;
> will set x to 65535 (the value of the right hand side) which is
> 0x0000ffff, hardly the maximum value for this unsigned long.


I certainly agree that (unsigned) -1 is not going to yield ULONG_MAX.
I took your original comment to imply that (unsigned long) -1 would
not produce the desired results without the L suffix, that is where my
objection stemmed from.

--
Robert Gamble
 
Reply With Quote
 
Hallvard B Furuseth
Guest
Posts: n/a
 
      04-21-2008
Peter Nilsson wrote:
> Tomás Ó hÉilidhe wrote:
>> memset(data,-1,sizeof data)
>> to set all bits in a chunk of memory to 1.

>
> That function need not be available on a freestanding implementation.
> If it is available though, the behaviour should work as you describe.


Only on 2s-complement systems, as Barry pointed out.
OTOH (unsigned char)-1 always works.

--
Hallvard
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      04-21-2008
In article <(E-Mail Removed)>,
Barry Schwarz <(E-Mail Removed)> wrote:
>On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás Ó hÉilidhe
><(E-Mail Removed)> wrote:


>>Also, I might rely on things such as:


>> memset(data,-1,sizeof data)


>>to set all bits in a chunk of memory to 1.


>This only works on 2s-complement systems.


C89 4.11.6.1 The memset Function

Description

The memset function copies the value of c (converted to an
unsigned char) into each of the first n charactes of the object
pointed to by s.


From this we can deduce that memset with value -1 will write UCHAR_MAX
to the n locations.

Is there ever a time when UCHAR_MAX is not all bits 1? The definition
of unsigned (C89 3.1.2.5) indicates that,

For each of the signed integer types, there is a corresponding
(but different) unsigned integer type (designated by the keyword
unsigned) that uses the same amount of storage (including
sign information) [...]

And doesn't C99 guarantee that unsigned char will have no padding bits
or trap representations?

--
"Product of a myriad various minds and contending tongues, compact of
obscure and minute association, a language has its own abundant and
often recondite laws, in the habitual and summary recognition of
which scholarship consists." -- Walter Pater
 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      04-21-2008
Hallvard B Furuseth wrote:
> Peter Nilsson wrote:
> > Tom�s � h�ilidhe wrote:
> > > memset(data,-1,sizeof data)
> > > to set all bits in a chunk of memory to 1.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > That function need not be available on a
> > freestanding implementation.
> > If it is available though, the behaviour should
> > work as you describe.

>
> Only on 2s-complement systems, as Barry pointed out.


The Barry is wrong.

> OTOH (unsigned char)-1 always works.


Which is precisely what memset will do.

7.21.6.1p2 "The memset function copies the value of c
(converted to an unsigned char) ..."

--
Peter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Benchmarking C compilers for embedded systems Philipp Klaus Krause C Programming 8 09-30-2011 12:11 PM
How to determine a IE embedded control be full trusted? idiot ASP .Net 0 08-30-2006 02:33 AM
Voip PBX,Private Phone Systems,PBX Telephone Systems, Business Phone Systems broadbandera@gmail.com UK VOIP 9 07-24-2006 03:44 PM
commercial c compilers vs free c compilers geletine C Programming 33 07-07-2006 05:21 AM
Embedded C++ Compilers kieran@cyrocom.co.uk C++ 3 05-12-2005 01:56 AM



Advertisments