Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by ppulle

  1. My two bits as well....Sourceboost is a great compiler and affordable. All our bug reports and suggestions are us trying to help you guys out and the quick responses and actions on suggestions are quickly taken as well. More than once have you guys taken on board a request and it's appeared in the next release. Very few commercial compiler makers would give the users this sort of hands on support....thanks guys.


  2. Yep I understand that generally you would have to use the highest bit number maths to take into account these possibilities.

    What I was wondering was if this could be turned on/off by option or a pragma and that the user would be responsible for any code fragments that they may write, and generate smaller code if they wanted to. In the example below 16 bit code could be generated regardless:



    #pragma USE_16_BIT_MATHS //generate a compiler warning to check code

    short nBig = X * 1000 / Y; //uses 16bit maths...it's OK, I've checked my operands!

    ....and other code in my highly optimised routine


    short nNormal = X * 1000 / Y; //uses default 32 bit maths


    Probably not very 'C' standard...but would be handy in a microcontroller focussed compiler so we can make code as small as possible. Any example would be using 16bit maths when playing around with timer registers.




    You are right... partially :) Regardless of optimization:


    long nBig = X * 1000;  // uses 32 bit code

    short nBig = X * 1000;  // uses 16 bit code


    But the original code was a bit different. Something like this:


    short nBig = X * 1000 / Y;


    can't use 16 bit code in multiplication or the result may be incorrect. For this particular expression 32 bit multiplication is used and produces 32 bit long temporary result that is than devided by Y.




  3. Sorry....I might not have read the explanation properly.


    I was thinking that the optimisation switch would force the compiler to use 32 or 16bit (or 8bit etc) maths in all the operations based on the result. So if you define

    unsigned long nBig;

    unsigned short nSmall;


    Then (if option enabled)

    nBig = X * 1000; // would use 32 bit code

    nSmall = X * 1000; // would use 16bit code

    It would be up to the user to ensure their code wouldn't do something silly eg set X=80 when calculating nSmall....of course a warning similiar to those already in place should be issued.



  4. Thanks for the feedback Pavel, it really helps us users to understand what's going on...and helps diagnose problems when we're pushing the compiler to the limit. Much appreciated and one of the reasons I like SourceBoost so much.


    I don't suppose a later release could have a switch to detect these 32 v 16 bit situations and generate appropriate code based on the data size of the result variable?



  5. A minor correction to the above. I was going from v6.03 -> v6.11 not 6.0 as previously stated.


    The uninstall went with no problems, plus I managed to get an accurate figure on the compile size. On a 16F88 target, optimisation -O1, with v6.03 I get 177 bytes free and is functioning as it should. With the same code, v6.11 compiler and some mystery errors, same optimisation -O1 I get 55 bytes free....mmmm


    With -Oa agressive optimisation I get around 255 bytes free on v6.11....but as noted above, some of this may be due to the....aggressive optimisation of assignments. v6.03 doesn't have the -Oa option.



  6. Hi All,


    Just a quick note to users of v6.1 SourceBoost 'C' compiler. I had a very tightly coded set of code, that was leaving about 70-100 bytes free in v6.0. I updated to v6.11 and first got a exceeding rom error...OK, I'll put on agressive optimisation using compiler option -Oa.

    Some functions failed eg:


    unsigned char a_global_var; //declared globally for use in asm statements

    unsigned char b_global_var;


    void my_func(unsigned char a, unsigned char :(


    a_global_var = a; //assign function parameters so asm code can use them

    b_global_var = b;




    movf a_global_var,W ;my actual code is non trivial!!

    addwf b_global_var,F





    I then looked at the code bar....to see what was happening.


    The compiler optimised out the assignments to the global variables I presume thinking that they weren't being used, this meant my assembly code now didn't get the values to work with.......doh....if only we could access function parameters in asm code fragements ....hint, hint B)

    On the plus side the agressive optimisation really cut down the code size!


    OK so I move to level 1 optimisation with the -O1 option. These particular functions now compiled OK.....however the code still doesn't work and is a little longer than before. The mix of optimisation improvements from 6.0 -> 6.11 is doing something which I'll have to track down. I don't suppose theres a list somewhere of the optimisation changes?


    For now I'm in a bit of a rush and will go back to 6.0 (hopefully....expect another msg if I can't figure out how to uninstall 6.11 and reinstall 6.0). For now just a notice that people should watch out when compiling old code with regards to the new optimisation algorithms in 6.11 and in particular the issue of 'unused assignments' above.



  7. Thanks for the response Pavel.....one for the enhancement list I suppose :)


    I suppose I should clarify the code I wrote below as well....it won't work. The variable naming appears only after compilation, and so you get an error even using the scheme...doh


    Just had an idea that may be easier to implement (and increse possibility of making it to next release!)...it doesn't work at the moment but if you could define the memory location for the parameter variable..eg:


    #define PARMPOS 0x30

    unsigned char parmasm@PARMPOS;

    void myfunc(unsigned char parm@PARMPOS);


    then you could use the equivalent 'parmasm' variable in code like this:

    void myfunc(unsigned char parm@PARMPOS)




    movf _parmasm,W





    anyway....just a thought..and would I suspect be easier to code than re-writing the whole variable allocation code in the compiler. Even just being able to use a global variable in the function definition would help...though I supect it wouldn't be 'C' then.



  8. Hi,

    I'd like to use some function parameters in some inline assembly. From the compiler it seems to use the pattern:

    (function name)_00000_arg_(parameter name)


    void my_func(unsigned char nParm);

    ....nParm is defined and can be referred to in asm statement as


    movf _my_func_00000_arg_nParm,W




    and I can write my assembly using that format. All well and good.


    Problems are that

    - it is dependant on the particular build of the compiler, and has to be worked out by doing a test compile

    - changing the function name or parameter name means going through the asm statement and fiddling about


    Is there a correct method for referring to the function parameters in an asm statement that will work if say the writers change this parameter naming scheme? Also is there any danger of there being a 00000_arg changing to 00001_arg.....the numbers imply that it can be incremented?


    I know that I can simply declare working variables and assign them in the function...but memory is getting tight.



    Any suggestions would be greatly appreciated.



  9. Thanks for the confirmation Dave, I thought it might be something like that. Looking at the most assembly the linker is indeed very clever, though I didn't expect that you guys had figured out a way of making it read my mind!! Fair enough.

    Do have a suggestion though, how about getting the linker to put up a warning when it sees a 'addwf pcl' line.....to remind the user to check out the source..it's pretty much second nature now having used PIC assembly for a while, but new wonder what's happening.


    Incidentally, I was considering changing the state machine code to something like

    movf _sw_state,W

    xorlw STATE1

    btfsc _status,Z

    goto DO_STATE1

    movf _sw_state,W

    xorlw STATE2

    btfsc _status,Z

    goto DO_STATE2......and so on....have to keep it in assembly as it's an interrupt routine.


    Is this a reasonable alternative.....or have you guys (or forum members) figured out a more efficient state/jump method?



  10. Hi,


    Not sure if this is a bug, or if it has been seen before. I'm using SourceBoost V6 upgraded from the previous v5 version.


    The problem is the automatic bank select code is not working. More to the point, it is working up to a point, then doesn't. I can't figure out why.


    I've got code in an asm segment, which is referring to some variables I've let the compiler allocate. When I look at the assembly, it's put them into bank1. I'm also using bank0 registers like checking port inputs.


    The compiler correctly inserts proper RP0,RP1 statements up to the last bit of the code below when I look at the code view....however for some reason it then stops putting bank select statements in....(my comments in <<<<<>>>>)


    In my INP_MEASURE computed goto below, the increment of the sw_measure variable has no bank select statements, while the previous section in INP_CONFZERO has them correctly set up when the same variable was clrf'd.


    I can only think that somehow the compiler has got it into it's head that the bank select statements set up in INP_CONFZERO carry through to INP_MEASURE and there is no need to add them....but why did it sort things out OK in INP_CONFZERO?


    What's going on? For now I've moved my variables explicitly into bank0.....but I'd rather let the compiler do the allocation.


    The bank <variable> directive in c2c doesn't seem to work in boostc...is there an alternative?





    note variables sw_state and sw_measure are defined as:

    unsigned char sw_state;

    unsigned char sw_measure;

    INP_PORT is #define INP_PORT _porta



    The asm file created shows them as allocated to bank1....located 0xec, 0xed


    void inp_scan(void)




    <<<<compiler correctly switches to bank 1>>>

    movf _sw_state,W ;just to current state

    <<<<<then switches to bank 0 to calculate pcl change>>>>>>

    addwf _pcl,F

    goto INP_IDLE


    goto INP_MEASURE


    <code snipped>

    goto INP_EXIT


    btfsc INP_PORT,INP_PIN

    goto INP_EXIT


    movlw IN_IDLE

    <<<<compiler correctly switches to bank1>>>>

    movwf _sw_state

    <<<<compilr correctly switches to bank 0>>>>>

    btfsc INP_PORT,INP_PIN

    goto INP_EXIT

    movlw IN_MEASURE

    <<<compiler still gets it right, and correctly switches to bank 1>>>>>

    movwf _sw_state

    clrf _sw_measure

    goto INP_EXIT


    <<<<doh....after getting it right all this time, now it 'forgets' to switch to bank 1

    incf _sw_measure,F

    movlw MEASURE_MAX

    <<<<remaining cod has no bank select instructions inserted by compiler>>>>>

  11. Just started on using the ADC on the 16F88 with the new 5.9 sourceboost ide/compiler. (Thanks to Pavel and co...some nice changes there).

    Is the ADC supported on the 16F88?....are there issues and restrictions. I've noted the docos mentioned 16F877 and compatibles as being supported....but is 16F88 compatible?

    Anyway, just thought Id ask before banging my head around code trying to get it to work in case it wasn't supported yet.


  12. oops...sorry my mistake....I was trying all sorts of things like -h --help /? to get up the list....must be the Linux in me!


    ..could you get the linker to show all its command line options with a -h -? --help ...


    That's already been done for a long time already. If you run compiler or linker without any command line options they will display their help screen with all options listed:


    D:\Program Files\SourceBoost>boostc.pic16.exe
    BoostC Optimizing C Compiler Version 1.9.4 Beta (test build) (for PIC16 architecture)
    Copyright(C) 2004-2005 Pavel Baranov
    Copyright(C) 2004-2005 David Hobday
    Useage: boostc.pic16.exe [options] files
           -t name target processor (default name=PIC16F628)
           -On     optimization level (default n=1)
                   n=0 - optimization turned off
                   n=1 - optimization turned on
           -Wn     warning level (default n=1)
                   n=0 - no warnings
                   n=1 - some warnings
                   n=2 - all warnings
           -i      debug inline code (default off)
           -d name define 'name'
           -v      verbose mode turned on (default off)
    D:\Program Files\SourceBoost>linker.exe
    BoostLink Optimizing Linker Version 1.9.3 Beta
    Copyright(C) 2004-2005 Pavel Baranov
    Copyright(C) 2004-2005 David Hobday
    Useage: linker.exe [options] files
    -t name     target processor
    -On         optimisation level 0-1 (default n=1)
                n=0 - no optimization
                n=1 - pattern matching and bank switching optimization on
    -v          verbose mode
    -d path     directory for project output
    -p name     project (output) name for multiple .obj file linking
    -ld path    directory for library search
    -rb address ROM bottom address to use
    -rt address ROM top address to use
    Switches for making libraries:
    -lib        make library file from supplied .obj and .lib files
    -p name     project (library output file) name





  13. Hi,

    Next release or so, could you get the linker to show all its command line options with a -h -? --help (or as a result of an error in options) please. Also both c2c and boost compilers (although it shows some, I'm not sure it shows all).

    This is handy when trying to optimise the compile (as opposed to the code).



    PS: Thanks for the char * support in boostc....it's proving very handy in reducing some asm code that needed to do some very nasty byte juggling.

  14. Thanks Dave,


    I'll look into it your example, though I don't really want to change to Boost right now (I'll check it out when my current deadline has passed).


    I actually had an idea on the problem......put the interrupt and asm code into an included asm file or library and not let the c2c compiler touch it at all, linking it in at the call to MPASM stage....a bit fiddly but it should work. I'll get back to the forum on the results.






    If I was using the BoostC compiler to do what you want, I would where the linker puts the bottom of its code using the -rb linker option.


    This way you move everything up leaving you to fill in the blanks regarding reset and interrupt vector. You have total freedom in this area B)


    The only downside to this is that to put code in this area you will need to manually put in the opcodes using the #pragma DATA directive :)


    This will be OK if you only have a tiny amount of code todo. You can aways jump to the interrupt handler function once you have done you highspeed stuff.


    You will need to add code to patch the reset through to the normal reset code. You will know where this is because it will all be shifted by the amount you specify in -rb option.


    To see this kind of thing being done have a look at the BoostC bootloader by Ryan Davis http://www.picant.com/c2c/examples.html


    Hope this helps.




  15. I feel like I'm talking to myself.....oh well maybe it's the holidays :)


    I've added a enhancement request to this problem, but if anyone has any ideas, please post them.


    I've got a bit of a timetable and don't want to experiment with the new Boost1.8 compiler unless I knew it would work, has anyone got the same problem with the new Boost1.8 compiler?



  16. Hi Pavel,


    For C2C compiler version 5.7e


    Please refer to topic


    for the original reason for the problem and examples.


    I'd like to be able to disable the compiler inserting bank switch statements in asm{} code only but not for the 'C' code. Currently it can be switched off for all code, but doing this prevents the 'C' code from working if it is large, like my code. For some asm code I am taking care of the bank switching myself, and don't want the extra code inserted. The problem is important in the interrupt routine described in the topic referenced above, but is now becoming important now my code is approaching memory limit....too many instructions being added.



    Does the new Boost1.8 compiler support this? I'm up against a timetable so don't really want to risk changing my environment if it isn't.


    Thanks Phil

  17. HI All,

    With SourceBoost IDE 5.7, C2C 5.7e, target 16F628A.

    I have a very tight interrupt routine, I've written my own context saving (and disabled auto insertion in IDE as well as disabled default interrupt.)

    Problem is the compiler is inserting bcf STATUS,RP0 etc when I don't want it to....ie in the interrupt routine. I want it elsewhere in the code, just this little piece of asm code. If I disable context switching, it turns it off for all the code, no good for me though, I just want it in this one spot.


    void interrupt(void){

    asm {

    .....blah minimal context saving

    clrf _status ;want to clear RP0,RP1 and IRP

    clrf _portb


    compiles as

    blah context stuff

    clrf _status

    bcf _status,RP0 <--------superfluous

    bcf _status,RP1

    clrf _portb

    although I know the compiler is being helpful here, but I've already handled the problem

    of setting everything to page zero and I'm now two cycles further than where I wanted to be....four if you count the initial jump to interrupt routine.


    Any ideas of what to do here? I know I can disable context switching, but then I'd have to manually change every bit of code and put page changes in...yuk


    A similiar post to this was http://sourceboost.ipbhost.com/index.php?showtopic=43&hl=

    although this was about something else it shows the same result




    PS: Any ideas on removing the need to jump to the interrupt? Ie org the interrupt code right at 0x04 before the main startup code? Perhaps change where the main startup code goes. That's an extra two cycles that can be trimmed.



  • Create New...