Jump to content

ppulle

EstablishedMember
  • Content Count

    71
  • Joined

  • Last visited

Everything 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. phil
  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 #pragma USE_DEFAULT_MATHS 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. Phil
  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. Phil
  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? Phil
  5. May be a while before I try the install/re-install to do some differential test, but I have a project in mind that might be suitable to demonstrate the code/optimisation issues. Incidentally teunizz.....if you run the compiler from the command line without any parameters, it will print a help screen with the optimisation and other settings. phil
  6. 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. phil
  7. 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; asm { movf a_global_var,W ;my actual code is non trivial!! addwf b_global_var,F } return; } 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 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. phil
  8. 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) { asm { movf _parmasm,W } return; } 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. phil
  9. 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) eg void my_func(unsigned char nParm); ....nParm is defined and can be referred to in asm statement as asm{ 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. Phil
  10. 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? phil
  11. 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? Phil 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) { asm { <<<<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_CONFZERO goto INP_MEASURE goto INP_CONFMEASURE <code snipped> goto INP_EXIT INP_IDLE: btfsc INP_PORT,INP_PIN goto INP_EXIT INP_CONFZERO: 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 INP_MEASURE: <<<<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>>>>>
  12. Thanks for the info Dave...it's not too serious, I'll test the ADC stuff the hard way.....ummm.....with hardware!
  13. 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. Phil
  14. 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! 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) http://www.picant.com/c2c/c.html Copyright(C) 2004-2005 Pavel Baranov Copyright(C) 2004-2005 David Hobday Useage: boostc.pic16.exe [options] files Options: -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 http://www.picant.com/c2c/c.html Copyright(C) 2004-2005 Pavel Baranov Copyright(C) 2004-2005 David Hobday Useage: linker.exe [options] files Options: -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 Regards, Pavel <{POST_SNAPBACK}>
  15. 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). Thanks Phil 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.
  16. The BoostC compiler version 1.9.3 does not have the XORWF fix for inline assembly. asm { XORWF _blah,F } compiles as XORWF blah,W and XORWF blah,W compiles as XORWF blah,F workaround #define XORF W #define XORW F asm { XORWF blah,XORF ;or use XORW as needed.....when compiler fixed, change these defines or search and replace }
  17. Using Sourceboost IDE 5.8 and C2C 5.8e compiling for 16F88 target when the code size goes over 2k it does not compile. Errors start appearing saying that it cannot find various labels and compilation is aborted. The PIC16F88.TDF file was checked and it is at version 1.16
  18. 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. Phil
  19. 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? Phil
  20. Hi Pavel, For C2C compiler version 5.7e Please refer to topic http://sourceboost.ipbhost.com/index.php?showtopic=825 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
  21. 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. Eg 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 Phil 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. Thanks
×
×
  • Create New...