Jump to content

jartim

EstablishedMember
  • Content count

    39
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jartim

  • Rank
    Regular

Recent Profile Visitors

669 profile views
  1. jartim

    Compiler hangs with in-line assembly

    Hi Pavel You are 100% correct, I was changing the coding from assembler to C and wasn't concentrating! Please disregard my original post. Regards Tim
  2. Bug description: Compiler hangs indefinitely with the following source - Steps to reproduce: This file is "TClass.hpp" - unsigned char ReadFlash(unsigned int FlashAddr) { asm { _tblptru = 0 _tblptrh = _FlashAddr _tblptrl = _FlashAddr+1 tblrd* } return tablat; } Expected behaviour: This should compile with no errors Is the problem 100% reproduceable: 100% every time IDE version: MPLAB-X V4.20 Compiler: BoostC++ Compiler version: V7.43 Target device: PIC18F8527 OS: Win 7 Comments: Compiles if the three lines relating to _tblptrx are commented out.
  3. Hi Jorge No, not yet, I will do this today. I assumed that the forum was the first place to go to report an issue? Regards Tim
  4. Bug description: Compiler generates incorrect code from mixed C++ and inline assembler - Steps to reproduce: The following is a sample section of code that generates the wrong address for _TestTemp+1 - void CPUTest() { unsigned char TestTemp[3]; asm { CPUTest_9: movlw 0xff ; set up locations ready to change movwf _TestTemp movwf _TestTemp+1 movwf _TestTemp+2 lfsr 0, _TestTemp+1 ; set up a pointer movlw 0x55 movwf _postdec0 } } Expected behaviour: In my application TestTemp[0] is located at 0x5C2, TestTemp[1] and [2] are at 0x5C3 and 0x5C4 respectively. The compiler should load fsr0 with the value 0x5C3 (_TestTemp+1), however the final generated code loads the value 0x5C2 instead. Is the problem 100% reproducible: 100% happens every time IDE version: MPLAB-X V4.20 Compiler: BoostC++ Compiler version: V7.43 Target device: PIC18F8527 OS: Win7 Comments:
  5. jartim

    Incorrect code generated

    Thanks Pavel. Unfortunately the Chameleon compiler does not support C++ (does it?) Regards Tim
  6. jartim

    Incorrect code generated

    Bug description: The compiler generates incorrect code for the following statement - while (c -= 1) Steps to reproduce: My source code is this - #define BSIZE 120 unsigned char RxBuffer[BSIZE]@0x100; unsigned char TxBuffer[BSIZE]@0x200; unsigned char RamSwapArea[16U]@0x300; void main() { asm lfsr 1, _RxBuffer asm lfsr 2, _TxBuffer unsigned char c = BSIZE; while (c -= 1) { asm movff _postinc1, _postinc2 } } The bug is the statement "while (c -= 1)" generates an INFSNZ instruction, even though variable c is being decremented. Here is the disassembly listing - 13: #define BSIZE 120 14: unsigned char RxBuffer[BSIZE]@0x100; 15: unsigned char TxBuffer[BSIZE]@0x200; 16: unsigned char RamSwapArea[16U]@0x300; 17: 18: void main() 19: { 20: asm lfsr 1, _RxBuffer 0008 EE11 LFSR 1, 0x100 000A F000 NOP 21: asm lfsr 2, _TxBuffer 000C EE22 LFSR 2, 0x200 000E F000 NOP 22: 23: unsigned char c = BSIZE; 0010 0E78 MOVLW 0x78 0012 6E01 MOVWF c, ACCESS 24: while (c -= 1U) 0014 4A01 INFSNZ c, F, ACCESS 001C D7FB BRA 0x14 25: { 26: asm movff _postinc1, _postinc2 0018 CFE6 MOVFF POSTINC1, POSTINC2 001A FFDE NOP 27: } 28: } 0016 0012 RETURN 0 Expected behaviour: The instruction at address 0014 should be 'DCFSNZ c, F, ACCESS Is the problem 100% reproduceable: 100% every time IDE version: MPLAB-X 4.15 (64-bit) Compiler: BoostC++ Optimizing C++ Compiler Version 7.43 (for PIC18 architecture) Compiler version: V7.43 Target device: PIC18F8527 OS: Windows 10 Pro 64-bit Comments: Have included the source files - main.cpp
  7. Thanks Pavel, that was the problem. Cannot believe I missed it, it was a long day. Rgds Tim
  8. Hi, Does anyone have any insight into how to access a function parameter from in-line assembler? I am doing the following - void type24Var::add(const unsigned long src) { asm { movf _src, W } } But this will not compile and I get the message - failure type24Var.cpp(68:2): error: error in built-in assembly make[2]: [build/default/production/type24Var.o] Error 1 (ignored) It's driving me crazy, nothing I do seems to clear the error!
  9. jartim

    Unrecognised type ID

    Hi guys, I'm getting this message when I build my project - Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F Coff generation: Internal Warning: Member Var:currentCrcRomPtr Unrecognised type id:0xF000000F It doesn't appear to be causing any issues, however the compiler reports a warning so I expect there is something odd going on. Any ideas? (Compiler = BoostC++ V7.42) Regards Tim Jarrett
  10. Thanks Jorge, pretty much what I had decided to do as well. It just would be easier to have the compiler and linker do all the work for me, rather than have to build the code twice. Regards Tim
  11. Hi Jorge All I'm trying to do is calculate a CRC checksum for the ROM, starting at 0x0000 and ending at the last used address of my program, hence I need to know the last address used. I can't CRC the entire ROM because I will be using the top end for non-volatile storage, and for that I also need to know the last used address. Normally I would edit the linker control file and add a label after the used code section, but this compiler doesn't appear to use a control file, I guess it has the parameters hard-coded in. All I can do at the moment is build the code with a 0x0000 address coded in as a rom char* pair, look at the code statistics after the build process, copy the size of the code in to the rom char* and then re-build. It would be safer and easier to have the compiler and linker do it automatically. Regards Tim
  12. Hi guys, Is there any easy way of identifying the last used address in rom using BoostC or BoostC++ compilers? I cannot find a linker control file to add a label, is there any way to guarantee that a label defined in the source code ends up as the last addressed object? Thanks Tim
  13. Another request, not much luck with enhancements so far but worth a punt... Please can you add support for friend functions for classes? Thanks.
  14. A long shot I know, but what are the chances of the source code being moved to an open-source licence? That way maybe there could be more third-party improvements and bug fixes etc. Just a thought. (I would certainly be interested in adding new features, i.e. 12-bit support, true template support, overloaded constructor support etc.) Regards Tim
  15. Please can you add support for the 12-bit baseline devices to BoostC and BoostC++? Some of these have relatively large FLASH and register memories but have a 12-bit instruction-width core, which the current compiler doesn't support! Regards Tim Jarrett
×