cRIO and PowerPC stuff

[Bsteckler]

I sent this out to the programmers and electricians on my team, thought this might be of some help to the community:

Those who attended the workshops know that the cRIO that we will be using is powered by a Freescale 400 MHz PowerPC processor, this is substantially different then the PIC chip that we have used in the past, and I have compiled some stuff on the archetecture of the chip to aid in programming. Most of this probably won't make sence to you if you don't know much about microarchitectures, but its useful nonetheless.



These are some pages about the workings of the chip:

http://www.go-ecs.com/ppc/ppctek1.htm
http://www.ibm.com/developerworks/li...ary/l-powarch/

http://developer.apple.com/documenta...H240-TPXREF101


For those who don't want to read that, here is what it all means:


1) we have a ful 32 bit desktop grade processor to play with.

2) the PowerPC has 32 general purpose registers, and varying numbers of special purpose regisers, and some also have floating point registers. (in compairison, an x86 has a total of 8 registers).

3) being a 32 bit processor, it can address up to 4 GB of space (Physical RAM)

2) it can support strings up to 128 bytes in length, and can natively support byte, word, halfword, and doubleword data types

3) PowerPCs use big-endian byte ordering, so the most significant byte in any of the above data types is given the lowest address

4) the calling convention of the PowerPC passes arguments to functions into the registers (has no stack) whereas an x86 sends them to the stack, as such, programming errors and adressing variables outside of an array are less likely to cause a crash on a PPC

5) However, the EABI creates a "virtual stack" by reserving GPRs as stack pointers.

6) PowerPCs use shorter pipelines with complex stages, wereas an x86 uses longer, skinnier ones (basically, an x86 can run fast, but a PowerPC can do more stuff)

7) PowerPC instructions are 4 bytes in size and must be alligned, whereas x86 ones are variable in size and do not need to be alligned

8) the type 'bool' is four bytes on PowerPC, rather than one on x86

9) an integer divide by zero operation returns a 0 on PowerPCs, but floating point divide by zero operations cause a crash

[Greg McKaskle]

I have a few comments I thought I'd add.

Originally Posted by Bsteckler

2) it can support strings up to 128 bytes in length, and can natively support byte, word, halfword, and doubleword data types

4) the calling convention of the PowerPC passes arguments to functions into the registers (has no stack) whereas an x86 sends them to the stack, as such, programming errors and adressing variables outside of an array are less likely to cause a crash on a PPC

9) an integer divide by zero operation returns a 0 on PowerPCs, but floating point divide by zero operations cause a crash

2. String instructions such as the ones to convert from number to string have limits, but this doesn't mean that there are limits on string sizes once you are using libraries for C or LV. In reality, LV strings are limited to 2GB, and C ones are probably limited to 4GB. In addition to string sizes, the PPC is rather strict on alignment, generally words need to be on a 2 byte boundary, longs on a 4, I believe doubles need to be on a four, and there is a performance advantage to eight byte alignment on some PPC architectures, I don't really think that applies to this version.

4) Since you have an OS and libraries you are interoperating with, the ABI (application binary interface) is equally important to pay attention to as the HW architecture. The EABI defines the registers to use for stack and stack linkage. This defines how the linkage between function calls fit on the stack and are pointed to by registers. This also defines which types go in registers by value, which by reference, and at what point things may go on the stack. I don't know about the VXWorks ABI, but I'm guessing it is something like the MS and Apple one. Arrays are not stored in registers, and addressing outside of an array or other storage is still very likely to crash or cause an exception.

9) This crash is actually a signaling, and the exception settings define whether signaling is on or off. Generally the signaling is off and the results will result in an infinity -infinity, or a NaN depending on the number being divided by zero. For details refer to the IEEE 854 spec.

The other thing to familiarize yourself with is how the language handles these issues. C, C++, and LV will all help with these areas to differing degrees.

Greg McKaskle

[Bsteckler]

Thanks for adding that, I basically just pulled stuff from the websites that I found. Those were probably written for a 601,603/603e, or 604. Whereas the cRIO is (hopefully) using something more advanced, such as a 750 or a 74xx series (G3 and G4 for those who don't know).

[Greg McKaskle]

The exact processor is the Freescale MPC5200, which is a part of the 603e family. So sorry, no Altivec or advanced stuff. This is low power, highly integrated, industrial temperature, etc.

Greg McKaskle