Mapper output file: mapfile? Topic is solved

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 332
Joined: Wed Apr 25, 2012 8:52 pm

Mapper output file: mapfile?

Postby aclassifier » Wed Jan 11, 2017 9:00 am

I have tried to have a complete map of the resourse usage generated, but the only I seem to get to work is

Code: Select all

XCC_FLAGS -report
It gives a summary, here's a line from it:

Code: Select all

Timers available:          10,   used:          7 .  OKAY
I'd like to see where those timers are. I have tried the recipe in [1] but I don't seem to solve it that way. Like

Code: Select all

XCC_MAP_FLAGS = --map _Aquarium_map.txt
added, but the

Code: Select all

# If the variable XCC_MAP_FLAGS is set it overrides the flags passed to
# xcc for the final link (mapping) stage.
probably, only causes that to give

Code: Select all

xcc: _Aquarium_map.txt: No such file or directory
xmake[1]: *** [bin//_Aquarium.xe] Error 1
xmake: *** [bin//_Aquarium.xe] Error 2
I have tried to add it to the general param field:

Code: Select all

XCC_FLAGS = -O2 -g -report -fxscope -save-temps -Xmapper --map -Xmapper _Aquarium_map.txt
it then doesn't complain, but I see no file.

And I have found nothing in the xTIMEcomposer User Guide [2] that I am able to apply correctly.

Please?

[1] https://www.xcore.com/forum/viewtopic.php?f=26&t=254
[2] https://www.xmos.com/download/private/x ... (14.x).pdf
View Solution
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Wed Jan 11, 2017 9:23 am

The last line is the right one, and you should be able to put that in XCC_MAP_FLAGS (you don't really care whether these flags are used during the compilation stage)

Code: Select all

XCC_MAP_FLAGS = -Xmapper --map -Xmapper _Aquarium_map.txt
I am not sure where the file will be placed - it may be in the .build directory?

Cheers,
Henk
User avatar
aclassifier
Respected Member
Posts: 332
Joined: Wed Apr 25, 2012 8:52 pm

Postby aclassifier » Wed Jan 11, 2017 9:56 am

Thanks, henk! It now worked, I found it in .build. But I had to move -report down from XCC_FLAGS:

Code: Select all

XCC_FLAGS = -O2 -g -fxscope -save-temps
XCC_MAP_FLAGS = -Xmapper --map -Xmapper _Aquarium_map.txt -Xmapper -report
But it didn't help in finding out timer usage. This is all there is about tmr or timer:

Code: Select all

00014ebe 0000000e .text                __init_threadlocal_timer
00014ecc 0000000c .text                __free_threadlocal_timer
000155fc 0000000c .text                xscope_gettime_local_timer
00018af4 00000020 .dp.data             __timers
00018d98 00000020 .dp.bss              __timer_base
00018db8 00000020 .dp.bss              __timer_delta

000155e0 00000008 .text                xscope_tmr.ctor
000155e8 00000008 .text                xscope_tmr.dtor
00018ddc 00000004 .dp.bss              xscope_tmr

From -report:
Timers available:          10,   used:          7 .  OKAY
I have some timers and some are used by used libraries and some hidden in delay_microseconds uses. Where's this info?
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Wed Jan 11, 2017 10:06 am

I think what you see is that the tools allocate a timer per thread, store those in a global array, and each thread uses the timer allocated to it. That avoids having to pass timers into and out of functions, and I guess simplifies distribution and combining, at the cost of being less efficient in some places.

So - it will have grabbed a timer per "logical core".

In addition, xscope uses a timer; although it shouldn't need one on XCORE200 (the XS2 instruction set has an instruction to get the current time without having to allocate a timer).

Assembly code may still allocate its own timers.

You can tell the tools to use hardware-timers everywhere.
User avatar
aclassifier
Respected Member
Posts: 332
Joined: Wed Apr 25, 2012 8:52 pm

Postby aclassifier » Wed Jan 11, 2017 10:06 am

henk wrote:.. and each thread uses the timer allocated to it.
So - it will have grabbed a timer per "logical core".
Assembly code may still allocate its own timers.
Hmm. So when the select statements of [[combinable]]s are merged into one select then it's only the next timeout that counts, and therefore may reuse a single hw timer per logical core?
henk wrote:.. You can tell the tools to use hardware-timers everywhere.
HW timer is not port timers, I assume, but standard "timer"? Does this mean that it could in fact use several hw timers per logical core?
henk
Respected Member
Posts: 346
Joined: Wed Jan 27, 2016 5:21 pm

Postby henk » Wed Jan 11, 2017 11:05 am

The architecture resource 'timer' maps onto the XC type 'timer'.
There is two ways that this mapping can be achieved - soft, in which case the compiler conjures up one architecture-timer per thread, or hard, in which case the compiler allocates an architecture-timer for each timer declaration in XC. The latter enables the most efficient selects with multiple time-outs.

Indeed, port counters are something different, they count clock edges from an IO pin into a clock-block.
User avatar
aclassifier
Respected Member
Posts: 332
Joined: Wed Apr 25, 2012 8:52 pm

Postby aclassifier » Wed Jan 11, 2017 11:09 am

Thanks a lot, again, henk!-)

Who is online

Users browsing this forum: No registered users and 1 guest