四个嵌入式CPU标准面临的共同挑战

四个嵌入式CPU标准面临的共同挑战

组织接口（DRI）。以下是它们是什么以及每种情况发生了什么。

在所有最近的标准中，VSIPL最有可能被用户采用，因为它的实现很简单，并且与硬件和系统软件的工作方式不冲突。它的问题都与性能和开销有关，用户可以及时学习绕过它们，或者可以在实施者的帮助下消除它们。用户还没有急于接受VSIPL规范，因此供应商采用了观望策略。

功能子集

大多数供应商都实现了一小部分功能调用根据客户的要求提供更多功能的想法。另一方面，用户并不急于采用VSIPL，因为他们面临困境：使用VSIPL意味着放弃经过充分测试并经得起时间考验的遗留代码。在VSIPL中重新编码相同的数学方法在短期内是繁琐，昂贵和无利可图的。

也许所需要的是新的授予MPI/RT工作站版本的唯一目的，就像MPI一样。不幸的是，资助机构在启动这种标准化和可移植性工作方面有着悠久的历史，并且在这些项目期间没有跟进额外的资助。因此，在MPI/RT开发工作中是否可以获得这样的授权是值得怀疑的。

MPI

MPI存在了大约八年，是一个较旧的消息传递库，它标准化了多处理环境中节点之间的通信。嵌入式系统用户可能会质疑API的特性：

MPI提倡旧式过程编程技术，这些技术依赖于发送和接收功能来分发与数据保持独立的数据。功能。

MPI通信基于后期绑定协议，会损害性能。在执行发送或接收功能之前，系统不知道通信即将发生。在数据传输之后，没有信息被保留以指示可以再次使用相同的通信线路，从而阻止系统优化重复的数据移动。

MPI不是为嵌入式和实时系统设计的。但是，它的存在时间比任何其他便携式软件标准都要长，并且得到了公共工作站版本的强力支持。嵌入式系统供应商采用MPI为其平台感受到客户的压力，用户经常将其用于基准测试目的。该库的某些版本甚至已经安装在面向国防的实验室中，以协助在桌面环境中进行的研究项目。但是当谈到嵌入式和实时系统的部署时，以及人的生命依赖于系统可靠性和性能的情况下，不使用MPI。

不幸的是，MPI/RT论坛无法创建MPI的实时扩展，这将扩展到现有的MPI功能，并提供错误处理和嵌入式应用程序中急需的恢复过程。在目前情况下，MPI将继续不足以用于嵌入式系统，MPI/RT将继续疏远新应用的潜在设计者。这种情况违背了嵌入式系统编程标准规范的可行性。

DRI是一个高级库，它使用底层通信机制（如MPI或MPI/RT）在本地重新分配多维数据集在众多处理节点中。潜在用户可能会在以下方面质疑此API：

DRI规范不完整，并且不清楚何时完成1.0版。初步规范仍然包含逻辑错误和矛盾，需要缩小其重点，而不是争取更多的一般性。

关于DRI分配数据缓冲区和底层通信机制的属性存在未解决的问题。多维数据空间。

尽管应用程序和底层通信协议都可以提供自己的分配机制，但仍在考虑DRI内存分配。

MPI和MPI/RT是完全不同的，以引起人们的怀疑，即两个API都可以支持DRI级别上显示的相同类型的数据移动。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。