Jump to content

Dr. John

EstablishedMember
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Dr. John

  • Rank
    Newbrie
  1. Jorge and Reynard, Great stuff! Jorge, you are right. The only way that the compiler will deliver the correct results is if you declare the array as a string. I think that this is a bug, but there is a reasonable workaround and I'd really like to use this compiler since the Hi Tech compiler seems to create more than double the number of instructions (and at least double the amount of execution time) to accomplish the same thing. Reynard, you confirm Jorge's understanding and your comments were necessary for me to catch Jorge's initial comment to DELETE the brackets. I had tried to compile with the brackets in place, but empty, and got the same results as previously. This raises the following question to a couple of guys who seem to have a fair amount of experience with SourceBoost's products: What is your experience of the responsiveness of Dave and Pavel to issues such as these? I see that they monitor the board and provide initial feedback fairly quickly, but if there are issues that need fixing, are they responsive? What have been your experiences? Thanks again for your help. Dr. John
  2. Hi Reynard, Thanks for your input. What you said makes a lot of sense to me. However, what ACTUALLY happens is different. I get the following: 00000020:00000060 gbl_LCD_segment_config LCD_segment_config This is the problem that needs to be resolved. This result is completely independent of the presence/absence of the asterisk and its location (within the range of options presented here). Meanwhile, as I said before, the table is correctly created in ROM and the code to access it is as well. So, it seems like the compiler understands half of the issue, but not the other half. I'm hopeful that this will be eventually realized as a real bug and not a user error. Dr. John
  3. Gentlemen, Again, thanks for your attention to this. I have tried all three variations of the source code and receive identical results in the assembly code generated as well as the map file generated by the linker. The generated assembly code correctly puts the table in ROM, and correctly accesses it. However, in addition, it incorrectly allocates space for the table in RAM, which incorrect allocation follows through into the map file generated by the linker. Hence, were I to put a couple of larger tables (which is indeed my intent) in ROM, the result would be that I would have zero RAM available for anything else, even though it isn't being used. I'm hoping that you will address this issue since it is the main issue of this post and the main issue for me to have resolved prior to making a license purchase. Regards, Dr. John
  4. Pavel, Thanks for your rapid reply. Well, the form of the declaration matches exactly that shown in the BoostC manual, as shown on page 45. Originally I had declared the array without the pointer (i.e., rom char LCD_segment_config[12] = // LCD segments setting table // if 1, then pixel is enabled { // GFEDCBA 0b00111111, // for displaying '0' 0b00000110, // for displaying '1' 0b01011011, // for displaying '2' 0b01001111, // for displaying '3' 0b01100110, // for displaying '4' 0b01101101, // for displaying '5' 0b01111101, // for displaying '6' 0b00000111, // for displaying '7' 0b01111111, // for displaying '8' 0b01101111, // for displaying '9' 0b01111001, // for displaying 'E' 0b00000000 // for displaying ' ' }; In any case, the form of declaring the array doesn't seem to make any difference. In both cases, the compiler buys the declaration and seems to do the same thing, i.e., create code that will correctly access the table (which is created correctly in ROM), but also allocate the space that would be used by the array in RAM and thereby rob this space. I still think that this is a real bug. Also, some clarification of the correct/preferred way of declaring the array would be appreciated. I, like you, think that declaring it as per my original message is equivalent to declaring an array of pointers, but the manual speaks differently. Worse, (or better?), the compiler doesn't seem to distinguish between the two. Thanks again for your hep. Dr. John
  5. I have been reviewing BoostC in preparation for purchasing a Pro license in support of a project. While in general I like what I see, there is a bug that will prevent me from the purchase if it isn't fixed. The bug is that when declaring an array in ROM, space for same array is allocated in RAM even though it isn't used, thereby removing the availability of this RAM. Here is an example. rom char *LCD_segment_config[12] = // LCD segments setting table // if bit = 1, then pixel is enabled { // GFEDCBA 0b00111111, // for displaying '0' 0b00000110, // for displaying '1' 0b01011011, // for displaying '2' 0b01001111, // for displaying '3' 0b01100110, // for displaying '4' 0b01101101, // for displaying '5' 0b01111101, // for displaying '6' 0b00000111, // for displaying '7' 0b01111111, // for displaying '8' 0b01101111, // for displaying '9' 0b01111001, // for displaying 'E' 0b00000000 // for displaying ' ' }; The code generated will correctly access this table. However, if one looks at the memory map you can see the following. Register usage ============== Address Bit Lengh Bit Mask Unique Name Name ------- --------- -------- ----------- ---- 00000000:00000008 gbl_indf0 indf0 00000001:00000008 gbl_indf1 indf1 00000002:00000008 gbl_pcl pcl 00000003:00000008 gbl_status status 00000004:00000008 gbl_fsr0l fsr0l 00000005:00000008 gbl_fsr0h fsr0h 00000006:00000008 gbl_fsr1l fsr1l 00000007:00000008 gbl_fsr1h fsr1h 00000008:00000008 gbl_bsr bsr 00000009:00000008 gbl_wreg wreg 0000000A:00000008 gbl_pclath pclath 0000000B:00000008 gbl_intcon intcon 0000000C:00000008 gbl_porta porta 0000000D:00000008 gbl_portb portb 0000000E:00000008 gbl_portc portc 0000000F:00000008 gbl_portd portd 00000010:00000008 gbl_porte porte 00000011:00000008 gbl_pir1 pir1 00000012:00000008 gbl_pir2 pir2 00000013:00000008 gbl_pir3 pir3 00000014:00000008 gbl_pir4 pir4 00000015:00000008 gbl_tmr0 tmr0 00000016:00000008 gbl_tmr1l tmr1l 00000017:00000008 gbl_tmr1h tmr1h 00000018:00000008 gbl_t1con t1con 00000019:00000008 gbl_t1gcon t1gcon 0000001A:00000008 gbl_tmr2 tmr2 0000001B:00000008 gbl_pr2 pr2 0000001C:00000008 gbl_t2con t2con 00000020:00000060 gbl_LCD_segment_config LCD_segment_config 0000002C:00000010 gbl_xxxxxxxxxxx xxxxxxxxxxx The assembly code also contains this allocation. In fact, when first trying to compile and link code that I had written for the Hi Tech compiler, it wouldn't link, even though I was sure I was within the Lite license limitations. This was apparently because I had also included two additional larger tables that resulted in a RAM allocation more than sufficient to violate the Lite license limitations. I am not sure if this happens every time, but I consistently had the problem of violating the Lite license limitations until I started out with essentially a one line do-while loop in the main routine, adding a bit of code at at time until I found this. I expect that it is 100% reproducible. The expected behavior is for the tables to be allocated in ROM, but not be allocated in RAM since no reference to RAM is required for reading elements of the table. I am using the BoostC Optimizing C Compiler Version 7.05 (for PIC16 architecture) and corresponding linker. I appreciate the effort you guys are putting forth to make this compiler available and robust. Dr. John
×
×
  • Create New...