[taichichuan]

Yes, the 24-bit thing is a side effect of the memory architecture of the PPC processor in the cRIO. It turns out that the goal of the PPC was to execute almost all calls in 1 clock cycle. The fast local branch call executes in one cycle. But, in order to do that, the chip designers had to limit the distance of the branch. Hence, the fast local branch instruction is not 32-bit capable which is the reason for the -mlong-calls option in the C++ compiler. The -mlong-calls uses a 32-bit branch instruction that is relative to the contents of a special-purpose register on the PPC. The 32-bit capable call takes additional instruction execution time that isn't required for the fast local branch instruction. This is not a big deal for FIRST, but it does cause problems for some mission-critical uses of non-64 bit PPC processors.

The PPC is actually a very odd duck in that it uses the IBM RISC System-6000 instruction set, Motorola 88K cache & MMU and the limitations on memory that Apple had back 20 years ago when those companies got together (called the Apple-IBM-Motorola (AIM) alliance) to create the PowerPC. In the early 90's, having more than 16 MBs of RAM was unthinkable due to cost. So, they made some design decisions that made sense at the time but have come back to haunt us many years later.

The "Run as kernel task" option in Workbench loads your code into a special Wind Debug Agent (WDB) pool of memory located just above the O/S in low memory. However, then you deploy the code to the cRIO, your application can be loaded into high memory at the discretion of the loader (it uses a best-fit memory model). Therefore, when you run from Workbench, things will work fine. But, when you deploy the code, you're too far away for the fast local branch instruction of the PPC processor. So as George pointed out, use the -mlong-calls option to the compiler and you should be fine.

HTH,

Mike