Forums

在未签名的字符上按位执行时,IAR中出现警告(已更正)

开始于 距离101 2012年4月3日
所以?

“而现在有了完全不同的东西。”

来自Monty Python。

-
保罗·柯蒂斯(Rowley Associates Ltd) http://www.rowley.co.uk
SolderCore正在运行Defender ... http://www.vimeo.com/25709426

> - - -原始信息 - - -
>发件人:m ... [mailto:m ...]代表
> Frances Fischer
>发送:2012年4月13日13:00
> To: m...
>主题:RE:[msp430] Re:执行按位不打开时,在IAR中发出警告
>未签名的字符(已更正)
>
>
>
> From TI:
>
>
>
>MSP430不提供所有操作码的列表,因为有很多操作码
>可用的寻址模式。但是,对于
>根据指令,组成各个操作码的各个位
>和寻址模式。
>
>《 MSP430xxxx系列用户指南》(例如:《 MSP430x1xx系列用户指南》
>,MSP430x2xx系列用户指南)显示了所有可用于
>“ RISC 16位CPU”一章中设置的指令。 `寻址
>模式部分介绍了“ As”和“ Ad”位。在“指令集”中
>部分,您将了解如何构建指令的十六进制表示
> from the
> bits:
>
> 1. opcode
>2.S-Reg(0b0000 = R0,0b0001 = R1 ... 0b1111 = R15)
>3.D-Reg(0b0000 = R0,0b0001 = R1 ... 0b1111 = R15)
> 4. Ad
> 5. As
>6.字节或字操作(黑白)
>
>“指令集描述”部分包含核心指令
> Map.
>
>
>“指令周期和长度”部分概述了时钟数
>说明使用的周期。所需的CPU时钟周期数
>一条指令取决于指令格式和寻址
>使用的模式-不是指令本身。时钟周期数是指
> to the MCLK.
>
>
>
>
>
>
>
>
>
>
>
>
>
>

MSP430入门微控制器

你好,

> >char是最小的可寻址单元;平原 char type, which is
> >有符号或无符号,与有符号字符和
> unsigned char.
> >通过实现,将普通字符类型选择为
> >签名或未签名以生成最佳代码(通常最快/最小)。
> >因此,肯定有一个签名的char类型和有效的
> >字符“ \ 377”很可能为-1。整理时很重要
> strings.
>
>我的观点是/ name /“ char”不适合数字-它是
>不合逻辑的,并且编写用于存储数字或对“字符”进行算术的代码
>没有道理。

typedef char a_small_integer_t; //解决疾病

>(大概)可以工作-但是编写的代码可以
>作品只是编写高质量软件的一半。 ķ&R could
>就像将这种类型称为“香蕉”一样-可以完成相同的工作,
>谈论“签名香蕉”与“签名香蕉”同样愚蠢
> char".

世界已经知道什么是签名字符。

>与Pascal(定义了“字符”)进行对比 to hold characters,
>和“ ShortInt”可容纳8位整数(Pascal在指定
>确切的大小,尽管您可以使用子范围类型进行改进)。

True Pascal从未使用过短整数类型:它仅具有整数
类型和子范围类型用于整数,而REAL用于浮点数。 Borland
用“有用的东西”扩展了Pascal,因此不应将其称为
帕斯卡尔(Pascal)和SHORTINT是他们发明的。肯·鲍尔斯和
USCD人群使用长整数和长整数单位做类似的事情。
不要误会我的意思,我喜欢Pascal,我喜欢Modula-2,并且喜欢Lisp,但是
语言设计是一门艺术,而不是一门科学。

>“字符”和“ ShortInt”都可以简化为8位 unit on most
>系统,或者在无法寻址字节的系统上使用更大的单元。但是
>名称各不相同,以表示不同的用法,并帮助人们写
>清晰,逻辑和正确的代码。

一个typedef会整理命名。

> > >类型选择适宜的为8位 算术值是>
> >“ uint8_t”或“ int8_t”-这些名称说明了您的意思,因此
> > code >您写得更清晰,更合逻辑。
> >
> >否。这些仅用于存储定义:uint_t完全存储在
> >n的二进制补码形式,没有任何填充。该类型名称
> > may not
>
>未签名的数据不是“二进制补码”,因为它是未签名的。对我来说
>知识,C标准实际上不需要带符号的二进制补码
> data.

用u滑动手指;但是,如果您有一个int8_t,而您
在二进制补码机上,这些类型需要二进制补码存储。
2011年标准的7.20.1.1节。可以存储其他普通类型
有符号的幅度。

[剪]

>是的,关于uint8_t和int8_t的所有算术都由 first promoting the
>类型为“ int”(或,如有必要,为unsigned int)。
>
>这并不会改变这样的事实:写“ uint8_t x=
>100;”,但写“ unsigned char x = 100;”(即使是偶数也没有意义)-
>尽管生成的代码是相同的。

char可以存储ASCII字符集的字符,int可以存储。那里
是C中没有“字符”数据类型,则所有内容都是整数或无符号或
更长。

> >char的所有变体必须满足最低要求 according to the
> >标准,可以依靠它出现。因此,char更
> >比uint8_t具有可移植性,并且根据其定义,可签名和未签名
> >可以使用char来存储[-127,127]之间的内容(是的,
> > that is
> >正确)或[0,255]。
>
>如上所述,char不可移植-原因之一是
>确切地说,它仅以最小范围定义。何时需要
>您可以使用这些范围的高度可移植的,具有适当名称的类型
>“ uint_least8_t”和“ int_least8_t”。

没有理智的软件工程师会使用这些类型。我的意思是
有时您在代码中遇到过这些吗?您看过多少次了
使用PRI宏?

而且开发人员不需要:今天任何有用的东西都可以在两者之间运行
具有ISO 60559浮点数的补码字节寻址机器-任何东西
否则可被认为与众不同并被降级。 C 2011已经足够
点点滴滴处理这种“非标准”架构。

-
保罗·柯蒂斯(Rowley Associates Ltd) http://www.rowley.co.uk
SolderCore正在运行Defender ... http://www.vimeo.com/25709426

保罗·柯蒂斯(Paul Curtis)在13/04/2012 14:36写道:
> Hi,
>
>>>char是最小的可寻址单元;普通字符类型,即
>>>有符号或无符号,与有符号字符和
>> unsigned char.
>>>通过实现,将普通字符类型选择为
>>>签名或未签名以生成最佳代码(通常最快/最小)。
>>>因此,肯定有一个签名的char类型和有效的
>>>字符“ \ 377”很可能为-1。整理时很重要
>> strings.
>>
>>我的观点是/ name /“ char”不适合数字-它是
>>不合逻辑的,并且编写用于存储数字或对“字符”进行算术的代码
>>没有道理。
>
>typedef char a_small_integer_t; //解决疾病

我/真的/希望没人写这样的代码!您是依靠“ char”
在特定平台上签名(或者,您依赖
它是未签名的-而“ a_small_integer_t”是未签名的)。

如果您认为自己曾经需要知道平台是否使用“签名”或
“ unsigned”代表普通的“ char”,那么您犯了一个大错误。

因此,确定需要指定“已签名”或“未签名”后,
而且我认为您正在尝试使这项工作变得尴尬
架构,我们现在有:

typedef int_least8_t a_small_integer_t; //欢迎来到20世纪!
>
>>(大概)可以工作-但是编写的代码可以
>>作品只是编写高质量软件的一半。 ķ&R could
>>就像将这种类型称为“香蕉”一样-可以完成相同的工作,
>>谈论“签名香蕉”与“签名香蕉”同样愚蠢
>> char".
>
>世界已经知道什么是签名字符。

不,还没有。大多数C程序员认为“签名字符”始终为8位,
二的补语,范围为[-128,127]。 “ int8_t”可能仍会离开
下限未指定为-128或-127,但仍然更好。

当然,在大多数情况下,“ signed char” / is / [-128,
127]。只是因为很多人习惯于用
更糟糕的方式,是继续这样做的借口。 (例外,
当然,这是在修改现有代码时-往往更多
与现有样式保持一致比使用更好的样式更重要
一。)
我有很多不同的MISRA规则,但他们都做到了
对-您不应该使用“ char”,“ int”,“ short”或“ long”之类的东西,
但使用更好的指定typedef。如果您/ do /使用“ char”,则您
必须使用“签名字符”或“未签名字符”。
记住,“明确胜于隐含”-写出您的意思/ mean /
当您编写代码时。

>
>>将其与Pascal(定义了一个用于容纳字符的“字符”)进行对比,
>>和“ ShortInt”可容纳8位整数(Pascal在指定
>>确切的大小,尽管您可以使用子范围类型进行改进)。
>
>True Pascal从未使用过短整数类型:它仅具有整数
>类型和子范围类型用于整数,而REAL用于浮点数。 Borland
>用“有用的东西”扩展了Pascal,这样就不应该 called
>帕斯卡尔(Pascal)和SHORTINT是他们发明的。肯·鲍尔斯(Ken Bowles)和 the
>USCD人群使用长整数和长整数单位做类似的事情。
>不要误会我的意思,我喜欢Pascal,我喜欢Modula-2,并且喜欢Lisp,但是
>语言设计是一门艺术,而不是一门科学。
>

您当然对Pascal的历史是正确的-但是
很难区分“纯Pascal”和“ Borland Pascal”,尤其是
因为“ Borland Pascal”是事实上的标准。

我完全同意语言设计是一门艺术-这取决于
在很大程度上取决于语言的预期用途。我是Python迷,而我
不要抱怨那里指定的数字少得多。但至少
数字类型称为“ int”和“ float”,而不是“ character”。

>>“字符”和“ ShortInt”都可以归结为 8-bit unit on most
>>系统,或者在无法寻址字节的系统上使用更大的单元。但是
>>名称各不相同,以表示不同的用法,并帮助人们写
>>清晰,逻辑和正确的代码。
>
>一个typedef会整理命名。

完全正确-因此在C编程中,使用适当的typedef名称
表示您的意思,而不是不合逻辑的“本机”类型名称。你可以
在中找到合适的typedef名称的不错选择。

>
>>> >8位算术值的适当类型选择是>
>>>“ uint8_t”或“ int8_t”-这些名称说明了您的意思,因此
>>> code> 您写得更清晰,更合逻辑。
>>>
>>>否。这些仅用于存储定义:uint_t完全存储在
>>>n的二进制补码形式,没有任何填充。该类型名称
>>> may not
>>
>>未签名的数据不是“二进制补码”,因为它是未签名的。对我来说
>>知识,C标准实际上不需要带符号的二进制补码
>> data.
>
>用u滑动手指;但是,如果您有一个int8_t,而您
>在二进制补码机上,这些类型需要二进制补码 storage.
>2011年标准的7.20.1.1节。可以存储其他普通类型
> signed-magnitude.

这是否意味着在两人称赞机上
需要将“ int16_t”存储为二进制补码,而
理论上,“ short int”(也可能是16位)
是否存储有符号幅度或其他表示形式?我不能
想象那会发生,但是知道是否会很有趣
法律允许。

>
> [ snip ]
>
>>是的,关于uint8_t和int8_t的所有算法都是通过首先提升
>>类型为“ int”(或,如有必要,为unsigned int)。
>>
>>这并不会改变这样的事实:写“ uint8_t x>> 100;" 但是写“ unsigned char x = 100;”是没有意义的。 - 甚至
>>尽管生成的代码是相同的。
>
>char可以存储ASCII字符集的字符,int可以存储。 There
>是C中没有“字符”数据类型,则所有内容都是整数或无符号或
> longer.
>
>>>char的所有变体必须满足以下最低要求
>>>标准,可以依靠它出现。因此,char更
>>>比uint8_t具有可移植性,并且根据其定义,可签名和未签名
>>>可以使用char来存储[-127,127]之间的内容(是的,
>>> that is
>>>正确)或[0,255]。
>>
>>如上所述,char不可移植-原因之一是
>>确切地说,它仅以最小范围定义。何时需要
>>您可以使用这些范围的高度可移植的,具有适当名称的类型
>>“ uint_least8_t”和“ int_least8_t”。
>
>没有理智的软件工程师会使用这些类型。我的意思是
>有时您在代码中遇到过这些吗?您看过多少次了
>使用PRI宏?
>

我自己没有使用过这些类型-但是,我设法避免了
使用无法寻址字节的目标,除了很久以前的一个项目。
每当有人提出“ TMS320 DSP不是一个好的选择
在这里”,我确保他们知道/确切/他们可以在哪里放置怪物。

大多数代码不必特别可移植,也没有
以不必要的可移植性为名牺牲可读性。

另一方面,我/ have /在少数情况下使用了int_fast8_t和uint_fast8_t
在AVR和msp430之间可移植代码的场合,以及
对于快速代码的需要,这带来了不便。

>开发人员不需要:有任何用途 今天跑两
>具有ISO 60559浮点数的补码字节寻址机器-任何东西
>否则可被认为与众不同并被降级。 C 2011有 enough
>点点滴滴处理这种“非标准”架构。
>

同意
爱的另一个原因

***.B or ***.W

像往常一样搅拌。



在13/04/2012 10:33 PM,David Brown写道:
>保罗·柯蒂斯(Paul Curtis)在13/04/2012 14:36写道:
>> Hi,
>>
>>>>char是最小的可寻址单元;普通字符类型,即
>>>>有符号或无符号,与有符号字符和
>>> unsigned char.
>>>>通过实现,将普通字符类型选择为
>>>>签名或未签名以生成最佳代码(通常最快/最小)。
>>>>因此,肯定有一个签名的char类型和有效的
>>>>字符“ \ 377”很可能为-1。整理时很重要
>>> strings.
>>>
>>>我的观点是/ name /“ char”不适合数字-它是
>>>不合逻辑的,并且编写用于存储数字或对“字符”进行算术的代码
>>>没有道理。
>>typedef char a_small_integer_t; //解决疾病
>我/真的/希望没人写这样的代码!您是依靠“ char”
>在特定平台上签名(或者,您依赖
>它是未签名的-而“ a_small_integer_t”是未签名的)。
>
>如果您认为自己曾经需要知道平台是否使用“签名”或
>“ unsigned”代表普通的“ char”,那么您犯了一个大错误。
>
>因此,确定需要指定“已签名”或“未签名”后,
>而且我认为您正在尝试使这项工作变得尴尬
>架构,我们现在有:
>
>typedef int_least8_t a_small_integer_t; //欢迎来到20世纪!
>>>(大概)可以工作-但是编写的代码可以
>>>作品只是编写高质量软件的一半。 ķ&R could
>>>就像将这种类型称为“香蕉”一样-可以完成相同的工作,
>>>谈论“签名香蕉”与“签名香蕉”同样愚蠢
>>> char".
>>世界已经知道什么是签名字符。
>不,还没有。大多数C程序员认为“签名字符”始终为8位,
>二的补语,范围为[-128,127]。 “ int8_t”可能仍会离开
>下限未指定为-128或-127,但仍然更好。
>
>当然,在大多数情况下,“ signed char” / is / [-128,
>127]。只是因为很多人习惯于用
>更糟糕的方式,是继续这样做的借口。 (例外,
>当然,这是在修改现有代码时-往往更多
>与现有样式保持一致比使用更好的样式更重要
> one.)
>我有很多不同的MISRA规则,但他们都做到了
>对-您不应该使用“ char”,“ int”,“ short”或“ long”之类的东西,
>但使用更好的指定typedef。如果您/ do /使用“ char”,则您
>必须使用“签名字符”或“未签名字符”。
>记住,“明确胜于隐含” –写您的/意思/
>当您编写代码时。
>
>>>将其与Pascal(定义了一个用于容纳字符的“字符”)进行对比,
>>>和“ ShortInt”可容纳8位整数(Pascal在 specifying
>>>确切的大小,尽管您可以使用子范围类型进行改进)。
>>True Pascal从未使用过短整数类型:它仅具有整数
>>类型和子范围类型用于整数,而REAL用于浮点数。 Borland
>>用“有用的东西”扩展了Pascal,这样就不应该 called
>>帕斯卡尔(Pascal)和SHORTINT是他们发明的。肯·鲍尔斯(Ken Bowles)和 the
>>USCD人群使用长整数和长整数单位做类似的事情。
>>不要误会我的意思,我喜欢Pascal,我喜欢Modula-2,并且喜欢Lisp,但是
>>语言设计是一门艺术,而不是一门科学。
>>
>您当然对Pascal的历史是正确的-但是
>很难区分“纯Pascal”和“ Borland Pascal”,尤其是
>因为“ Borland Pascal”是事实上的标准。
>
>我完全同意语言设计是一门艺术-这取决于
>在很大程度上取决于语言的预期用途。我是Python迷,而我
>不要抱怨那里指定的数字少得多。但至少
>数字类型称为“ int”和“ float”,而不是“ character”。
>
>>>大多数情况下,“字符”和“ ShortInt”都归结为8位单元
>>>系统,或者在无法寻址字节的系统上使用更大的单元。但是
>>>名称各不相同,以表示不同的用法,并帮助人们写
>>>清晰,逻辑和正确的代码。
>>一个typedef会整理命名。
>完全正确-因此在C编程中,使用适当的typedef名称
>表示您的意思,而不是不合逻辑的“本机”类型名称。你可以
>在其中找到适当的typedef名称的一个很好的选择。
>
>>>> >8位算术值的适当类型选择是>
>>>>“ uint8_t”或“ int8_t”-这些名称说明了您的意思,因此
>>>> code>您写得更清晰,更合逻辑。
>>>>
>>>>否。这些仅用于存储定义:uint_t完全存储在
>>>>n的二进制补码形式,没有任何填充。该类型名称
>>>> may not
>>>未签名的数据不是“二进制补码”,因为它是未签名的。对我来说
>>>知识,C标准实际上不需要带符号的二进制补码
>>> data.
>>用u滑动手指;但是,如果您有一个int8_t,而您
>>在二进制补码机上,这些类型需要二进制补码 storage.
>>2011年标准的7.20.1.1节。可以存储其他普通类型
>> signed-magnitude.
>这是否意味着在两人称赞机上
>需要将“ int16_t”存储为二进制补码,而
>理论上,“ short int”(也可能是16位)
>是否存储有符号幅度或其他表示形式?我不能
>想象那会发生,但是知道是否会很有趣
>法律允许。
>
>> [ snip ]
>>
>>>是的,关于uint8_t和int8_t的所有算法都是通过首先提升
>>>类型为“ int”(或,如有必要,为unsigned int)。
>>>
>>>这并不会改变这样的事实:写“ uint8_t x>>> 100;”,但写“ unsigned char x = 100;”(即使是偶数也没有意义)-
>>>尽管生成的代码是相同的。
>>char可以存储ASCII字符集的字符,int可以存储。 There
>>是C中没有“字符”数据类型,则所有内容都是整数或无符号或
>> longer.
>>
>>>>char的所有变体必须满足以下最低要求
>>>>标准,可以依靠它出现。因此,char更
>>>>比uint8_t具有可移植性,并且根据其定义,可签名和未签名
>>>>可以使用char来存储[-127,127]之间的内容(是的,
>>>> that is
>>>>正确)或[0,255]。
>>>如上所述,char不可移植-原因之一是
>>>确切地说,它仅以最小范围定义。何时需要
>>>您可以使用这些范围的高度可移植的,具有适当名称的类型
>>>“ uint_least8_t”和“ int_least8_t”。
>>没有理智的软件工程师会使用这些类型。我的意思是
>>有时您在代码中遇到过这些吗?你看过几次了 the
>>使用PRI宏?
>>
>我自己没有使用过这些类型-但是,我设法避免了
>使用无法寻址字节的目标,除了很久以前的一个项目。
>每当有人提出“ TMS320 DSP不是一个好的选择
>在这里”,我确保他们知道/确切/他们可以在哪里放置怪物。
>
>大多数代码不必特别可移植,也没有
>以不必要的可移植性为名牺牲可读性。
>
>另一方面,我/ have /在少数情况下使用了int_fast8_t和uint_fast8_t
>在AVR和msp430之间可移植代码的场合,以及
>对于快速代码的需要,这带来了不便。
>
>>而且开发人员不需要:今天任何有用的东西都可以在两者之间运行
>>具有浮点ISO 60559的补码字节寻址机器 point--anything
>>否则可被认为与众不同并被降级。 C 2011有 enough
>>点点滴滴处理这种“非标准”架构。
>>
> Agreed.
>
让您掌控一切。不会浪费时间与您的工具作斗争。

很高兴见到你回来艾尔!

布莱克利

--在...中,Onestone写道:
>
>爱的另一个原因
>
>***。B或***。W
>
>像往常一样搅拌。
>
> Al
>
>在13/04/2012 10:33 PM,David Brown写道:
> >保罗·柯蒂斯(Paul Curtis)在13/04/2012 14:36写道:
> >> Hi,
> >>
> >>>>char是最小的可寻址单元;普通字符类型,即
> >>>>有符号或无符号,与有符号字符和
> >>> unsigned char.
> >>>>通过实现,将普通字符类型选择为
> >>>>签名或未签名以生成最佳代码(通常最快/最小)。
> >>>>因此,肯定有一个签名的char类型和有效的
> >>>>字符“ \ 377”很可能为-1。整理时很重要
> >>> strings.
> >>>
> >>>我的观点是/ name /“ char”不适合数字-它是
> >>>不合逻辑的,并编写用于存储数字或对算术进行算术的代码 "char"
> >>>没有道理。
> >>typedef char a_small_integer_t; //解决疾病
> >我/真的/希望没人写这样的代码!您是依靠“ char”
> >在特定平台上签名(或者,您依赖
> >它是未签名的-而“ a_small_integer_t”是未签名的)。
> >
> >如果您认为自己曾经需要知道平台是否使用“签名”或
> >“ unsigned”代表普通的“ char”,那么您犯了一个大错误。
> >
> >因此,确定需要指定“已签名”或“未签名”后,
> >而且我认为您正在尝试使这项工作变得尴尬
> >架构,我们现在有:
> >
> >typedef int_least8_t a_small_integer_t; //欢迎来到20世纪!
> >
> >
> >>>(大概)可以工作-但是编写的代码可以
> >>>作品只是编写高质量软件的一半。 ķ&R could
> >>>就像将这种类型称为“香蕉”一样-它会做同样的事情 job,
> >>>谈论“签名香蕉”与“签名香蕉”同样愚蠢
> >>> char".
> >>世界已经知道什么是签名字符。
> >不,还没有。大多数C程序员认为“签名字符”始终为8位,
> >二的补语,范围为[-128,127]。 “ int8_t”可能仍会离开
> >下限未指定为-128或-127,但仍然更好。
> >
> >当然,在大多数情况下,“ signed char” / is / [-128,
> >127]。只是因为很多人习惯于用
> >更糟糕的方式,是继续这样做的借口。 (例外,
> >当然,这是在修改现有代码时-往往更多
> >与现有样式保持一致比使用更好的样式更重要
> > one.)
> >
> >
> >我有很多不同的MISRA规则,但他们都做到了
> >对-您不应该使用“ char”,“ int”,“ short”或“ long”之类的东西,
> >但使用更好的指定typedef。如果您/ do /使用“ char”,则您
> >必须使用“签名字符”或“未签名字符”。
> >
> >
> >记住,“明确胜于隐含” –写您的/意思/
> >当您编写代码时。
> >
> >>>将其与Pascal进行对比,后者定义了要保留的“字符” characters,
> >>>和“ ShortInt”可容纳8位整数(Pascal在 specifying
> >>>确切的大小,尽管您可以使用子范围类型进行改进)。
> >>True Pascal从未拥有过短整数类型:它仅具有 integer
> >>类型和子范围类型用于整数,而REAL用于浮点数。 Borland
> >>用“有用的东西”扩展了Pascal,这样就不应该 called
> >>帕斯卡尔(Pascal)和SHORTINT是他们发明的。肯·鲍尔斯(Ken Bowles)和 the
> >>USCD人群使用长整数和长整数做了类似的事情 unit.
> >>不要误会我的意思,我喜欢Pascal,我喜欢Modula-2,并且喜欢Lisp, but
> >>语言设计是一门艺术,而不是一门科学。
> >>
> >您当然对Pascal的历史是正确的-但是
> >很难区分“纯Pascal”和“ Borland Pascal”,尤其是
> >因为“ Borland Pascal”是事实上的标准。
> >
> >我完全同意语言设计是一门艺术-这取决于
> >在很大程度上取决于语言的预期用途。我是Python迷,而我
> >不要抱怨那里指定的数字少得多。但至少
> >数字类型称为“ int”和“ float”,而不是“ character”。
> >
> >>>大多数情况下,“字符”和“ ShortInt”都归结为8位单元
> >>>系统,或者在无法寻址字节的系统上使用更大的单元。但是
> >>>名称各不相同,以表示不同的用法,并帮助人们写
> >>>清晰,逻辑和正确的代码。
> >>一个typedef会整理命名。
> >完全正确-因此在C编程中,使用适当的typedef名称
> >表示您的意思,而不是不合逻辑的“本机”类型名称。你可以
> >在其中找到适当的typedef名称的一个很好的选择。
> >
> >>>> >8位算术值的适当类型选择是>
> >>>>“ uint8_t”或“ int8_t”-这些名称说明了您的意思,因此
> >>>> code>您写得更清晰,更合逻辑。
> >>>>
> >>>>否。这些仅用于存储定义:uint_t完全存储在
> >>>>n的二进制补码形式,没有任何填充。该类型名称
> >>>> may not
> >>>未签名的数据不是“二进制补码”,因为它是未签名的。对我来说
> >>>知识,C标准实际上并不需要二进制补码 signed
> >>> data.
> >>用u滑动手指;但是,如果您有int8_t,并且您 are
> >>在二进制补码机上,这些类型需要二进制补码 storage.
> >>2011年标准的7.20.1.1节。可以存储其他普通类型
> >> signed-magnitude.
> >这是否意味着在两人称赞机上
> >需要将“ int16_t”存储为二进制补码,而
> >理论上,“ short int”(也可能是16位)
> >是否存储有符号幅度或其他表示形式?我不能
> >想象那会发生,但是知道是否会很有趣
> >法律允许。
> >
> >> [ snip ]
> >>
> >>>是的,关于uint8_t和int8_t的所有算术都是通过先提升来完成的 the
> >>>类型为“ int”(或,如有必要,为unsigned int)。
> >>>
> >>>这并不会改变这样的事实:写“ uint8_t x> >>> 100;”,但写“ unsigned char x = 100;”(即使是偶数也没有意义)-
> >>>尽管生成的代码是相同的。
> >>char可以存储ASCII字符集的字符,int可以存储。 There
> >>是C中没有“字符”数据类型,则所有内容都是整数或无符号 or
> >> longer.
> >>
> >>>>char的所有变体必须满足以下最低要求
> >>>>标准,可以依靠它出现。因此,char更
> >>>>比uint8_t具有可移植性,并且根据其定义,可签名和未签名
> >>>>可以使用char来存储[-127,127]之间的内容(是的,
> >>>> that is
> >>>>正确)或[0,255]。
> >>>如上所述,char不可移植-原因之一是
> >>>确切地说,它仅以最小范围定义。何时需要
> >>>您可以使用这些范围的高度可移植的,具有适当名称的类型
> >>>“ uint_least8_t”和“ int_least8_t”。
> >>没有理智的软件工程师会使用这些类型。我的意思是
> >>有时您在代码中遇到过这些吗?你看过几次了 the
> >>使用PRI宏?
> >>
> >我自己没有使用过这些类型-但是,我设法避免了
> >使用无法寻址字节的目标,除了很久以前的一个项目。
> >每当有人提出“ TMS320 DSP不是一个好的选择
> >在这里”,我确保他们知道/ exactly /在哪里可以放置 monstrosity.
> >
> >大多数代码不必特别可移植,也没有
> >以不必要的可移植性为名牺牲可读性。
> >
> >另一方面,我/ have /在少数情况下使用了int_fast8_t和uint_fast8_t
> >在AVR和msp430之间可移植代码的场合,以及
> >对于快速代码的需要,这带来了不便。
> >
> >>而且开发人员不需要:今天任何有用的东西都可以在两者之间运行
> >>具有浮点ISO 60559的补码字节寻址机器 point--anything
> >>否则可被认为与众不同并被降级。 C 2011有 enough
> >>点点滴滴处理这种“非标准”架构。
> >>
> > Agreed.
> >
> >
> >
> >
> >
> >
> >
> >typedef char a_small_integer_t; //解决疾病
>
>我/真的/希望没人写这样的代码!您是依靠“ char”
>在特定平台上签名(或者,您依赖
>它是未签名的-而“ a_small_integer_t”是未签名的)。

我故意说“小整数”,我没有说“小整数”
或“一个小的无符号整数”;它只是产生的“小整数”
特定架构的“最佳代码”。

>如果您认为自己需要知道平台是否 uses "签" or
>“ unsigned”代表普通的“ char”,那么您犯了一个大错误。
我同意这一点。我会说你需要保重 observe
当可以对纯字符进行签名或不签名时请多加注意。这咬人时
他们没想到:

int lut [256]] = {...};

无效foo(char * p)
{
int x = lut[*p++];
}

如果对普通字符进行了签名,则此简单表述很容易失败
当使用通用语言环境(例如HU.hu)时,如果输入来自
具有特定于语言环境的扩展字符的字符串。当整理
字符串,带符号的纯字符可能会给您带来意想不到的结果,除非您
使用C库排序规则功能。

>我想您正在尝试使这项工作即使在 笨拙的架构,
> we now have:
>
>typedef int_least8_t a_small_integer_t; //欢迎来到20日
世纪!

哇。我在21世纪,就在您的前面。 :-)

>我有很多不同的MISRA规则,但是 they got this one
>对-您不应该使用“ char”,“ int”,“ short”或“ long”之类的东西,
>但使用更好的指定typedef。如果您/ do /使用“ char”,则必须
>使用“签名字符”或“未签名字符”。

C语言中存在更糟糕的事情。最糟糕的是,纯粹的优先级数
运营商级别。 Modula-2和Pascal拥有此权利,您只需要
记住乘法和加法以及关系运算符
优越。这对每个人都有用,因为它很容易映射到数学
条款和产品。

>当然,您对Pascal的历史是正确的 - but it's difficult
>区分“纯Pascal”和“ Borland Pascal”,尤其是“ Borland”
>Pascal”是事实上的标准。

ISO扩展Pascal是一项真正的标准;而Prospero在
实施它。 Pascal现在是一种死水语言。

> >用u滑动手指;但是,如果您有 an int8_t, and you
> are
> >在二进制补码机上,这些类型需要二进制补码
> storage.
> >2011年标准的7.20.1.1节。可以存储其他普通类型
> > signed-magnitude.
>
>这是否意味着在两人称赞机上
>需要将“ int16_t”存储为二进制补码,而
>理论上,“ short int”(也可能是16位)
>是否存储有符号幅度或其他表示形式?

好问题。

>我无法想象那会发生,但是会 知道很有趣
如果
>法律允许。

我将不得不解决这个问题;我无法想象许多有符号的幅度
除了十进制算术之外,今天使用的其他机器。即使是现在
涵盖最新的60559标准;这是我需要的更多乐趣
接受并理解。

> >没有理智的软件工程师会使用这些 类型;我的意思是
> >有时您在代码中遇到过这些吗?你看过几次了
> >PRI宏的使用?
>
>我自己没有使用过这些类型-但是,我设法避免了
>使用无法寻址字节的目标,除了很久以前的一个项目。
>每当有人提出“ TMS320 DSP不是一个好的选择
>在这里”,我确保他们知道/确切/他们可以在哪里放置怪物。

在TMS320C40上以C语言编写了用于雷达应用的低级DSP,
我必须说我不太喜欢这种架构。

>大多数代码不必特别可移植, and there is no
>以不必要的可移植性为名牺牲可读性。

的确。

-
保罗·柯蒂斯(Rowley Associates Ltd) http://www.rowley.co.uk
SolderCore正在运行Defender ... http://www.vimeo.com/25709426

保罗·柯蒂斯(Paul Curtis)在13/04/2012 15:53写道:
>>>typedef char a_small_integer_t; //解决疾病
>>
>>我/真的/希望没人写这样的代码!您是依靠“ char”
>>在特定平台上签名(或者,您依赖
>>它是未签名的-而“ a_small_integer_t”是未签名的)。
>
>我故意说“小整数”,我没有说“小号 integer"
>或“一个小的无符号整数”;它只是产生的“小整数”
>特定架构的“最佳代码”。
>
>>如果您认为自己曾经需要知道平台是否使用“签名”或
>>“ unsigned”代表普通的“ char”,那么您犯了一个大错误。
>我同意这一点。我会说你需要照顾和观察
>
>他们没想到:
>
>int lut [256]] = {...};
>
> void foo(char *p)
> {
>int x = lut [* p ++];
> }
>
>如果对普通字符进行了签名,则此简单语句很容易 fail
>当使用通用语言环境(例如HU.hu)时,如果输入来自
>具有特定于语言环境的扩展字符的字符串。当整理
>字符串,带符号的纯字符可能会给您带来意想不到的结果,除非您
>使用C库排序规则功能。
>

gcc将“ -Wchar-subscripts”作为警告是有充分理由的,并且
我怀疑许多其他编译器会警告此类问题。

>>我想您正在尝试使这项工作即使在 笨拙的架构,
>> we now have:
>>
>>typedef int_least8_t a_small_integer_t; //欢迎来到20日
> century!
>
>哇。我在21世纪,就在您的前面。 :-)

愚蠢的错别字分数是1-1 :-)

>
>>我有很多不同的MISRA规则,但他们都做到了
>>对-您不应该使用“ char”,“ int”,“ short”或“ long”之类的东西,
>>但使用更好的指定typedef。如果您/ do /使用“ char”,则必须
>>使用“签名字符”或“未签名字符”。
>
>C语言中存在更糟糕的事情。最糟糕的是,纯粹的优先级数
>运营商级别。 Modula-2和Pascal拥有此权利,您只需要
>记住乘法和加法以及关系运算符
>优越。这对每个人都有用,因为它很容易映射到数学
> terms and products.
>

我不是警告过您不要从这里开始吗?唯一明智的写作方式
C语言中的表达式要依靠基本数学和
如您所建议,关系运算符,其余部分使用方括号。

>>当然,您对Pascal的历史是正确的 - but it's difficult
>>区分“纯Pascal”和“ Borland Pascal”,尤其是“ Borland”
>>Pascal”是事实上的标准。
>
>ISO扩展Pascal是一项真正的标准; Prospero做得很好 of
>实施它。 Pascal现在是一种死水语言。
>

是的,但是“ ISO Pascal”的麻烦在于它的用法很小
与“ Borland Pascal”相比-我实际上不知道/ anyone /
实现了它。还有其他一些,例如嵌入式Pascal
编译器和Free Pascal,它们通常支持Borland的一些新增功能
和他们自己的一些。

>>>用u滑动手指;但是,如果您有 an int8_t, and you
>> are
>>>在二进制补码机上,这些类型需要二进制补码
>> storage.
>>>2011年标准的7.20.1.1节。可以存储其他普通类型
>>> signed-magnitude.
>>
>>这是否意味着在两人称赞机上
>>需要将“ int16_t”存储为二进制补码,而
>>理论上,“ short int”(也可能是16位)
>>是否存储有符号幅度或其他表示形式?
>
> Good question.
>
>>我无法想象会发生这种情况,但是知道这将很有趣
> if
>>法律允许。
>
>我将不得不解决这个问题;我无法想象许多有符号的幅度
>除了十进制算术之外,今天使用的其他机器。即使是现在
>涵盖最新的60559标准;这是我需要的更多乐趣
>接受并理解。
>
>>>没有理智的软件工程师会使用这些类型。我的意思是
>>>有时您在代码中遇到过这些吗?你看过几次了
>>>PRI宏的使用?
>>
>>我自己没有使用过这些类型-但是,我设法避免了
>>使用无法寻址字节的目标,除了很久以前的一个项目。
>>每当有人提出“ TMS320 DSP不是一个好的选择
>>在这里”,我确保他们知道/确切/他们可以在哪里放置怪物。
>
>在TMS320C40上用C语言编写了用于雷达的低级DSP application,
>我必须说我不太喜欢这种架构。
>

我会说得更厉害-但是,我不像你那样外交!

>>大多数代码不必特别可移植, and there is no
>>以不必要的可移植性为名牺牲可读性。
>
> Indeed.
>

mvh。,

大卫

保罗在2012年4月13日星期五10:10:40 +0100写道:

>使用带符号的符号时更为普遍 不是的字符类型
>MSP430本机支持:
>
>/ * 8位闪烁的AVR程序员始终认为“越小越好”
>efficient". */
>
>signed char n;
>void bar(int x);
>
>void foo(void)
>{
> signed char x;
> for (x = 1; x < n+2; ++x)
> bar(x);
>}
>
> MOV.B #1, R11
> JMP @48
>@49
> MOV.B R11, R15
> SXT R15
> CALL #_bar
> ADD.B #1, R11
>@48
> MOV.B &_n, R15
> SXT R15
> ADD.W #2, R15
> MOV.B R11, R14
> SXT R14
> CMP.W R15, R14
> JL @49
>
>在这里,我们看到了相反的情况:x移到R15之后,我们需要对扩展R15进行签名;
>这是因为.B操作将寄存器的高阶部分清零,
>他们不签署扩展它。和两个签名的外观比较
>混合+1的字符?是的,看起来不错,不是吗?
>



保罗,只是一个补充问题。如果循环体没有
包括一个可以修改n的函数调用,但是
而是一段显然没有的C语句
修改n,然后将'n + 2'计算结果提升到外部
循环? (n不是易变的,n + 2应该不变
在循环执行期间。)在我看来,答案是肯定的,
它将把不变的子表达式提升到循环之外。
但是无论如何,我很好奇,只是以为我会问。

而且,这是关于C标准的怪异回忆
(记不清C89或C99还是两者-您是否提出了
2011年标准??),但我似乎还记得
正在讨论中的比较,x< n+2, the
允许编译器避免显式的“整数提升”
在生成的代码中,如果编译器可以确定
实际发出的代码“好像”已经发生促销。
(尽管您在上面显示的情况可能不允许这样做
在不知道n on值的情况下完全可确定
入门,我可以轻松地将应该计算的小马
由编译器在没有升级的情况下像“好像”一样工作
必须发生。所以问题仍然存在。)
回忆起来可能错了,我也很好奇
关于你在那里的想法。

乔恩
2012年4月24日,乔恩·基万(Jon Kirwan)在22:17写道:

>保罗在2012年4月13日星期五10:10:40 +0100写道:
>
>>
>>
>>当使用不带符号的字符类型时,这种情况更为普遍
>>MSP430本机支持:
>>
>>/ * 8位闪烁的AVR程序员始终认为“越小越好”
>> efficient". */
>>
>> signed char n;
>> void bar(int x);
>>
>> void foo(void)
>> {
>> signed char x;
>> for (x = 1; x < n+2; ++x)
>> bar(x);
>> }
>>
>> MOV.B #1, R11
>> JMP @48
>> @49
>> MOV.B R11, R15
>> SXT R15
>> CALL #_bar
>> ADD.B #1, R11
>> @48
>> MOV.B &_n, R15
>> SXT R15
>> ADD.W #2, R15
>> MOV.B R11, R14
>> SXT R14
>> CMP.W R15, R14
>> JL @49
>>
>>在这里,我们看到了相反的情况:x移到 it;
>>这是因为.B操作会将的高阶部分归零 register,
>>他们不签署扩展它。和两个的简单比较 signed
>>混合+1的字符?是的,看起来不错,不是吗?
>>保罗,只是一个补充问题。如果循环体 didn't
>包括一个可以修改n的函数调用,但是
>而是一段显然没有的C语句
>修改n,然后将'n + 2'计算结果提升到外部
> the loop?

它可能是。无论是不是我无法回答的另一个问题, in general.

>(n不是易变的,n + 2应该不变
>在循环执行期间。)在我看来,答案是肯定的,
>它将把不变的子表达式提升到循环之外。
>但是无论如何,我很好奇,只是以为我会问。
>
>而且,这是关于C标准的怪异回忆
>(记不清C89或C99还是两者-您是否提出了
>2011年标准??),但我似乎还记得
>正在讨论中的比较,x< n+2, the
>允许编译器避免显式的“整数提升”
>在生成的代码中,如果编译器可以确定
>实际发出的代码“好像”已经发生促销。

那是正确的。执行必须匹配抽象语义;编译器 只要重新安装程序的副作用,它就可以做所有想要重新排列的程序 程序根据抽象机状态进行维护。

在编译器中,通常会在 中间表示。然后,优化程序可以缩小转化范围甚至 在优化的某些阶段放弃转化-通常会有更多 而不是在编译器中可以检测到并丢弃这些东西的地方, 通常是在最容易检测和修改的地方做出务实的决定 "an" IR.

>(尽管您上面显示的情况可能不允许 this to be
>在不知道n on值的情况下完全可确定
>入门,我可以轻松地将应该计算的小马
>由编译器在没有升级的情况下像“好像”一样工作
>必须发生。所以问题仍然存在。)
>回忆起来可能错了,我也很好奇
>关于你在那里的想法。

所有ISO标准都是使用抽象机指定的,因此 适用于C89 / 90,C99和C11。

保罗

保罗在2012年4月24日星期二23:13:30 +0100写道:

>2012年4月24日,乔恩·基万(Jon Kirwan)在22:17写道:
>
>>保罗在2012年4月13日星期五10:10:40 +0100写道:
>>
>>>
>>>
>>>当使用不带符号的字符类型时,这种情况更为普遍
>>>MSP430本机支持:
>>>
>>>/ * 8位闪烁的AVR程序员始终认为“越小越好”
>>> efficient". */
>>>
>>> signed char n;
>>> void bar(int x);
>>>
>>> void foo(void)
>>> {
>>> signed char x;
>>> for (x = 1; x < n+2; ++x)
>>> bar(x);
>>> }
>>>
>>> MOV.B #1, R11
>>> JMP @48
>>> @49
>>> MOV.B R11, R15
>>> SXT R15
>>> CALL #_bar
>>> ADD.B #1, R11
>>> @48
>>> MOV.B &_n, R15
>>> SXT R15
>>> ADD.W #2, R15
>>> MOV.B R11, R14
>>> SXT R14
>>> CMP.W R15, R14
>>> JL @49
>>>
>>>在这里,我们看到了相反的情况:x移到 it;
>>>这是因为.B操作会将的高阶部分归零 register,
>>>他们不签署扩展它。和两个的简单比较 signed
>>>混合+1的字符?是的,看起来不错,不是吗?
>>>
>>
>>
>>
>>保罗,只是一个补充问题。如果循环体没有
>>包括一个可以修改n的函数调用,但是
>>而是一段显然没有的C语句
>>修改n,然后将'n + 2'计算结果提升到外部
>> the loop?
>
>它可能是。是否是一个不同的问题
>通常我无法回答。

我当时特别在问这个问题。我的意思是
我看到的用于反汇编的编译器的情况
以上。不一般。这个答案我想我已经知道了。

>>(n不是易变的,n + 2应该不变
>>在循环执行期间。)在我看来,答案是肯定的,
>>它将把不变的子表达式提升到循环之外。
>>但是无论如何,我很好奇,只是以为我会问。
>>
>>而且,这是关于C标准的怪异回忆
>>(记不清C89或C99还是两者-您是否提出了
>>2011年标准??),但我似乎还记得
>>正在讨论中的比较,x< n+2, the
>>允许编译器避免显式的“整数提升”
>>在生成的代码中,如果编译器可以确定
>>实际发出的代码“好像”已经发生促销。
>
>那是正确的。执行必须与摘要匹配
>语义编译器可以做所有想要重新排列的
>程序,只要程序的副作用是
>根据抽象机状态进行维护。

正确的。

>在编译器中,通常使整数 conversions
>在中间表示中是显式的。

啊哈!这是一个具体的花絮。所以如果我
正确理解这一点,进行整数提升
在解析和语法分析过程中以及其他之前。
因此,原始程序员的“提示”实际上是输给了
编译器,如果有理由这样做是不可恢复的
所以。

> The optimiser
>然后可以缩小转换范围甚至放弃转换
>在优化的某些阶段-通常会有更多
>而不是编译器中可以放置此类内容的位置
>检测并丢弃,通常是实用的
>决定哪里最容易检测和修改“ IR”。

您能想到“缩小转换”逻辑的情况吗
_FAIL_会进行缩小的转换,但缺少
原始程序员的显式语法声明了类型,但是
可能有可能做更多的事
缩小转换时存在的信息
逻辑运作?还是有1:1的情况,所有这些
在规则可能缩小范围的情况下,
丢失显式语法绝对没有可能的影响
在缩小期间可用的选项?

现在我给自己一个难题要考虑。也许你已经
有一个答案。但是我会考虑一下
提出更精确的问题也很有趣。

>>(尽管您上面显示的情况可能不允许 this to be
>>在不知道n on值的情况下完全可确定
>>入门,我可以轻松地将应该计算的小马
>>由编译器在没有升级的情况下像“好像”一样工作
>>必须发生。所以问题仍然存在。)
>>回忆起来可能错了,我也很好奇
>>关于你在那里的想法。
>
>所有ISO标准都是使用抽象机指定的,
>因此它同样适用于C89 / 90,C99和C11。

我总是对自己的失败感到怀疑,并留有余地
那。

谢谢,
乔恩