Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Hii jartim Why are you commenting a post from 2010. That guy "naim" has probably gone for long, the post above is his first and only since 2010. Best regards Jorge
  3. Hi I think you are guessing right! And in doing so the compiler saves one instruction, as you can see in your openning post the second form (not preserved) is one instruction shorter than the first (preserved). Best regards Jorge
  4. Do you really write your code without any comments or description?!?
  5. Hey Jorge, that could be the answer. The value in Trembler isn't used after the 2nd occurrence and I guess the compiler is free to overwrite its value if it sees it's no longer required.
  6. Hi Are you sure that in the context of the whole program, the value of "trembler @ 0x47" still needs to be preserved for the remaining code after 0x020B ? Best regards Jorge
  7. Hi If code can be generated to compute indexing of arrays, struct fields, ponters and so on, for sure it can also generate code to access a given bit in a byte or word from a variable. My guess is that a piece of generic code to do that would be heavy and ineficient, so they choose to leave it to the programmer, to write optimized code for each use case. Just my 2 cents.... Best regards Jorge
  8. Hi Jorge, That's probably because there is no corresponding instruction at the assembly instruction level, only 'bsf' or 'bcf' with a constant.
  9. Reynard, No, but the ANDWF 0x47, F at address 0x020B does! 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, F 020C 0A47 INCF 0x47, W 020D 00C4 MOVWF WatchdogTarget
  10. Yesterday
  11. Hi jartim, Are you sure INCF 0x47, W modifies the value in Trembler ? Cheers Reynard
  12. Last week
  13. Preprocessor Macros Do Not Work In Mplab-X V4

    Hi If my memory is not tricking me, that "item 2" refered a problem with the Sourceboost IDE and has nothing to do with MPLAB integration. Just my 2 cents... Best regards Jorge
  14. You are correct in your findings. Some of the tdf files are specifying the incorrect program address range. This is a subject that came up a few years ago but who wants to go through all the tdf files to find the errors. Hopefully they will be corrected as they are reported. My main work horses are the 26k22 and 46k22 which appear correctly specified. Cheers Reynard
  15. Preprocessor Macros Do Not Work In Mplab-X V4

    It looks like this problem was originally fixed in V7.10 but has been re-introduced (this is the text from the version log for V7.10) - Mplab x integration 1. Updated MPLAB X plugin to support all SourceBoost compilers. 2. Fixed problem when extra command line arguments were not added to the command line. 3. Added support for include directories to mplabx plugin. Item 2 is the problem being reported here.
  16. Thanks Reynard, but that was my first thought too! (I have been caught before with that one...). If I play with the compiler, I can see some CPUs with values which agree with the data sheets, and others which do not - even though the data sheets are all specifying "Flash (bytes)", not "instructions. Also, some TDF files agree with the associated data sheets (eg 44K22), while the TDF for 66K22 does not agree - so there is some inconsistency worth checking! I have had a situation where the compiler says "all OK, only used just over 50% program memory" while MPLAB wont load the hex file into the CPU properly because its too big.... As an example, my current project uses 66K22: the compiler is saying "ROM available 131072 bytes, ROM used 34774 bytes (26.1%)". But if I look at the program area of the hex file in MPLAB, it has a limit of 0xFFFF (65536 bytes) and has code up to 0x87D6 (which is the 34774 bytes specified by the compiler). Clearly not 26% utilisation..... more like 53%.... compiler is wrong....
  17. Earlier
  18. Check that the data sheets are not specifying number of instructions as one instruction is two bytes. Cheers Reynard
  19. In SourceBoostC ver 730, I have noticed that some 18Fxx'K'yy CPUs are returning the wrong program memory size in the IDE (it is often 2x correct value). Examples: 66K22, 67K22. If I look in the .tdf files for these CPUs, the same "incorrect" values are present as the program memory ranges. The values are 2 x the size shown in the CPU data sheet. This leads to the IDE \ compiler stats being incorrect after a compile (eg, "ROM available:", "used:" and "free:" figures) I have checked a "correct" CPU tdf (eg, 44K22) and the size agrees with the data sheet, and is displayed correctly in the IDE... Am i missing something about the "factor of 2" on these CPUs? Or is this just a plain and simple error? (It has turned up on other CPUs too - I will list as I come across them again...) This may be "old news" now that Chameleon is out, but other users may still be working on 730 and it may be that the error has carried over into the new compiler support files....
  20. Preprocessor Macros Do Not Work In Mplab-X V4

    Found a workaround to this issue - manually define the macro in the "Additional options" field - The output window shows the value gets tagged on to the end of the command line, whereas before it was not being passed to the compiler at all.
  21. Bug description: The same source code line generates different assembly code in different places. Sometimes the generated code is incorrect, sometimes it is correct. Steps to reproduce: Use the same source code in 2 different places in the source. Detailed description to reproduce this problem I use this statement in two different places in my source code - WatchdogTarget = CONST_WDT_MINTIME + (Trembler & 0x07); CONST_WDT_MINTIME is a constant - #define CONST_WDT_MINTIME 1U The first time it is used, the following code is generated (which looks correct) - 01D7 3007 MOVLW 0x7 01D8 0547 ANDWF 0x47, W 01D9 00CA MOVWF 0x4A 01DA 0A4A INCF 0x4A, W 01DB 00C4 MOVWF WatchdogTarget The second time is it used, the following code is generated (which is not correct as it modifies the value in "Trembler" at 0x47) - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, F 020C 0A47 INCF 0x47, W 020D 00C4 MOVWF WatchdogTarget Expected behaviour: This is the code I would expect to see - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, W 020C 0A47 ADDLW 0x01 020D 00C4 MOVWF WatchdogTarget The compiler should not modify the value of "Trembler" at 0x47 (and as the value of CONST_WDT_MINTIME may be other values at compile-time) If CONST_WDT_MINTIME was (say) 32, I would expect to see this instead - 020A 3007 MOVLW 0x7 020B 05C7 ANDWF 0x47, W 020C 0A47 ADDLW 0x20 020D 00C4 MOVWF WatchdogTarget Is the problem 100% reproduceable: Every time IDE version: MPLAB-X 4.0 Compiler: BoostC++ Compiler version: 7.42 Target device: PIC12F635 OS: Windows 7 64-bit
  22. Looks like a bug. Will take a look. Pavel
  23. First time using Chameleon and I'm stuck. enum MY_ENUM {ENUM0, ENUM1, ENUM2}; int myIntArray[ENUM2]; void main() {} Why can't I use an enum value as array size ? Works with BoostC. Cheers Reynard
  24. Update To Test_Bit

    Hi Any special reason to not use the bitwise not operator (~) or does it generate the same code^? Using a logical operator induces the compiler to do a type cast on the result of "test_bit" to a logical type (char or int) before checking its value. In strict 'C' the "!test_bit(...)" expression translates to something like "!(char)test_bit()" or "!(int)test_bit(...)" How about droping the old "test-bit()" and similar macros and using direct bit indexing, If I'm not worng its available since the first release of BoostC 7.xx AFAIK the "test_bit", "set_bit" and "clear_bit" macros have been deprecated several years ago. EDIT ADD: "semantics do matter!" Best reards Jorge
  25. Update To Test_Bit

    Hello - When the compiler generates code for "test_bit(x,y)" it very nicely generates a 'btfss' instruction. However, when it generates code for "!test_bit(x,y)" it generates much more complex code because the ! is a logical operation not a bit-wise operation. It would be nice if the compiler could spot that "!test_bit(x,y)" is really a 'btfsc' instruction instead. Thanks!
  26. I would guess the endian-ness is wrong for the long-integer so when you load the bytes in individually, they're actually going in in the wrong order. The union works because the compiler automatically swaps the bytes around to match the correct endian-ness for the long or float.
  1. Load more activity
×