allocate hwtimer assembly directive

If you have a simple question and just want an answer.
User avatar
akp
Respected Member
Posts: 323
Joined: Thu Nov 26, 2015 11:47 pm

allocate hwtimer assembly directive

Postby akp » Sat Nov 09, 2019 4:55 pm

Hello,

I am able to allocate a hwtimer in assembly using the getr instruction, and storing the handle to the data section works fine in a timer isr. However, I don't know how to inform the linker that I've used this timer, i.e. when it does the constraints checks it doesn't see that I've allocated this global timer so the constraints check isn't accurate.

I know I can get it to count if I use an xc file that contains

Code: Select all

hwtimer_t mytimer;
and then use that timer in the assembly. When I do an xobjdump, I see the following information

Code: Select all

    Opcode::SUM_REDUCE _num_global_timers, _num_global_timers_set, 0, 0
    ADD_TO_SET      _num_global_timers_set, 1, mytimer.ctor, 0
So I was thinking in my assembly file to do

Code: Select all

.sum_reduce _num_global_timers, _num_global_timers_set, 0
.add_to_set _num_global_timers_set, 1
but that gives me an error --

crt1.S: Error: Undefined reference to '_num_global_timers_set'

Any idea what I should do differently so my permanently allocated timer gets picked up in the constraints check?

[EDIT] The reason I want to allocate it in the assembly file is to ensure it's accessible from a 16 bit ldw instruction and won't need a 32 bit ldw instruction.
User avatar
mon2
XCore Legend
Posts: 1567
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Sat Nov 09, 2019 11:23 pm

hi akp. See if the comments from davelacey helps:

viewtopic.php?f=21&t=223&hilit=hwtimer&start=10
User avatar
akp
Respected Member
Posts: 323
Joined: Thu Nov 26, 2015 11:47 pm

Postby akp » Sun Nov 10, 2019 9:37 pm

Hi mon2,

Thank you, I read that but it doesn't seem to address my question. And in fact I am working on my updates to the FreeRTOS port to make use of the XS2 architecture, specifically dual issue assembly and some of the new instructions. So far I have reduced the context switch time by over 15% compared to using single issue assembly for the kernel. Everything is working, including the timer I am using for the system tick, except when I build the program with -report I get the following incorrect constraints check report:

Code: Select all

Constraint check for tile[0]:
  Cores available:            8,   used:          1 .  OKAY
  Timers available:          10,   used:          1 .  OKAY
  Chanends available:        32,   used:          1 .  OKAY
  Memory available:       262144,   used:      29400 .  OKAY
    (Stack: 436, Code: 11224, Data: 17740)
It is reporting just a single timer used -- i.e. the timer always allocated for the core. It should show 2 timers used, due to the timer allocated for the FreeRTOS tickclock. So I don't need to know how to allocate the timer, I've allocated it just fine, I just need to know how to tell the constraints checker that I allocated the timer in an assembly file rather than an xc file.

If I allocate the timer within an xc file using hwtimer_t tickclock, then I get the following:

Code: Select all

Constraint check for tile[0]:
  Cores available:            8,   used:          1 .  OKAY
  Timers available:          10,   used:          2 .  OKAY
  Chanends available:        32,   used:          1 .  OKAY
  Memory available:       262144,   used:      29412 .  OKAY
    (Stack: 436, Code: 11224, Data: 17752)
Like I said, both work perfectly fine in terms of the kernel. It's just that I can save one instruction in the timer ISR if I allocate the hwtimer in the assembly file, and I guess it saves a few bytes too. I know that seems ridiculous just to save one clock cycle in the ISR, it's kind of an exercise I am doing to see how much I can optimize something in assembly if I put my mind to it. So what I want to be able to do is determine the assembly directive so the constraints report shown at the top indicates 2 timers used -- like the second one shows -- rather than just 1 so that my constraints report is accurate. I hope this clarifies the issue I am facing.

Who is online

Users browsing this forum: No registered users and 5 guests