Defining allocation space.

Hi friends.

I am wondering if there are any methods for defining the memory allocation for a function level "symbol" (fx pointer or array).

I know the DATA_SECTION pragma can be used on file level. Is there a simular method that can be applied for non-global variables?

Thank you for your time.

Esben.

Can you please post some more details ? The code that you might be working with.

Hoping to see you back soon.

REALNAPSTER

I wouldn't think so, the stack works quite well and it's efficient. Where else do you want to put them? You can align data with the aligned keyword (if that's at all helpful). You could also use static, I think that plops it in bss or data, not sure though.

>the stack works quite well and it's efficient. Where else do you want to put them?

Arent variables normally allocated on the heap?

I am tuning some code to run fast on a TI c6416 dsp. I have a problem with thrashing of one of my dynamic arrays, and I want to make sure that this array is read into a different cache-line than the arrays that might be thrashing it.

I am not sure this code will make any sense in regards to the cache problems but here it goes:

Code:

static void jpc_qmfb1d_split(jpc_fix_t *startptr, int startind, int endind,
  register int step, jpc_fix_t *lstartptr, int lstartind, int lendind,
  jpc_fix_t *hstartptr, int hstartind, int hendind)
{

               const int bufsize = JPC_CEILDIVPOW2(endind - startind, 2);
#if !defined(HAVE_VLA)
#define QMFB_SPLITBUFSIZE 4096
	jpc_fix_t *splitbuf=(jpc_fix_t*)malloc(sizeof(jpc_fix_t)*QMFB_SPLITBUFSIZE);
#else
	jpc_fix_t *splitbuf=(jpc_fix_t*)malloc(sizeof(jpc_fix_t)*bufsize);
#endif
	jpc_fix_t *buf;
	int llen;
	int hlen;
	int twostep;
	jpc_fix_t *tmpptr;
	register jpc_fix_t *ptr;
	register jpc_fix_t *hptr;
	register jpc_fix_t *lptr;
	register int n;
	int state;

	buf = splitbuf; 
	twostep = step << 1;
	llen = lendind - lstartind;
	hlen = hendind - hstartind;

#if !defined(HAVE_VLA)
	if (bufsize > QMFB_SPLITBUFSIZE) { //esbn: ..SIZE=4096.
		if (!(buf = jas_malloc(bufsize * sizeof(jpc_fix_t)))) {
			abort();
		}
	}
#endif
	
                state = 0;
	ptr = startptr;
	lptr = lstartptr;
	tmpptr = buf;
	n = llen;

	#pragma MUST_ITERATE(2,,); 
	while (n-- > 0) {
		if (state) {
		                *tmpptr = *lptr; 
			++tmpptr;
		}
		*lptr = *ptr; 			
                                ptr += twostep;
		lptr += step;
		state ^= 1;
	}
		
	ptr = &startptr[((((llen + hlen) >> 1) << 1) - 1) * step];
	hptr = &hstartptr[(hlen - 1) * step];
	n = hlen - (tmpptr - buf);
	#pragma MUST_ITERATE(2,,); 
	while (n-- > 0) {
		*hptr = *ptr;
		ptr -= twostep;
		hptr -= step;
	}
		
	n = tmpptr - buf;
	#pragma MUST_ITERATE(2,,); 		
                while (n-- > 0) {
		--tmpptr;
		*hptr = *tmpptr;
		hptr -= step;
	}

#if !defined(HAVE_VLA)
	/* If the split buffer was allocated on the heap, free this memory. */
	if (buf != splitbuf) {
		jas_free(buf);
	}
#endif
}

My problem is with the 'tmpptr', which points 'buf', whick points to 'splitbuf'. I would like to control the allocation of this 'splitbuf' to avoid thrashing...

Hope this made some sense...

Esben.

1. How do you know it is a cache problem?

2. What is the difference between malloc and jas_malloc ?

3. Why don't you free splitbuf - I see massive memory leakage here.

malloc and free calls can be pretty expensive, maybe this is the actual cause of the problem.
For a given input, compare the results with using a static array of a known size with using malloc to allocate the same.

4. Why are you using the register keyword?

Modern compilers are much more efficient at working out which variables are best stored in registers.
At best, the compiler will just ignore your attempts
At worst, the compiler will try and obey your wishes, even if the code is worse as a result.

>Salem:

>1. How do you know it is a cache problem?
I have runned a profiling analysis on the code, and can see that I have 5% cpu stall cycles caused by cache read and write misses...

>2. What is the difference between malloc and jas_malloc ?
No difference really. jas_malloc() just calls malloc(). Guess it's for portabililty purposes or something. I'm not sure, the original code is open source, not mine.

>3. Why don't you free splitbuf?
ups...and you are right: it just costed me 80,000 cpu cycles to free the splitbuf. I declared it as a static array instead and gained back almost 150,000 cycles.

By the way, the reason I have declared it as a dynamic array is off course for flexability purposes. Is there any way to keep this kind of flexability with a static array?

The original declaration looked like the following. It couldnt build on TI.s CCS developer, and I must say I find it strange that it could in MSVC...

Code:

const int bufsize = JPC_CEILDIVPOW2(endind - startind, 2);

#if !defined(HAVE_VLA) 
#define QMFB_SPLITBUFSIZE 4096
	static jpc_fix_t splitbuf[QMFB_SPLITBUFSIZE]; 
#else
	jpc_fix_t splitbuf[bufsize];
#endif

>4. Why are you using the register keyword?
Good question. I removed the register keyword and gained 300 cycles

> and can see that I have 5% cpu stall cycles caused by cache read and write misses
Since you seem to be walking through memory in a linear fashion, this doesn't seem unreasonable.
Are there any #pragma hints for cache prediction?
Is there a cache API, which may for example make it more favourable to linear access rather than random access?

> while (n-- > 0)
> if (state)
If n is always even when you run this loop, I would suggest you unroll it and eliminate the state variable altogether. Even if it isn't, making the last iteration a special case is going to be preferable to testing the flag on each iteration.

Code:

  while (n-- > 0) {
    // these lines done when state == 0
    *lptr = *ptr;
    ptr += twostep;
    lptr += step;
    
    // these lines done when state == 1
    *tmpptr = *lptr;
    ++tmpptr;
    *lptr = *ptr;
    ptr += twostep;
    lptr += step;
  }

> #pragma MUST_ITERATE(2,,)
Check your optimisation hints.
http://tii.developerconference.ext.t...n-tutorial.pdf
> My problem is with the 'tmpptr', which points 'buf', whick points to 'splitbuf'.
In particular, does your compiler support the "restrict" qualifier which helps to reduce the pointer aliasing problem.

> Is there any way to keep this kind of flexability with a static array?
Perform some calculation to determine whether your static array is big enough. If it is, use it. If not, malloc.
Or you could just pass the problem back to the caller, and let it supply the working storage buffer as another parameter, since the caller is likely to know more about what is required.

> and I must say I find it strange that it could in MSVC
Variable length arrays are a C99 only feature. It is not in C89 nor C++.
However, this doesn't stop individual compilers from extending the language in various ways, and vla's seem a popular thing to support.

Salem: thanks for you helpful suggestions.

>I would suggest you unroll it and eliminate the state variable altogether.

I dont understand how UNROLL together with your code example corresponds to the original code...?

Esben.

State toggles between false and true
It's simply all the code which executes when state == 0, followed by all the code which executes when state == 1

Sure! I see it...and I would have to run the loop n/2 itertions, right?

Yes.