嵌入式系统需要改进的C版本。

对此投诉的明显反驳是仅使用 汇编语言进行编程，但是 客户通常需要使用C / C ++。 /> 征求意见。 谢谢， Bill Hanna 解决方案 Bill Hanna< bi ***** @ aol.com>在留言中写道 news：97 ************************** @ posting.google.c om ... 由于以下原因，C不适用于嵌入式系统：1）简单地支持并且不容易直接寻址存储器映射的I / O.您必须找到与编译器相关的变通方法。您必须创建宏，使用强制转换并使用间接寻址（指针）来读取或写入内存映射的I / O. 2）C不支持实时中断。中断引导是依赖于编译器的。 3）C不提供固定点32X32的全部结果。它只提供LH结果。数字滤波器应用需要UH结果。 4）C不提供溢出检测或执行检测。 对此投诉的明显反驳是只能用汇编语言编程，但客户通常要求使用C / C ++。 征求意见。 我的评论： 您似乎觉得C不足以满足您的需求。 所以使用（或创建）足够。 在这里，我们讨论C原样。 -Mike 2003年7月4日22:36:08 -0700， bi ***** @ aol.com （Bill Hanna）在 comp.lang.c中写道： 由于以下原因，C不适用于嵌入式系统： 这很有趣，我已经在嵌入式系统中使用C超过20年b ，我觉得它很高hly足够。 除此之外，谁曾说C应该足够用于嵌入式系统？ 最后，什么更好？ 1）不简单地支持内存映射I / O的直接寻址。您必须找到与编译器相关的解决方法。您必须创建宏，使用强制转换并使用间接寻址（指针）来读取或写入内存映射的I / O. 上述任何一项都有什么问题？如果您的编译器没有为它识别并提供 指针的宏提供 a格式，请与编译器供应商联系或购买更好的 编译器。语法很直接。 那么比内存映射I / O更奇怪的事情，比如特殊的 寄存器，单独的I / O空间一些英特尔（和其他一些） 架构，内存映射寄存器和其他一些东西？ 那么什么？ 2 ）C不支持实时中断。中断矢量化取决于编译器。 中断向量与硬件有关，取决于 处理器和其他一些东西。 3）C不提供32X32固定点的全部结果。它只提供LH结果。数字滤波器应用需要UH结果。 C根本不支持定点数据。它原生支持整数和 浮点类型。供应商支持定点 提供的库。 4）C不提供溢出检测或执行检测。 对，这是故意的。 C的基本设计目标之一就是你不需要付出你不需要的东西。在需要这些功能的情况下，请添加它们。当不需要时，不要试图给每个程序加重每个程序的负担 。 对这个投诉的明显反驳是只在汇编语言，但客户通常要求使用C / C ++。 征求意见。谢谢， Bill Hanna C适用于嵌入式系统，因为客户需要它。并且 也是因为在超过四分之一世纪的时间里，有大量强大的嵌入式系统已经用它构建了它们。 虽然所有这些都是偏离主题的，但我还有两个额外的评论： 1.停止抱怨。如果您的客户要求使用C， 无论是投诉还是寻找另一行 工作。 2.您的大多数投诉与正确的语言无关。 C $ / b $ b根本不支持任何硬件，不支持键盘，视频显示， 磁盘驱动器，串行终端，什么都不支持。它也不支持 中断。因此，它不支持ADC或PWM 或DAC是无关紧要的。缺乏对第一个硬件列表的支持 我提到并没有阻止C被用于几乎所有主要的操作系统。缺乏对中断的标准化支持（以及这可能是一场噩梦）并没有阻止中断例程 被写入（非标准，扩展）C操作系统 和桌面应用程序。 您的问题似乎与语言不同，但是 你的编译厂商。显然他们没有做得那么好 为你的特定平台提供可用的扩展。 - Jack Klein 主页： http://JK-Technology.Com 常见问题解答 comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c ++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c ++ ftp://snurse-l.org/pub/acllc-c++/faq ＃征求意见。 通常的技巧是找到你喜欢的基本语言，可能是C / / 或Bliss或Ada或PL / I或Algol或Fortran，然后根据你的具体情况进行调整 需要。你想要的一些东西根本不存在于这个或那个cpu 这些年来我一直在努力。要求所有这些都被标准化。 变成类似C的东西会创建一种无法用于某些系统的语言。 如果客户要求用不可能支持它的语言来完成任务，你应该在接受这些问题之前协商这些问题 作为客户。 - Derk Gwen http://derkgwen.250free.com/html/index.html 你在这里经营什么样的便利店？ C is inadequate for embedded systems for the following reasons:1) Direct addressing of memory mapped I/O is not supported simplyand easily. You have to find work-arounds that are compiler dependent.You have to create macros , use casting and use indirect addressing(pointers) to read or write to memory mapped I/O.2) C does not support real time interrupts. The interruptvectoring is compiler dependent.3) C does not provide the full result of a fixed point 32X32multiply. It only provides the LH result. The UH result is needed fordigital filter applications.4) C does not provide overflow detection or carry out detection.The obvious rebuttal to this complaint is to program only inassembler language, however use of C/C++ is usually demanded by thecustomer.Comments are solicted.Thanks,Bill Hanna 解决方案Bill Hanna <bi*****@aol.com> wrote in messagenews:97**************************@posting.google.c om... C is inadequate for embedded systems for the following reasons: 1) Direct addressing of memory mapped I/O is not supported simply and easily. You have to find work-arounds that are compiler dependent. You have to create macros , use casting and use indirect addressing (pointers) to read or write to memory mapped I/O. 2) C does not support real time interrupts. The interrupt vectoring is compiler dependent. 3) C does not provide the full result of a fixed point 32X32 multiply. It only provides the LH result. The UH result is needed for digital filter applications. 4) C does not provide overflow detection or carry out detection. The obvious rebuttal to this complaint is to program only in assembler language, however use of C/C++ is usually demanded by the customer. Comments are solicted.My comment:You seem to feel that C is insufficient to your needs.So use (or create) something that is sufficient.Here, we discuss C as it is.-Mike On 4 Jul 2003 22:36:08 -0700, bi*****@aol.com (Bill Hanna) wrote incomp.lang.c: C is inadequate for embedded systems for the following reasons:That''s funny, I''ve been using C for embedded systems for more than 20years, and I find it highly adequate.Besides which, who ever said that C was supposed to be adequate forembedded systems?Finally, what''s better? 1) Direct addressing of memory mapped I/O is not supported simply and easily. You have to find work-arounds that are compiler dependent. You have to create macros , use casting and use indirect addressing (pointers) to read or write to memory mapped I/O.What''s wrong with any of the above? If your compiler does not providea format for macros that it recognizes and optimizes away thepointers, take it up with the compiler vendor or buy a bettercompiler. The syntax works quite directly.And what about things stranger than memory-mapped I/O, such as specialregisters, the separate I/O space of some Intel (and some other)architectures, memory-mapped registers, and quite a few other things?So what? 2) C does not support real time interrupts. The interrupt vectoring is compiler dependent.The interrupt vectoring is hardware dependent, depending on theprocessor and quite a few other things. 3) C does not provide the full result of a fixed point 32X32 multiply. It only provides the LH result. The UH result is needed for digital filter applications.C does not support fixed point data at all. It supports integer andfloating point types natively. Fixed point is supported by vendorsupplied libraries. 4) C does not provide overflow detection or carry out detection.Right, and that''s deliberate. One of the fundamental design goals ofC is that you don''t pay for what you don''t need. In the cases whereyou need these features, add them. Don''t try to burden every programby everyone else with them when they are not needed. The obvious rebuttal to this complaint is to program only in assembler language, however use of C/C++ is usually demanded by the customer. Comments are solicted. Thanks, Bill HannaC is adequate for embedded systems because customers demand it. Andalso because of the huge number of robust embedded systems that havebeen built with it over more than a quarter of a century.While all of this is off-topic, I do have two additional comments:1. Stop whining. If the requirement of your customers is to use C,either do it without complaint or perhaps look for another line ofwork.2. Most of your complaints are not about the language proper. Cdoesn''t support any hardware at all, not keyboards, video displays,disk drives, serial terminals, not anything. Nor does it supportinterrupts at all. So the fact that it doesn''t support ADCs or PWMsor DACs is irrelevant. Lack of support for the first list of hardwareI mentioned hasn''t stopped C from being used for almost every majoroperating system. Lack of standardized support for interrupts (andwhat a nightmare that would be) has not prevented interrupt routinesfrom being written in (non-standard, extended) C in operating systemsand applications for desk tops.Your problems appear to be not so much with the language, but withyour compiler vendor. Apparently they are not doing such a good jobproviding usable extensions for your particular platform.--Jack KleinHome: http://JK-Technology.ComFAQs forcomp.lang.c http://www.eskimo.com/~scs/C-faq/top.htmlcomp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq# Comments are solicted.The usual technique is to find a base language that you like, perhaps Cor Bliss or Ada or PL/I or Algol or Fortran, then adapt it to your specificneeds. Some of things you want simply do not exist on this or that cpuI''ve worked on over the years. Demanding all of them to be standardisedinto something like C would create a language that would be unusable forsome systems.If customers demand things be done in a language that can''t possiblysupport it, you should''ve negotiated those issues before accepting themas customers.--Derk Gwen http://derkgwen.250free.com/html/index.htmlWhat kind of convenience store do you run here? 这篇关于嵌入式系统需要改进的C版本。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！