大规模的并行运算;想利用多个CPU的特点，如DM642这样的方案，应用于复杂的视频方案。想利用DSP的浮点计算能力，同时也使用ARM的事务计算能力;

　　单纯的提高系统的性能：对于普通的应用，提高系统性能是基本出发点。但嵌入式系统应用多处理器并不是一个简单的事情。多处理器的软件设计难度很大，调试也是很大的问题。

　　如果不采用操作系统处理，采用前后台系统。那么自己还要设计一个通信算法，还要设计一个结果整合系统。这样的系统自己设计很多东西，其中总线的可靠和容错设计至关重要。

　　所以可能的话，利用成熟稳定的操作系统来支持多处理器可以减少不少的开发难度。然而，寻找这样的一个操作系统并非易事。

　　首先要明确自己的应用，需要线程进程迁移吗?需要处理器平衡吗? 对于多处理器，如果不支持线程进程迁移，那也就谈不上处理器任务的动态平衡，不然只能事前指定好线程进程运行于哪个处理器。对于异构型多处理器，线程迁移和进程迁移并没有多大的实际意义。对于追求利益的公司来说，目前还谈不上实用价值。所以，迁移只限于对称处理器。

　　然而，对称处理器也不是什么进程可迁移。对于对称处理器，操作系统封装好底层，让用户开发起来像是对一个CPU再做开发，当然不可能与单个CPU完全一致，但起码减轻了许多难度。

　　很多朋友问我RTEMS可以跑在x86这样的CMP的多处理器上吗?当然。但是，设计起来又不同于普通的对称多处理器。因为，CMP处理器上的CPU共享了许多东西，中断，内存，总线，他们的编址空间基本上都是一致的。对于RTEMS这样的RTOS来说，它采用的是异构型的方式支持对称处理器，即有几个CPU就得跑几个RTEMS。

　　那么通讯显得尤为重要，多个RTEMS需要多个系统的TICK，那么TICK从哪里来，CMP共享着很多资源，那么就要求，使用者必须为RTEMS手动的指定中断源，划分内存空间，这就造成了，CMP上的多个CPU虽然都是跑RTEMS，但是想关于CPU的驱动很多都是不一样的。这种紧耦合的系统是非常难办的。

　　相对于CMP，同 种CPU组成的P就要简单一些，因为全部驱动都是一样的，可能会因为通信方式的问题，通信驱动要特殊处理一下，但这会极大的减轻了开发的压力和调试的难度。总好比每个CPU一个Core，那是要崩溃了。特别是调试问题，所以从经济角度的问题考虑，还是比较喜欢这种多个相同的单个CPU组成的多处理器系统。

　　很多时候，对于那个异构型的处理器，当然用RTEMS也可以轻松摆平，但是还是一个问题，多个核心需要自己的RTEMS支持，开发多有不便。况且，操作系统的调试还是比较复杂的。所以现实版的方案都是，异构型处理器当中负责事务运算的处理器跑操作系统，而负责计算的处理器采用前后台系统，简单的通过共享内存通讯，响应操作系统的计算请求。

　　这样大大的减小了开发难度，反正操作系统把DSP当作了个硬件的寄存器，写几个寄存器就能得到结果，或者是输入一组天文一样的数据，得到一个复杂的结果。Anyway，总之这样的反应式的处理方式是绝大部分工程中采用的方式。就是简单、可靠、实用。

　　看来，嵌入式系统中的多处理器还是与应用高度的相关。