Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Pavel

  1. If code uses */% operations it needs to link with libc library. When building from SourceBoost IDE this is done automatically. Otherwise you need to link with libc library using other means. (For libc library look into the 'lib' subdirectory in your SourceBoost installation directory). Regards, Pavel
  2. Pavel

    Compiler Error?

    Another workaround is to cast pointers to unsigned short: while ((unsigned short)EP0_start < (unsigned short)EP0_end) { ... } Regards, Pavel
  3. Pavel

    Compiler Error?

    Hmmm I see now but I still don't recommend this practice even when this bug is fixed. Pointers are 2 bytes long and operations on such variables generates much more code than if 1 byte vars are used. If buffer is less than 256 bytes long a simple for loop with char counter will work more efficient: char i; for( i = 0; i < BUFLEN; i++ ) { ... } Regards, Pavel
  4. Pavel

    Compiler Error?

    Yes this looks like an error but this kind of comparisson is probably never used in the code (at least I never ever used something like this). I'm curious when you need to compare pointers? Regards, Pavel
  5. If you see this problem happening again please zip the whole project and send it to me. I want to reproduce it and see what's happening inside compiler. Regards, Pavel
  6. Yes this is an error and it has been already reported for 1.6 release. The workaround is not to use 'else' if this is end of a function like: ... if (i == 0) // this doesn't { return 1; } return 0; /* Buffer not available, return false */ } This error has been fixed and fix will be available in 1.7 release. Regards, Pavel
  7. Fixed. Fix will be available in 1.7 release. Regards, Pavel
  8. I tried to reproduce the problem using your code from the first post (though I had to reverse function order) but everything works fine here. String is being copied as expected. Regards, Pavel
  9. This bug has been fixed. Took a while to sort it out but now compiler fully supports static locals. Fix will be available in BoostC 1.7 release (or update). Regards, Pavel
  10. Actually manual may be not completly correct here. While there is no technical limit for the number of array dimensions in compiler COFF file format may have limit on it. Regards, Pavel
  11. This probably will never happen. The reason is that for PIC16 a contiguous array in several banks can't exist. There will be hardware mapped register in between and this will make code that delas with array indexing several times longer and complex. Regards, Pavel
  12. This array is from global scope and optimizing out variables from there is a bit trickier than from functions. This work is in our todo list. Regards, Pavel
  13. This is not an error. It is stated in BoostC help that an array must fit in register bank. Regards, Pavel
  14. For */% operation compiler uses special functions from libc library. These functions are declared in boostc.h that in turn is included into system.h Regards, Pavel
  15. Fixed. Fix will be available in 1.7 release (or update). Regards, Pavel
  16. This one has been fixed. Fix will be available in 1.7 release (or update). Regards, Pavel
  17. This is not a bug. You need to include system.h Without this header code that uses */% operations won't compile. Regards, Pavel
  18. Yes this error was already reported in this forum. A workaround is to write code like: char badReturn(int good, int evil) { if (good < evil) { return 666; } return 1; } Regards, Pavel
  19. Maybe this happened because I moved your topic from general to bug report forum and at the same time deleted same topic from bug report forum. So far forum worked ok for me. Regards, Pavel
  20. Yep seems to be a bug. Thanks for reporting. Regards, Pavel
  21. Thanks for the explanations. We'll try to add this feature into the next BoostC update. Regards, Pavel
  22. Tha latest SourceBoost 5.7 release reads the list of supported targets from map.txt file that is in the config directory. Now adding support for a new targed for BoostC toolsuit is a matter of adding a configuration file (.TDF) for such target and adding it to map.txt (of course target must be either 14 or 16 bit core). Regards, Pavel
  23. Oops this one was forgotten. Though it has a very simple workaround. Instead of: char bin_to_bcd_high (char bin) { if (bin > 199) return 2; else if (bin > 99) return 1; else return 0; #ifdef _BOOSTC return 0; // todo: boostc bug reported, remove when fixed #endif } use: char bin_to_bcd_high (char bin) { if (bin > 199) return 2; else if (bin > 99) return 1; return 0; } Regards, Pavel
  24. We need to investigate this issue. Currently BoostC expects a label as argument of the call instruction. What is located on address used in "call 3ffh"? How other compilers deal with such calibrating? Regards, Pavel
  25. The IDE does not expire. The assembler or picc-lite toolsuits do not expire either. So if you work with assembly under SourceBoost IDE you don't need to worry about ant trial periods or limitations. There just aren't any Wow this sounds very cool. Do you use C2C or BoostC? If you are willing to share this project we'll be happy to publish it on the comiler web site. Regards, Pavel
  • Create New...