Jump to content

Jamie

EstablishedMember
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Jamie

  • Rank
    Newbrie
  • Birthday 08/14/1969

Contact Methods

  • MSN
    net_hog_@msn.com
  • Website URL
    http://it.toolbox.com/blogs/codesharp
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Seattle, WA
  • Interests
    Electronics & Microcontrollers (guess I'm in the right forum eh?)
  1. Recursion will work but strange things may happen if you use function arguments and local variables as these will be modified on reentry as the same software stack locations are used (the software stack is static). It maybe that your code correctly handles the reentrency issues, so creating an error during the project build for this condition may not desirable. Regards Dave Hi Dave, I was seeing if you did anything special to handle recursion because of the nature of the static stack . You should be able to identify the bad cases by analysis. It's useful to analyze recursion to identify potential return stack overflow too. I would second Reynard's request to give a warning (do you have a #pragma to turn on/off warnings?) Thoughts for improvement (on that huge list I'm sure you have : * Identify a recursion scenario - give at least a warning unless the recursion can be verified to be safe -- this I think, along with ability to turn warnings on/off is very desirable * flatten out tail-call recursion (maybe you do this already?) * In a recursion scenario, determine if it's bounded (above example it is) - this gives opportunity to flatten the recursion * Determine if modified 'stack' variables are used after the recursive call returns (this can be used at least to determine if recursion is safe or not) * introduce a temporary value stack in the recursive call Out of all of this, I particularly vote the first point. I don't think it's a hardship asking someone to avoid recursion, and those warnings help alert the more naive programmer. Flattening out tail-call recursion should be a trivial optimization if you've not done this already (I haven't checked) given the static stack. - Jamie
  2. I was experimenting to see how the compiler handled recursion, and wrote the following simple problem: #include <system.h> unsigned char recur(unsigned char r, unsigned char x) { if(r > 0) { return recur (r-1, x+x) + x; } else { return x; } } void main() { unsigned char c = recur(3, 1); } This should give the value '15', but gives the value '32', consistent across all optimization levels as far as I can tell. Generated code (default optimization) is as follows: ;///////////////////////////////////////////////////////////////////////////////// ;// Code Generator: BoostC Compiler - http://www.sourceboost.com ;// Version : 6.95 ;// License Type : Full License ;// Limitations : PIC12,PIC16 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only ;///////////////////////////////////////////////////////////////////////////////// ORG 0x00000000 0000 281F GOTO _startup ORG 0x00000004 0004 recur_00000 0004 ; { recur; function begin 0004 0821 MOVF recur_00000_arg_r, W 0005 3C00 SUBLW 0x00 0006 1803 BTFSC STATUS,C 0007 2812 GOTO label1 0008 0321 DECF recur_00000_arg_r, W 0009 00A1 MOVWF recur_00000_arg_r 000A 0822 MOVF recur_00000_arg_x, W 000B 0722 ADDWF recur_00000_arg_x, W 000C 00A2 MOVWF recur_00000_arg_x 000D 2004 CALL recur_00000 000E 0822 MOVF recur_00000_arg_x, W 000F 0723 ADDWF CompTempVarRet579, W 0010 00A3 MOVWF CompTempVarRet579 0011 0008 RETURN 0012 label1 0012 0822 MOVF recur_00000_arg_x, W 0013 00A3 MOVWF CompTempVarRet579 0014 0008 RETURN 0015 ; } recur function end ORG 0x00000015 0015 main 0015 ; { main; function begin 0015 3003 MOVLW 0x03 0016 1283 BCF STATUS, RP0 0017 1303 BCF STATUS, RP1 0018 00A1 MOVWF recur_00000_arg_r 0019 3001 MOVLW 0x01 001A 00A2 MOVWF recur_00000_arg_x 001B 2004 CALL recur_00000 001C 0823 MOVF CompTempVarRet579, W 001D 00A0 MOVWF main_1_c 001E 0008 RETURN 001F ; } main function end ORG 0x0000001F 001F _startup 001F 118A BCF PCLATH,3 0020 120A BCF PCLATH,4 0021 2815 GOTO main Not sure if this is even intended to be supported or not. Thanks! - Jamie
  3. New blog entry in my "Code Sharp" blog, showing how to use Novo for a Reaction Timer game. http://it.toolbox.com/blogs/codesharp/sour...novo-rtos-31978 Enjoy!
  4. This would suggest that if the two semaphores in above example were being waited on by two different threads, then only one of them would be moved to the wait queue? Or has the behavior chanced since this description was written? Looking at the source code its looks like the documentation is out of date. I remember once trying to implement at ultra lightweight SysSignalSemaphoreIsr function, but this caused too many other issues. Regards Dave This is good to know, thanks Dave!
  5. Both calls to SysSignalSemaphoreIsr(); are significant as they affect different semaphores. Even if they both operated on the same semaphore they would still be significant because the semaphores are of a counting type, so two calls to SysSignalSemaphoreIsr(hSem1); would cause the hSem1 value to be increased by 2. Regards Dave Hi Dave, I'm trying to understand the significance of the following in the documentation: This would suggest that if the two semaphores in above example were being waited on by two different threads, then only one of them would be moved to the wait queue? Or has the behavior chanced since this description was written?
  6. I'm drafting a blog/sample for Novo. Can you confirm that my following understanding of SysSignalSemaphoreIsr is correct? I believe the following code to be broken: void interrupt(void) { if ( /* int1 flag test */ ) { SysSignalSemaphoreIsr(hSem1); /* clear int1 flag */ } if ( /* int2 flag test */ ) { SysSignalSemaphoreIsr(hSem2); /* clear int2 flag */ } } Should int1 and int2 flags both be set, "SysSignalSemaphoreIsr(hSem1);" would effectively be ignored. If my understanding is correct, is there a trivial workaround?
×
×
  • Create New...