Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Asmotaku

  • Rank
  1. Bug description: BoostC16 Linker greedy optimizations. BoostC16 linker makes time-critical built-in assembly very hard to get, with command-line parameter -O1 ! Steps to reproduce: Compile and Link the following Statements : "JUMPTABLE_MASK" equals 0x07 Passing the "myindexvar" parameter to the "Time_Critical_Func" routines makes the ┬ÁC execute an instruction flow, as shown below myindexvar <= 1 --> process CODECHUNK[1-5] myindexvar == 2 --> process CODECHUNK[2-5] myindexvar == 3 --> process CODECHUNK[3-5] myindexvar == 4 --> process CODECHUNK[4-5] myindexvar == 5 --> process CODECHUNK[5] myindexvar > 5 --> process CODECHUNK[1-5] + time-alignment 'NOP's Any value of "myindexvar" exceeding 0x05 must code for a code jump to "CODECHUNK_01", plus time-critical NOP's. void Time_Critical_Func() asm{ MOVLW 0x03 MOVWF _pclath INCF _myindexvar, W ANDLW JUMPTABLE_MASK ADDWF _plc, F ; forced jump GOTO CODECHUNK_1 GOTO CODECHUNK_2 GOTO CODECHUNK_3 GOTO CODECHUNK_4 GOTO CODECHUNK_5 NOP NOP ; last address accessible by 'forced jump' NOP ; some time-critical ops NOP ; Which could have been replaced by the well-known : GOTO $+1 ; which replace 2 NOPs, saving program memory ; The fact is I use it whenever I can... CODECHUNK_1: ; do what's needed in first chunk CODECHUNK_2: ; do what's needed in first chunk CODECHUNK_3: ; do what's needed in first chunk CODECHUNK_4: ; do what's needed in first chunk CODECHUNK_5: ; do what's needed in first chunk RETLW 0 } } The problem 100% reproduceable. Pending behavior : BoostC16 linker, with command-line operator [-01] (Optimization On) will judge the [NOP]s as dead code... which is not... Those silent instruction may be critical for a real-time application. Morever : the GOTO $+1 trick, which save program ROM, is said to be invalid by the linker. *sob* *sob* Expected behaviour: How a fixed program should behave : You can bypass this by using the [-O0] command-line parameter...BUT...your code inherits a buch of BANK selection instruction (BCF STATUS , RPx), which damages the time-critical code aspects. Users should have the opportunity to tell BoostC when a built-in asm snippet must be optimized wisely, or even left as-is ! Such as the unchecked() pragma of C#. As a matter of fact, the code I presented above could have been easier to implement if BoostC had offered a fixed address function declaration : void MyFixedRoutine()@MY_ROM_ADDRESS IDE version: SourceBoost IDE v5.r6.c1 Compiler: BoostC Compiler version: BoostC16 v1.r4 Target device: Any PIC16 architecture OS: WinXP Comments : Didn't spend time to check syntax in this post.
  2. Found it.... BoostC is unable to allocate & map memory for fixed-address arrays... writing : " char MyArray[6]@0x190; " will lead to this horrible "missing semicolon".... HOW CAN I SET AN ARRAY TO BANK-COMMON MEMORY ??? *sob* *sob* Example : On a P16F877, all registers mapped between 0x70 & 0x7F can be accessed without bank selection... It saves 4 asm instruction for a simple read-modify-write code...
  3. Why does BoostC compiler throws out tons of "missing semicolon" errors with a C code that compiles perfectly with C2C. I used neither any fancy pragmas, nor even header files ! Any hint about this situation ?
  4. The best way would be using LP configuration to draw a minimal current from the PIC's internal osc driver (although an external clock wiring will let the OSC2 pin unconnected, and no current will flow through it anyway). Then, the simpliest and most accurate solution should be a crytal oscillator, with a frequency (let's call it Fq) equal to a power of 2 if u wanna use interrupts. Therefore, you can use this subcircuit to drive a 74HC161, which will provide you with 4 selectable clock rates : Fq/2 , Fq/4, Fq/8, Fq/16. Then, with a 4MHz oscillator, you can get a 500kHz frequency from pin12 (Q2) of the 74HC161. This is a sure way to get many different clock sources from a cheap circuit (u can get a 74HC161 for less than half a buck !). Another solution would be to use a 1MHz ext clock combined with a "divide by 2" subcirtcuit. But the number of device will reach the first I described, without as many rates (ie : five) as you could desire ! Don't think about ACCURATE clock sources neither with RC pairs, nor resonators. I almost forgot : SPG8651A offers a 100ppm stability. Far away from your 5ppm needs !!!! Nota Bene : I was talking n'bout CRYSTAL clock sources, cuz, as you said, you need 5ppm accuracy.
  5. I've heard about 'bit support' in the enhancement requests section. Excellent thougth...but, as a matter of fact : C2C is already optimized for single-bit tests upon ...u8 variables. As far as I'm concerned, I'm tired about writing ASM snippets in order to optimize my code when accessing u16 LSB/MSB. for example : short u16Value=0; // // Do thingies with u16Value... // ...and then... // if(u16Value.10) // testing bit u16Value<10>, equivalent to " if(u16Value & 0x0400) " { // conditional code block } CC5X gets a big advantage about this : short u16Variable= 0xFFAA; char u8Value_A,u8Value_B; // assuming this : u8Value_A = u16Variable.low8 // least significant byte u8Value_B = u16Variable.high8 // most significant byte Note : u16Variable's address does not have to be pinned in ram by a strongly-mapped declaration ! :cool: We're saving code AND memory. (not using any third "_code_tmp_0000" variable). Time is now to create a new "variable bitlength" type, such as u1,u2,u3,u4,u5,u6,u7,u8 (char)... etc... No kidding ! P12C508(A) only offers 25 byte of memory ! Then, where is the usefulness in using a C compiler when half of your code appears between asm{} statements (I hate to have "dirty" C mixed with "clean" ASM in the same file, that's quite unreadable). Strong explicit casting would be a start (when using macros), for ex. : #define MSB(MyU16var) (char)@(&MyU16var + 1) Finally, users won't bother to write .pat scripts to optimize 16bits conditions. :sob: Pavel Sir ! Please, help us !
  6. Well, some ANSI-C newbies could ask "what is dereferencing". It concern the use of "&" preceding a var's symbol. Then, using indirect addressing with FSR, it's common sense to think of : char myvariable[10]; char idx; for(idx=0; idx<10; idx++) { fsr = &myvariable + idx; indf = something; } /* instead of */ ??? for(idx=0; idx<10; idx++) { asm { bank _myvariable ; risky while using .lib modules ; movf _idx,W addlw _myvariable movwf FSR ;** assert STATUS's IRP bit **; movf _something,W movwf INDF; } As far as I'm concerned, I greatly prefer the first syntax and its 3 lines code ! :cool: So, Mr Pavel Sir, how about dereferencing ?
  7. Well, some ANSI-C newbies could ask "what is dereferencing". It concern the use of "&" preceding a var's symbol. Then, using indirect addressing with FSR, it's common sense to think of : char myvariable[10] char idx; for(idx=0; idx<10; idx++) { fsr = &myvariable + idx; indf = something; } /* instead of */ for(idx=0; idx<10; idx++) { asm { bank _myvariable ; risky while using .lib modules ; movf _myvariable,W movwf FSR movf _something,W movwf INDF; }
  8. please read "semicolon" instead of "semiconlon" (which is just a half a gust)
  9. Well ... is it impossible to define symbols containing "parenthesis", as in pseudo-function declarations (parameterless macros). And is it really impossible to use backslashes '\' to extend the #define lenght to multiple lines ???
  10. Hi there. Well, it appears that C2C is unable to locate an error from inside a header file. Beware Pavel ! CC5X is able to do it ! :: Friendly yours... Asmotaku, registered user. I almost forgot : a just simple "missing" semicolon throws back a "general error" message. Sthg like " semiconlon expected" may be much proficient while debugging. May it not ?
  • Create New...