原创 [eCos相关]HAL中的Global Pointer

在hal-architecture-characterization.html文档的末尾：

Global Pointer
CYGARC_HAL_SAVE_GP()
CYGARC_HAL_RESTORE_GP()
These macros insert code to save and restore any global data pointer that the ABI uses. These are necessary when switching context between two eCos instances - for example between an eCos application and RedBoot.
唯有在MIPS体系结构的hal_arch.h中实现了这两个宏定义，其余体系结构的hal_arch.h中均未实现。即是说从RedBoot切换到eCos application之后，无法再返回RedBoot。

SAVE与RESTORE必须成对使用。

//以下内容来自网络，不知其对错

ABI(Application Binary Interface)或EABI（Extend ABI）(ABI又分为oabi和nabi,即旧新两种)通常是处理器体系结构的一部分，它与平台是紧密相连的。
我们可以把ABI理解为一套规则，这套规则一般包括定义了以下内容：

1、应用程序如何发出系统调用来trap到内核态。
2、如何使用机器的寄存器。比如，RISC处理器的ABI就要规定用那个通用寄存器来作stack pointer和frame pointer。
3、规定如何进行procedure call。
2和3是最重要的，而且特定于那个平台的编译器和链接器实现都要遵循这些约定。

1)GCC 3.0 改进了对C++的支持。修正了原来版本中C++库中的多个错误，让GCC 3.0 更好地遵循ISO C++ 标准，还提供面向C++新的应用二进制代码界面（ Application Binary Interface ：ABI)。
2)ELF為 COFF 格式的後繼者，主要的特徵為可以具有複數節區段，並可以使用32-bits或是64-bits的數值。 主要的缺點為： ELF 格式是在每個系統中只 會有一種 ABI 的假設為前題被設計出來的。但是，在事實上，這個 假設錯的離譜。因為，縱使在商用的 SYSV 世界裡，也至少有 SVR4， Solaris 和 SCO 三種 ABI。

若两个程序 ABI 不同, 但 API 兼容, 用相同的 ABI 重新编译其中一个程序就行了.
比如 libstdc++.so.5 和 libstdc++.so.6 API 兼容, 但 ABI 不兼容, 一般的商业软件, Realplayer, Adobe Reader 都是用libstdc++.so.5 的 ABI , 但你自己不能重新编译, 所以必须要装 libstdc++.so.5 .
如果你有 Realplayer 的源码 ( Helix ), 因为 C++ 的 API 是兼容的, 就可以用 libstdc++.so.6 的 ABI 编译出用 libstdc++.so.6 的.
-----------------------------------------------------------------------------------------------------
abi（应用二进制接口）我的理解就是机器代码一层的接口。先说一下api（特指系统调用）,
api基本上是和机器硬件平台无关但是和操作系统密切相关的接口，一个api调用定义了一个对内核的操作，以及操作的参数。C语言会议函数的形式调用api。
   
abi，是比api更贴近硬件的一层接口，它规定的是二进制代码之间的调用规则。举个例子来说吧！
一个应用程序，调用了.so库中的函数或者系统调用，如果它的编译器可以找到被调用函数或者系统
调用的话，则编译可以同过，也就是说，它是用的api是正确的。但是，这个调用离成功还很远。。。。。
   
首先，如果编译出来的代码和运行库函数和系统调用的代码不是一个硬件平台的，则这个应用根本就不能和被调用代码运行在一起，则调用不会成功。
   
即使库函数、系统调用和是运行在同一硬件平台上的调用也不一定会趁成功。因为程序最终是被编译成二进制代码的，并且是要加载到内存中运行的。那么，在调用库函数或者系统调用的时候，应用要先要以库函数或者系统调用指定的方式和位置（内存或者寄存器）设置参数，然后通过中断或者其他方式跳转到被调用代码的起始处进行执行，被调用代码从指定位置去到参数，处理完毕之后再将结果放到指定的位置，最后应用再到指定的地方取回结果，调用完毕！