eTPU Local Variables

[erdinc26]

Hello,

I work on MPC5674F with eTPU2.

I read most things about global and local static variables how they stored in memory, but I have never seen anything about local variables. I looked .lcf file of eTPU code.

There is a section as stack. Are local variables here? Are they common for all channels?

If you source about memory sections please share with me.

Best regards,

Erdinc

@davidtosenovjan @johndiener 

[erdinc26]

Thanks for your answer. @johndiener @davidtosenovjan 

Do you have any source about Freescale ETPU compiler v1.5.1? (CodeWarrior Development Studio for eTPU - Version: 10.2.2)

Also how local variables stored in memory for this compiler?

Best regards.

Erdinc

[johndiener · Accepted solution]

I can't speak for any of the compilation tools besides Ashware's, but I would assume all obey C scoping rules - that is that local variables are only visible within their C scope.  That being said, due to the unique nature of the eTPU architecture, how local variables are actually stored is unusual.  First, if possible, local variables are processed using registers, or possibly optimized away entirely, as would be done on almost any architecture or by any toolset.  However, if local variables overflow the available register set, they must make use of the shared data memory.  This is where things get interesting.

Most architectures make use of a stack and temporarily store function stack frames, parameters, and local variables there.  The eTPU instruction set makes such a solution difficult but not impossible (more later).  The original eTPU solution was to store these register-overflowing locals in what is referred to as "global scratchpad" memory.  Basically under the hood local variables are stored at a static address, somewhere in the eTPU global data range (relative addresses 0x0 - 0x1023).  This is reasonably efficient but has a few drawbacks - recursion cannot work (not a big deal) and more importantly, if the same eTPU code (function) is running on both eTPU engines that share data memory, simultaneously, they can corrupt each other's local variables - a big problem.  Fortunately this doesn't affect most eTPU code - either the code does not need to use scratchpad, or does not need to run simultaneously on both engines.  And there are some more complex work-arounds.  Generally, I recommend using the global scratchpad memory model in most cases - it is the most efficient.

In order to address the potential corruption issue, the eTPU2 added an engine-relative addressing mode.  I believe all toolsets have an "engine scratchpad" mode that is similar to "global scratchpad" but each engine has their own copies of data (such as local variables) that get assigned to that memory space.  It is somewhat less efficient.  I don't know about other tools, but with Ashware you can actually select the mode on a translation unit (object file) basis, although that is generally only recommended for advanced users.

As alluded to earlier, there is one other option.  Ashware does provide a true stack-based memory model for function frames and local variables.  It is less efficient as the eTPU instruction set was not designed to easily support a true stack. This capability is rarely needed, but does exist.

More information on eTPU programming and memory models, from Ashware's perspective, can be found in http://services.ashware.com/Download_Files/compiler_ref_manual.pdf.