#1664 Bad code silently generated when mixing RAM/ROM storage

closed-duplicate
None
5
2010-09-23
2010-07-31
No

The attached file a.c is compiled with this command and output:
$ sdcc -mpic16 -ppic18f4550 a.c
message: using default linker script "/usr/share/gputils/lkr/18f4550.lkr"
to produce the file a.asm. Here's the problem: the variable "foo_impl" is stored in ROM (due to its const qualifier), while the variable "foos" is stored in RAM (due the variable itself *not* actually being const qualified). The implementation of call_fptr() unfortunately first does a multiply and some adds to point FSR0 at foos[idx], then loads two bytes from that location and uses those two bytes to reload FSR0! This is wrong: since the referent of the pointer stored in foos[idx] is in ROM, one needs to instead read three bytes from foos[idx] and load them into TBLPTR and then use TBLRD.

Splitting up the code into two statements, the first loading foos[idx] into a local variable fooptr of type [const foo_t *] and the second going through that pointer to get to fooptr(), works correctly as it then uses the generic pointer functions as it seems the compiler no longer "knows" what fooptr is pointing at.

$ sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.8.0 #5117 (Feb 21 2010) (UNIX)

Discussion

  • Christopher Head

    The input source code

     
  • Christopher Head

    The assembly output

     
  • Maarten Brock

    Maarten Brock - 2010-07-31
    • labels: --> 608414
     
  • Philipp Klaus Krause

    You're using sdcc 2.8.0 #5117, which is ancient (over two and a half years old). I just tried in sdcc 2.9.7 #5983 and could not reproduce the bug. I remember some bug like this having been fixed long ago, and it wasn't pic16-specific.

    We released 2.9.0 in early 2009. 3.0.0 is to be released in october. You might want to try current sdcc.

    Philipp

    P.S.: I suppose you're using Debian stable, 2.8.0 is the sdcc version in lenny. 2.9.0 is in current Debian testing.

     
  • Philipp Klaus Krause

    • labels: 608414 -->
    • status: open --> closed-duplicate
     
  • Philipp Klaus Krause

    • assigned_to: nobody --> spth
     
  • Christopher Head

    Yes, this is fixed in snapshot 6026, thanks. Looking forward to v3!

    P.S.: I've never used Debian; I use Gentoo, which only got 2.9.0 rather recently due to bug 3038644 (patches / "Fix for GCC-4.4 compile error") preventing SDCC from building and due to people being confused and thinking that the missing libcmd was a system library, when it's actually part of SDCC.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks