嵌入式系统编译器是否值得信任 [英] Should embedded systems compilers be trusted

问题描述

我在C标准中有一些保证。例如，

我可能会写


（未签名）-1


来获取最大价值无符号整数。


另外，我可能依赖于以下内容：


memset（数据，-1，sizeof数据）

将一块内存中的所有位设置为1.


我现在正在使用嵌入式系统编译器而且我很犹豫

相信这样的事情。我已经遇到过以下

怪癖：


1）你不能将变量定义为const，除非它可以放入

芯片的ROM。

2）默认情况下没有使用堆栈;你必须定义一个函数

" reentrant"如果你想要一个堆栈。


对于那些有嵌入式系统经验的人来说，你有什么感觉信任C合规？一些

问题我会关注的是：


1）int至少为16位
2）长期至少为32位


我正在使用PIC C编译器对PIC16F684芯片进行编程。

解决方案

Tomásóhéilidhe < to *@lavabit.com写信息

新闻：02 ***************************** ***** @ 26g2000h sk.googlegroups.com ...

>

我有一些保证我在C标准。例如，

我可能会写


（未签名）-1


来获取最大价值无符号整数。


另外，我可能依赖于以下内容：


memset（数据，-1，sizeof数据）

将一块内存中的所有位设置为1.


我现在正在使用嵌入式系统编译器而且我很犹豫

相信这样的事情。我已经遇到过以下

怪癖：


1）你不能将变量定义为const，除非它可以放入

芯片的ROM。

2）默认情况下没有使用堆栈;你必须定义一个函数

" reentrant"如果你想要一个堆栈。


对于那些有嵌入式系统经验的人来说，你有什么感觉信任C合规？一些

问题我会关注的是：


1）int至少为16位
2）长期至少为32位


我正在使用PIC C编译器对PIC16F684芯片进行编程。

在我使用的大多数嵌入式编译器中，他们已经在

的在线帮助中找到了一个部分包装或手册中他们总结了他们所针对的

标准（例如C89）以及它们的变化来自

。诸如consts的存储位置和堆栈行为之类的项目对我已经使用过的人来说非常普遍。其他一些编译器，另一方面，在某个地方有一个评论，他们是基于C的。或在C中有
根或者其他一些。在这些情况下，所有的赌注都差不多。


对于你提到的物品（整数/多头，转换的大小），包裹

经常提供定义（ i16，int32，uint8）你将使用而不是

标准名称来确保你编码的大小被保留并且是非常明确的

如何进行转换。即使有了这些，我通常会尽可能早地在系统中添加一些代码来验证编码

关于大小，转换，堆栈操作，初始化等的假设。

开启并停止机器，如果错误则会显示错误信息。这些

测试应该只在开发环境中触发，并且你可能认为他们从来没有真正发生过，但是我让他们离开了/>
几次（通常是在开发包升级之后）和

他们已经为我节省了很多悲伤追踪会有什么微妙的结果

错误。在一种情况下，其中一个由于处理I / O 16位数量的方式由于

而被更改时触发。前面的部分只有8位

I / O，新的那个有8和16，但前一位工程师认为他/ b $ b可以抛出16位数据和8位端口，它会截断

他的位。嗯，确实如此，但新部分的工作方式不同。当代码空间

有限时，我会将这些测试放在一些#define中进行调试或开发。


您可以尝试comp.arch.embedded对于这个问题。从我多年来看到的

开始，这个小组几乎假设你使用的是兼容的

编译器。


- 比尔

On Sun，2008年4月20日04:18:56 -0700（太平洋时间），Tomásóhéilidhe

< to*@lavabit.comwrote：

>
我在C标准中有一些保证。例如，
我可能会写$

（无符号）-1

获取无符号整数的最大值。

该标准保证无符号整数的值在它们向任一方向包装时表现良好。但是，对于比int更宽的整数类型，您的代码将无法使用
。对于C89，你可能需要（b）（无符号长）-1L和C99（无符号长long）-1LL。

>

memset（数据，-1，sizeof数据）

设置一大块的所有位内存为1.

这仅适用于2s补码系统。

> I''我现在使用嵌入式系统编译器，我很犹豫是否相信这样的事情。我已经遇到过以下的怪癖：

1）你不能将变量定义为const，除非它可以放在
芯片中ROM。
2）默认情况下没有使用堆栈;你必须定义一个函数
reentrant如果你想要一个堆栈。

