Memory limitations for instructions per thread

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
MarcAntigny
Active Member
Posts: 46
Joined: Tue Feb 13, 2018 2:50 pm

Memory limitations for instructions per thread

Postby MarcAntigny » Wed Sep 26, 2018 9:07 am

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
User avatar
mon2
XCore Legend
Posts: 1282
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Wed Sep 26, 2018 10:52 am

Same error is referenced here:

viewtopic.php?t=6152
MarcAntigny
Active Member
Posts: 46
Joined: Tue Feb 13, 2018 2:50 pm

Postby MarcAntigny » Wed Sep 26, 2018 11:05 am

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
Member++
Posts: 22
Joined: Fri Aug 12, 2016 6:13 pm

Postby plex » Wed Sep 26, 2018 1:45 pm

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
Active Member
Posts: 46
Joined: Tue Feb 13, 2018 2:50 pm

Postby MarcAntigny » Wed Sep 26, 2018 1:57 pm

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
Active Member
Posts: 46
Joined: Tue Feb 13, 2018 2:50 pm

Postby MarcAntigny » Thu Sep 27, 2018 9:53 am

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.
User avatar
mon2
XCore Legend
Posts: 1282
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Sep 27, 2018 9:55 am

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.

viewtopic.php?t=5901

https://www.xmos.com/published/how-disa ... g-xobjdump
MarcAntigny
Active Member
Posts: 46
Joined: Tue Feb 13, 2018 2:50 pm

Postby MarcAntigny » Thu Sep 27, 2018 1:20 pm

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...
User avatar
mon2
XCore Legend
Posts: 1282
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Sep 27, 2018 6:22 pm

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?
User avatar
mon2
XCore Legend
Posts: 1282
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Fri Sep 28, 2018 1:21 am

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[i];
> }
>
> 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

Who is online

Users browsing this forum: No registered users and 29 guests