View Single Post
  #7   Spotlight this post!  
Unread 22-02-2010, 13:32
gvarndell's Avatar
gvarndell gvarndell is offline
Software Engineer
AKA: Addi's and Georgie's Dad
FRC #1629 (GaCo)
Team Role: Parent
 
Join Date: Jan 2009
Rookie Year: 2008
Location: Grantsville, Maryland
Posts: 350
gvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond reputegvarndell has a reputation beyond repute
Re: Code download issue

Quote:
Originally Posted by mikets View Post
Thanks for the info. It makes sense now. So this is similar to the Intel x86 processor with respect to short and long jumps. And the problem is not within our code but between our code and the OS code that the distance could be beyond 16MB?
There's 64M RAM in the cRio, making that likely.

Quote:
It is still strange that I am imagining between our code and the OS/library code, it should only have CALLs instead of BRANCH instructions but then I am not familiar with PPC.
PPC doesn't have a CALL instruction, only branches.
Function calls are implemented by a special branch instruction that saves the address of the next instruction in an internal register before branching. Without -mlongcall, the offset of the branch target must fit in the 24-bit offset field of the 32-bit branch opcode -- as a signed value.

Quote:
I am surprise that not more people hit this. We must be the lucky ones that the loader decided to load a lot higher than other people.
No, plenty of people stumbled over it. Empirically, it seemed (and still does) that everyone who was bitten by it had failed to apply all updates to Workbench and/or LabView.
__________________
Robots never, ever, ever, ever break -- The Robot Repairman (Backyardigans)
Reply With Quote