Wrong generated code regarding GNURL78 far pointer access (code – 2022/09/14, 2022/09/15)
Wrong generated code regarding GNURL78 far pointer access (code – 2022/09/14, 2022/09/15)
Hello support team,
I found wrong generated codes regarding GNURL78 far pointer access: missing `es:` prefix for movw ax, [hl]. More information and zip files including all files for e2 studio 2022-07 and GNURL78 4.9.2.202201 are posted in the following Renesas’ Japanese user forum URLs.
CASE-20220914:
uint16_t _RomSum(void)
{
uint32_t prom, sum_s, sum_e;
uint16_t sum = 0;
sum_s = 0;
sum_e = 0x017DFEUL;
for( prom = sum_s; prom < sum_e; prom += 2 )
{
sum += *(uint16_t __far *)prom; <– HERE
}
return sum;
}
CASE-20220915:
uint16_t _RomSum(void)
{
// FIXME: If one of -O2, -O3, -Os is used, the generated code calls `abort()` immediately.
// FIXME: In case of using the immediate value in stead of `&psum_rom`, if other than -O0, -Og is
// used, the generated code has no ES register handling. (Note: If one of -O2, -O3, -Os is used,
// the generated code calls `abort()` immediately. Therefore `other than -O0, -Og` means only -O1.)
const uint16_t __far *prom, *sum_s, *sum_e;
uint16_t sum = 0;
sum_s = 0;
//sum_e = &psum_rom; // (const uint16_t __far *)0x017DFEUL; –> No ES register handling.
sum_e = (const uint16_t __far *)0x017DFEUL;
for( prom = sum_s; prom < sum_e; prom++ )
{
sum += *prom; <– HERE
}
return sum;
}
Generated code (for both cases):
…
movw ax, [hl]
…
Expected code (for both cases):
…
mov es, a
…
movw ax, es:[hl]
…
Renesas’ Japanese user forum URLs:
https://community-ja.renesas.com/cafe_rene/forums-groups/tools/f/forum21/9541/gnurl78-llvm-rl78-over-64kb-rom-checksum-code/46639#46639
GNURL78_far_pointer_issue_20220914.zip
https://community-ja.renesas.com/cafe_rene/forums-groups/tools/f/forum21/9541/gnurl78-llvm-rl78-over-64kb-rom-checksum-code/46652#46652
GNURL78_far_pointer_issue_20220915.zip
Best regards,
NoMaY
Hello,
I encountered the same problem in the startup code(crtbegin.o and crtend.o).
The instruction which refers to __CTOR_LIST__[0] in the _do_global_ctors_aux function lacks “ES:” and reads data from a different address.
Here is a part of the disassembled code of my executable file.
00002006 <___CTOR_LIST__>:
2006: ff brk1
2007: ff brk1
00002356 <___do_global_ctors_aux>:
2356: 61 ef sel rb2
2358: c1 push ax
2359: 61 cf sel rb0
235b: af 06 20 movw ax, !f2006 <__rl78_fini_end+0xefc65>
235e: bd f0 movw r8, ax
2360: 44 ff ff cmpw ax, #0xffff
2363: 61 f8 sknz
2365: ec 83 23 00 br !!2383 <.L1>
2369: c9 e8 06 20 movw r16, #0x2006
The instruction at 0x0235b is a read from __CTOR_LIST__[0] but it reads data from 0xF2006 which is different address than that of __CTOR_LIST__[0] (0x02006) because it is “movw ax, !addr16” style.
I think the instruction at 0x0235b must be “movw ax, es:!addr16” style.
To generate the above code, I don’t use any option except -o like bellow and I’m using GCC for Renesas 4.9.2.202201-GNURL78.
rl78-elf-gcc myprogram.c -o myprogram
Thank you.
Hello,
Thank you for reporting the issue.
We managed to reproduce it and can confirm that it is indeed a software bug. We raised an internal ticket for it, however the release date of the fix is uncertain at this point.
We apologize for any inconvenience caused.
__
Best regards,
The Open Source Tools Team
Hello support team,
Thank you for the reply.
It is good to hear that the issue is planned to be fixed.
Best regards,
NoMaY