日本語
Interrupt routine trashes registers (GCC for Renesas RX)
Interrupt routine trashes registers (GCC for Renesas RX)
When reserving register for speed these sometime gets trashed…
CMAKE_C_FLAGS ” -mint-register=2″
CMAKE_C_FLAGS ” -msmall-data-limit=512″
The isr looks like:
ServiceFastRXI1:
0000009b: pushm r1-r5
0000009d: mov.l #0x6500, r4
000000a3: mov.l [r4], r2
000000a5: mov.b 40997[r13], r1
000000a9: mov.l #0x6300, r3
000000af: mov.l 7360[r11], r11
000000b3: mov.w [r11], [r3]
000000b5: add #4, r2, r3
000000b8: mov.b r1, [r2]
000000ba: bclr #8, r3
000000bc: mov.l r3, [r4]
000000be: bset #4, 29206[r13].b
000000c2: popm r1-r5
000000c4: rtfi
r11 is used as gp gets overwritten.
The same can happen with r10 I’ve noted…
Bug or feature?
/Henrik
Hello,
Thank you for reaching out to us!
According to the GCC documentation, the description of the -mint-register option is as follows:
-mint-register=N Specify the number of registers to reserve for fast interrupt handler functions. The value N can be between 0 and 4. A value of 1 means that register r13 is reserved for the exclusive use of fast interrupt handlers. A value of 2 reserves r13 and r12. A value of 3 reserves r13, r12 and r11, and a value of 4 reserves r13 through r10. A value of 0, the default, does not reserve any registers.
Based on this, when using -mint-register=2, the compiler reserves only r13 and r12. Using -mint-register=3 should result in the desired behavior.
There is a known bug affecting -mint-register=4, which results in r10 not being reserved. This will be resolved in the next release.
Please let us know if we can be of further assistance.
__
Best regards,
The Open Source Tools Team
-
Hi, thank you for your reply = )
Yes, indeed I’ve read the manual and set aside r13 and r12. Further more, I’ve recognized r10 will be used by the compiler regardless your demands on r13 thru r10 (it’s used as a stack frame pointer?).
The problem resides in the manual page 365:
Quote – – –
The actual register chosen to hold the constant data base address depends upon
whether the ‘-msmall-data-limit’ and/or the ‘-mint-register’ commandline
options are enabled. Starting with register r13 and proceeding downwards,
registers are allocated first to satisfy the requirements of ‘-mint-register’,
then ‘-mpid’ and finally ‘-msmall-data-limit’. Thus it is possible for the
small data area register to be r8 if both ‘-mint-register=4’ and ‘-mpid’ are
specified on the command line.
By default this feature is not enabled. The default can be restored via the
‘-mno-pid’ command-line option.
– – – End quoteBy this statement I shuld get (-mno-pid):
r13 as global reserved register not used by gcc.
r12 as above
r11 as small data pointer (_gp) featured by gcc.Would you not agree?
-
Hello,
We agree, when using -mint-register=2 -msmall-data-limit=512, r13 and r12 should be reserved and r11 should be used as small data pointer.
In order to track down the source of this possible bug, could you please provide a minimal reproducible example and the version of the GCC RX toolchain used?
__
Best regards,
The Open Source Tools Team -
That was easy = )
I created a new project
“GCC for Renesas RX C/C++ Executable Project”
(RX231 custom target).Added “-mint-register=2 -msmall-data-limit=512” at
Properties/C/C++ Build/Settings/Compiler/Command
(rx-elf-gcc -mint-register=2 -msmall-data-limit=512)Added _gp to the linker script in .data section:
.data : AT(_mdata)
{
__gp = .;
_data = .;
*(.data)
*(.data.*)
*(D)
*(D_1)
*(D_2)
_edata = .;
} > RAMWrote a simple main and fast interrupt:
// start code
unsigned char Buffer[32];
unsigned char* pHead;
unsigned char* pTail;
volatile unsigned char Data;void ServiceFastRXI1(void) __attribute__ ((fast_interrupt,optimize(“-O2”)));
void ServiceFastRXI1(void)
{
*pHead++ = SCI1.RDR;
*pTail++ = Data++;
if(&Buffer[32] == pHead)
{
pTail = pHead = &Buffer[0];
}
ICU.IER[15].BIT.IEN6 = 1;
return;
}void main(void)
{
int i;
pTail = pHead = &Buffer[0];
i = (int)&ServiceFastRXI1;
return;
}
// end codeThe compiled interrupt becomes:
19:../src/MTX.c **** void ServiceFastRXI1(void) __attribute__ ((fast_interrupt,optimize(“-O2”)));
20:../src/MTX.c **** void ServiceFastRXI1(void)
21:../src/MTX.c **** {
9 .loc 1 21 1 view -0
10 ; Note: Fast Interrupt Handler
11 0000 6E 15 pushm r1-r5
12 .LCFI0:
22:../src/MTX.c **** *pHead++ = SCI1.RDR;
13 .loc 1 22 2 view .LVU1
14 .loc 1 22 8 is_stmt 0 view .LVU2
15 0002 FB 52 00 00 00 00 mov.L #_pHead, r5
16 0008 EC 53 mov.L [r5], r3
23:../src/MTX.c **** *pTail++ = Data++;
17 .loc 1 23 17 view .LVU3
18 000a FB 12 00 00 00 00 mov.L #_Data, r1
19 .loc 1 23 8 view .LVU4
20 0010 FB 42 00 00 00 00 mov.L #_pTail, r4
22:../src/MTX.c **** *pHead++ = SCI1.RDR;
21 .loc 1 22 8 view .LVU5
22 0016 71 32 01 add #1, r3, r2
23 0019 E3 52 mov.L r2, [r5]
22:../src/MTX.c **** *pHead++ = SCI1.RDR;
24 .loc 1 22 17 view .LVU6
25 001b FB 2E 20 A0 08 mov.L #0x8a020, r2
26 0020 89 2A mov.B 5[r2], r2
22:../src/MTX.c **** *pHead++ = SCI1.RDR;
27 .loc 1 22 11 view .LVU7
28 0022 C3 32 mov.B r2, [r3]
29 .loc 1 23 2 is_stmt 1 view .LVU8
30 .loc 1 23 17 is_stmt 0 view .LVU9
31 0024 CC 12 mov.B [r1], r2
32 .loc 1 23 8 view .LVU10
33 0026 EC 43 mov.L [r4], r3
34 .loc 1 23 17 view .LVU11
35 0028 71 2C 01 add #1, r2, r12
36 .loc 1 23 8 view .LVU12
37 002b 71 3B 01 add #1, r3, r11
38 .loc 1 23 17 view .LVU13
39 002e C3 1C mov.B r12, [r1]
40 .loc 1 23 8 view .LVU14
41 0030 E3 4B mov.L r11, [r4]
42 .loc 1 23 11 view .LVU15
43 0032 C3 32 mov.B r2, [r3]
24:../src/MTX.c **** if(&Buffer[32] == pHead)
44 .loc 1 24 2 is_stmt 1 view .LVU16
45 .loc 1 24 4 is_stmt 0 view .LVU17
46 0034 EC 53 mov.L [r5], r3
47 0036 74 03 00 00 00 00 cmp #_Buffer+32, r3
48 003c 20 15 beq .L5
25:../src/MTX.c **** {
26:../src/MTX.c **** pTail = pHead = &Buffer[0];
27:../src/MTX.c **** }
28:../src/MTX.c **** ICU.IER[15].BIT.IEN6 = 1;
49 .loc 1 28 2 is_stmt 1 view .LVU18
50 .loc 1 28 23 is_stmt 0 view .LVU19
51 003e FB 5E 00 70 08 mov.L #0x87000, r5
52 0043 CE 54 0F 02 mov.B 527[r5], r4
53 0047 78 64 bset #6, r4
54 0049 CB 54 0F 02 mov.B r4, 527[r5]
29:../src/MTX.c **** return;
55 .loc 1 29 2 is_stmt 1 view .LVU20
30:../src/MTX.c **** }
56 .loc 1 30 1 is_stmt 0 view .LVU21
57 004d 6F 15 popm r1-r5
58 004f 7F 94 rtfiNote that this trashes both r11 and r12…
/Henrik -
Hello,
Thank you, we can confirm that this is a bug.
We have raised an internal ticket, a fix is likely to be
included in the next release.__
Best regards,
The Open Source Tools Team -
I reckon the fix have been postponed and not included in the 8.3.0.202405 version.
This one trashes r12/r13 instead but other than that, identical result.
Good that documentation reflects the register limitation for this specific optimization.
Cheers
/Henrik -
Hello,
A fix was included regarding this issue in the GCC for Renesas RX 8.3.0.202405 release.
When using -mint-register=2 -msmall-data-limit=512, RX 8.3.0.202405 produces the following instructions:
Source code:
#include “iodefines.h”
unsigned char Buffer[32];
unsigned char* pHead;
unsigned char* pTail;
volatile unsigned char Data;void ServiceFastRXI1(void) __attribute__ ((fast_interrupt,optimize(“-O2”)));
void ServiceFastRXI1(void)
{
*pHead++ = SCI1.RDR;
*pTail++ = Data++;
if(&Buffer[32] == pHead)
{
pTail = pHead = &Buffer[0];
}
ICU.IER[15].BIT.IEN6 = 1;
return;
}void main(void)
{
int i;
pTail = pHead = &Buffer[0];
i = (int)&ServiceFastRXI1;
return;
}Compiled output:
.file “test.c”
.section P,”ax”
.comm _Buffer,32,1
.comm _pHead,4,4
.comm _pTail,4,4
.comm _Data,1,1
.global _ServiceFastRXI1
.type _ServiceFastRXI1, @function_ServiceFastRXI1:
; Note: Fast Interrupt Handler
pushm r1-r5
mov.L #_pHead, r5
mov.L [r5], r3
mov.L #_Data, r1
mov.L #_pTail, r4
add #1, r3, r2
mov.L r2, [r5]
mov.L #0x8a020, r2
mov.B 5[r2], r2
mov.B r2, [r3]
mov.B [r1], r2
mov.L [r4], r3
add #1, r2, r13
add #1, r3, r12
mov.B r13, [r1]
mov.L r12, [r4]
mov.B r2, [r3]
mov.L [r5], r3
cmp #_Buffer+32, r3
beq .L5
mov.L #0x87000, r5
bset #6, 527[r5].B
popm r1-r5
rtfi.L5:
mov.L #_Buffer, [r5]
mov.L #_Buffer, [r4]
mov.L #0x87000, r5
bset #6, 527[r5].B
popm r1-r5
rtfi
.size _ServiceFastRXI1, .-_ServiceFastRXI1
.global _main
.type _main, @function_main:
push.l r10
add #-4, r0, r10
mov.L r10, r0
mov.L #_pHead, r5
mov.L #_Buffer, [r5]
mov.L #_pHead, r5
mov.L [r5], r4
mov.L #_pTail, r5
mov.L r4, [r5]
mov.L #_ServiceFastRXI1, [r10]
nop
rtsd #8, r10-r10
.size _main, .-_main
.ident “GCC: (GCC_Build_8c9e6e87e) 8.3.0.202405-GNURX 20190222”Due to mint-registers being set to 2, GCC is free to use/allocate/trash r13 and r12 in the fast interrupt function, without saving and restoring them.
Due to msmall-data-limit > 0, GCC will not allocate r11 anywhere.
If you encountered a different behavior, please let us know.
Best regards,
The Open Source Tools Team -
Hello again : )
Yes, I get the same result.
Now I realize I’ve not fully understand the purpose of the -mint-register.
I read the manual as this option reserves registers from the compiler but free to use, where time is critical.
As you could optimize speed using registers as buffer pointers, reducing register save/restore and initialize, but as the compiler trashes them, this use is void.
With this said, the benefit for this option is not that great I once thought, I will keep these dirty __asm__.
Thanks for the great work = )
/Henrik -
Hello,
Indeed, these options are useful when developers write the time critical functions in assembly, having the assurance that the reserved registers won’t be allocated in other parts of the application. Avoiding fast_interrupt functions written in C, either by using normal interrupts or by writing them in assembly, should keep the mint-registers unmodified.
Please let us know if we can be of further assistance.
__
Best regards,
The Open Source Tools Team
Side noted:
The core in use RX23E/RX231.
Optimization level -O2
Toolchain 8.3.0.202104 but no change with newer ones.