对于那些有嵌入式系统C编译器经验的人来说，你如何相信它的C合规性？我要关注的一些问题是：

1）int至少为16位
2）长期至少32位
3 ）有符号和无符号类型之间的兼容转换

我正在使用PIC C编译器对PIC16F684芯片进行编程。

删除电子邮件的del

On Sun，2008年4月20日04:18:56 -0700（PDT ），Tomásóhéilidhe

< to *@lavabit.comwrote in comp.lang.c:

>

我在C标准中有一些保证。例如，

我可能会写


（未签名）-1


来获取最大价值无符号整数。

对，或任何其他无符号类型，（无符号类型）-1。或者，如果你是
分配或初始化任何无符号整数类型，只需简单

旧普通-1。

另外，我可能依赖于以下内容：


memset（数据，-1，sizeof数据）


设置所有位一大块记忆到1.

真的吗？我从来没有，也没想到有谁拥有。你真的这么做吗？为什么？我从来不需要所有

位1的内存块。当然，如果数组是无符号整数

类型之一，那么你除非这些类型包含填充物，否则我很安全。我从来没有听说过任何用于嵌入式炒锅的东西。

我现在正在使用嵌入式系统编译器而且我很犹豫

相信这样的东西。我已经遇到过以下

怪癖：


1）你不能将变量定义为const，除非它可以放入

芯片的ROM。

这不是怪癖。 C没有定义诸如ROM之类的东西。或者RAM。

你告诉编译器你想要定义一个不会改变
的对象。编译器必须将它放入内存中，因为它无法更改
。你有什么异议？

2）默认情况下没有使用堆栈;你必须定义一个函数

" reentrant"如果你想要一个堆栈。

这个是一些古老的8-bitter的真正问题。

他们对硬件的大小有严格的硬件限制堆栈。我没有（不会）使用PIC，这个架构太奇怪了，没有足够的理由，但是8051衍生品也有同样的问题。

对于那些有嵌入式系统经验的人来说，您对信任其C合规性感觉如何？一些

问题我会关注的是：

坦率地说，你问的是错误的问题。即使它是

正确的问题，你应该在comp.arch.embedded

而不是在这里问它。


信任不是正确的词。大多数嵌入式编译器，尤其是那些称自己为ANSI C的嵌入式编译器。编译器（都是它们），

提供了C语言的一个子集，因此根本不符合b $ b。

1）int至少为16位

ISTM一个编译器，我认为对于更老的PIC来说更多/>
有12位int的限制。

2）长期至少为32位

我似乎还记得一个嵌入式编译器长时间使用

少于32位的东西。

3 ）有符号和无符号类型之间的兼容转换


我正在使用PIC C编译器对PIC16F684芯片进行编程。

正如其他人所指出的那样，几乎每个编译器都带有

文档，无论是硬拷贝还是电子文档。文档将

告诉你编译器在这些和其他情况下做了什么。


但我仍然认为信任是错误的概念。 C被设计（并且定义为
）作为一般有效的系统计算语言，用于计算。它的许多功能和效率使它对嵌入式系统非常有用。但是许多嵌入式系统都具有完全实现C的硬件架构，或者完全不可能或者非常不切实际。


如果你正在为一个新的架构使用一个新的编译器，熟悉它自己的文档，特别是在实现定义的语言区域和区域。哪里有文件

符合标准的限制或遗漏。


如果在阅读并理解

之后仍有疑问文档，联系供应商的技术支持，如果存在的话。或者

甚至更好，编写和构建代码。通过检查生成的

目标代码或通过测试代码来了解它的作用。


信任的概念对于一个嵌入式编译器，从某种意义上来说，你在这里使用它的b $ b似乎与我希望经验丰富的嵌入式系统开发人员要做的尽职调查有点不一样。 br />

-

杰克克莱恩

主页： http://JK-Technology.Com

常见问题解答

comp.lang.c http://c-faq.com/

comp.lang.c ++ < a rel =nofollowhref =http://www.parashift.com/c++-faq-lite/target =_ blank> http://www.parashift.com/c++-faq-lite/

alt.comp.lang.learn.c-c ++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

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.

解决方案

"Tomás ó héilidhe" <to*@lavabit.comwrote in message
news:02**********************************@26g2000h sk.googlegroups.com...

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

