Memory limitations for instructions per thread

[MarcAntigny]

Hi all,

I'm working with the XU232-1024. I found that the memory is equally divided between the 4 tiles (256 kB for each). I have 6 threads running on one tile with many instructions. After compilation, the analyzer tool told me that each thread took about 5kB of memory for instructions. My datas for this tile took 6kB so about 36kB are used on the 256 kB available (6 * 5kB + 6kB). However when I add a bit of instructions in the threads, the compiler raised an error :

Code: Select all

..\.build_XX\foo.xc.o: Error: Changed section attributes for ''
..\.build_XX\foo.xc.o: Error: first set here

Is there such a limitation in memory for instructions per thread ? I suspect that there is a limitation of 32kB but have no hint on the origin of this. Any clues or information I missed ?
Thanks a lot,

Marc

[mon2]

Same error is referenced here:

http://www.xcore.com/viewtopic.php?t=6152

[MarcAntigny]

I already read the topic before posting. In my xn file, I got the right lines :

Code: Select all

<Package id="0" Type="XS2-UnA-1024-FB374">
			<Nodes>
				<Node Id="0" InPackageId="0" Type="XS2-L16A-512"
					SystemFrequency="500MHz" Oscillator="24MHz">

And I've tried with -O2 and -Os optimization level and I got the same errors...
Moreover, in the post you linked, the memory was about to be half-full for the tile 1 :

Code: Select all

Memory available: 262144, used: 128220 . OKAY

which is not even my case (I'm about 30kB on 256kB available).

Maybe it is linked with optimization levels but to go from 30kB to 256kB+ with few more lines seems really surprising.

[plex]

I use the XEF232-1024 and for tile[0] I am utilising 220kB total and more than 60kB in a single thread(size of functions from analysis without data and stack) without a problem.
I compile with -O3 and -mno-dual-issue.
There does not seem to be memory limitation per core/thread.
Basic question but have you tried Clean Project and then Build?

[MarcAntigny]

Hi plex,
Yes I did clean project (and "clean all" too) and rebuild. Several times. I even tried to re-import my project (cleaning workspace manually). And I got the same issue...

I investigate a bit and it seems that the limitation occurs at 40kB of memory for code. Seems totally confusing cause it's not a power of 2 nor the maximum available.
I have no idea of the reasons behind the errors.

[MarcAntigny]

Hi,
I searched where does the issue come from, and I found that the "pragma loop unroll" with large loop lead to the errors

Code: Select all

..\.build_XX\foo.xc.o: Error: Changed section attributes for ''
..\.build_XX\foo.xc.o: Error: first set here

I tried with several configuration (large loop of X steps for examples, smaller loops which steps sum equals to X) and I got the same issue.
Any hints on how the pragma unroll loop organize instructions ? It seems there is a limitation but I didn't get how to change it.

[mon2]

Marc, would you please review the following suggestions from Infiniteimprobability of using the -t flag and also the -s flag and post your results? These options should show the low level memory mappings.

http://www.xcore.com/viewtopic.php?t=5901

https://www.xmos.com/published/how-disa ... g-xobjdump

[MarcAntigny]

Hi mon,
As the errors occur at compilation, I have no .xe file to feed the xobjdump.
I tried it with reduced version of the code, which did compile. The assembly file obtained with -S flag was right and the loop well unrolled. However, it was obviously what I expected because if there were the issue, it could not have compile.
So I can't analyze what lead to the errors because the errors break the compilation...

[mon2]

Marc, consider to open a support ticket on the xmos.com website and/or contact your local FAE for assistance on this case. Please post your results.

Perhaps you have stumbled across some obscure compiler bug?

[mon2]

Marc, is it possible that you are facing a similar issue as posted here?

https://gcc.gnu.org/ml/gcc-help/2010-09/msg00098.html

> File boot.c is like below:
>
> int val[] __attribute__ ((section(".text"))) = {1, 2, 3, 4, 5 ,6};
> int getval(int i) {
> return val;
> }
>
> Then i compile it use gcc-4.2.4 and binutils2.20
>
> arm-elf-gcc boot.c -c -o boot.o
>
> It gives a warning:
>
> /tmp/ccIlHjum.s: Assembler message:
> /tmp/ccIlHjum.s:4: Warning: ignoring changed section attributes for .text
>
> What's wrong? What should i do to remove the warning?

You are putting a writable variable in .text, so gcc is trying to make
.text be writable. That fails, because .text was already implicitly
declared as read-only.

When using __attribute__ ((section)) you should normally stick to your
own sections, rather than trying to use existing ones.

You will in any case get a similar effect if you write
const int val[] = ...

Ian