In most embedded compilers I''ve used, they''ve had a section either in the
on-line help for the package or in the manual where they summarized the
standard they were targeting (such as C89) and what their variations from
that were. Items such as the storage location of consts and stack behavior
are pretty common for those I''ve used. Some other compilers, on the other
hand, have had a comment somewhere that they were "based on C" or "having
roots in C" or some such. In these cases all bets were pretty much off.

For the items you mention (size of ints/longs, conversion) the packages
often supply definitions (i16, int32, uint8) which you''d use instead of the
standard names to ensure that the sizes you''ve coded for are kept and are
quite explicit on how conversions are done. Even with these, I usually put
a bit of code as early in the system as I can that verifies the coding
assumptions about sizes, conversions, stack operation, initialization and so
on and stops the machine with some error indication if they''re wrong. These
tests should really only ever trigger in the development environment, and
you might figure they''d never really happen, but I have had them go off a
couple of times (usually right after a development package upgrade) and
they''ve saved me a lot of grief tracking down what would have been subtle
bugs. In one case one of them triggered when the part was changed due to
the way it handled I/O 16 bit quantities. The earlier part only had 8 bit
I/O, the new one had 8 and 16, but the previous engineer had assumed he
could throw 16 bit data and a 8 bit port and it would truncate the bits for
him. Well, it did, but the new part worked it differently. When code space
was limited, I''d put these tests in some #define for debug or development.

You might try comp.arch.embedded for this question. From what I''ve seen
over the years, this group pretty much assumes you''re using a compliant
compiler.

- Bill

On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás ó héilidhe
<to*@lavabit.comwrote:

>
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

On Sun, 20 Apr 2008 04:18:56 -0700 (PDT), Tomás ó héilidhe
<to*@lavabit.comwrote in comp.lang.c:

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

Right, or for any other unsigned type, (unsigned type)-1. Or if you
are assigning or initializing any unsigned integer type, just plain
old ordinary -1.

Also, I might rely on things such as:

memset(data,-1,sizeof data)

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

Really? I never have, can''t think of anybody who has. Do you really
do this? Why? I''ve never had a need for a block of memory with all
bits 1. Of course, if the array is of one of the unsigned integer
types, you''re safe unless these types contain padding, and I''ve never
heard of that it anything used for embedded wok.

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?

2) There''s no stack used by default; you must define a function as
"reentrant" if you want a stack.

This one is a true gotcha on some of the small, antique 8-bitters.
They have severe hardware limitations on the size of the stack. I
don''t (won''t) use PIC, the architecture is too bizarre without
sufficient reason, but 8051 derivatives have the same issue.

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:

Frankly, you are asking the wrong question. And even if it is the
right question, you should probably be asking it on comp.arch.embedded
rather than here.

"Trust" is not the right word. Most embedded compilers, especially
those which call themselves "ANSI C" compiler (which is all of them),
provide a subset of the C language and therefore aren''t really
conforming at all.

1) int being at least 16-Bit

ISTM one compiler, I think for much older PICs which had even more
limitations that had a 12-bit int.

2) long being at least 32-Bit

I also seem to remember one embedded compiler that had used something
less than 32 bits for long.

3) Compliant conversion between signed and unsigned types

I''m using the PIC C compiler to program the PIC16F684 chip.

As others have pointed out, just about every compiler comes with
documentation, either hard copy or electronic. The documentation will
tell you what the compiler does in these, and other cases.

But I still think "trust" is the wrong concept. C was designed (and
defined) as an efficient systems computing language for general
computing. Many of its features, and its efficiency, make it
extremely useful for embedded systems. But many embedded systems have
hardware architectures that make a full implementation of C either
completely impossible or incredibly impractical.

If you are using a new compiler for a new architecture, familiarize
yourself with its documentation, especially in areas of the language
that are "implementation-defined", and areas where it documents
limitations or omissions in conforming to the standard.

If anything is still questionable after reading and understanding the
documentation, contact the vendor''s tech support, if such exists. Or
even better, write and build code. See what it does by examining the
object code generated, or by testing the code.

The concept of "trust" for an embedded compiler, in the sense you use
it here, seems at odds with the kind of due diligence I would expect
an experienced embedded systems developer to do.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

这篇关于嵌入式系统编译器是否值得信任的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！