Post by thread:Pic basic

Hi Tony, Since nobody else has responded I'll put in my two cents worth. I was really disappointed/shocked in the performance numbers Scott Edwards quoted in the article; they were something like 1,000x slower than what I would consider a "decent" compiler (I seem to remember that a hand-written assembler could be as much as 1,400x better) for the speed the PIC was running at. Now, it is 10-50x better than the STAMP, but it's really pretty slow. The "C" Compilers out there are a lot better in terms of producing fast/reasonable code. >I was just wondering if anyone had an opinion on pic basic like >described in nuts&volts.I've written lots in basic some in C and a >little in assembly.But I prefer basic.I'm an instant gratification sorta >guy I guess. Tony M. I thought Clint Eastwood said that the only thing wrong with instant gratification was that it took too long... myke Today, the commercial sector is advancing computer and communication technology at a breakneck pace. In 1992, optical fiber was being installed within the continental U.S. at rates approaching the speed of sound (if computed as total miles of fiber divided by the number of seconds in the year). Aviation Week and Space Technology, October 28, 1996

myke predko wrote: {Quote hidden}> > Hi Tony, > > Since nobody else has responded I'll put in my two cents worth. > > I was really disappointed/shocked in the performance numbers Scott Edwards > quoted in the article; they were something like 1,000x slower than what I > would consider a "decent" compiler (I seem to remember that a hand-written > assembler could be as much as 1,400x better) for the speed the PIC was > running at. Now, it is 10-50x better than the STAMP, but it's really pretty > slow. > > The "C" Compilers out there are a lot better in terms of producing > fast/reasonable code. > > >I was just wondering if anyone had an opinion on pic basic like > >described in nuts&volts.I've written lots in basic some in C and a > >little in assembly.But I prefer basic.I'm an instant gratification sorta > >guy I guess. Tony M. > > I thought Clint Eastwood said that the only thing wrong with instant > gratification was that it took too long... > > myke That's what I had assumed. The same as on a pc since forever I wrote initially in basic or c then converted the subroutines one at a time to assembly.What I was wondering at the time was whether this was practical on a pic whether the code in compiled basic would even fit to start with but then I realize now that it was not a fair question.Besides my Microchip data book has arrived and I think I'll go with the assembly to start with.It looks reasonably doable Thanks Tony M.

> I was really disappointed/shocked in the performance numbers Scott Edwards > quoted in the article; they were something like 1,000x slower than what I > would consider a "decent" compiler (I seem to remember that a hand-written > assembler could be as much as 1,400x better) for the speed the PIC was > running at. Now, it is 10-50x better than the STAMP, but it's really pretty > slow. Which Pic BASIC was he talking about? PBASIC from Parallax is an interpreter. The "compile" option merely copies the interpreter and the P-Code into a PIC. There are also one or two true Pic BASIC compilers out there that produce native PIC code. The latter should be much faster than the former.

At 04:13 PM 11/27/96 -0600, you wrote: >> I was really disappointed/shocked in the performance numbers Scott Edwards >> quoted in the article; they were something like 1,000x slower than what I >> would consider a "decent" compiler (I seem to remember that a hand-written >> assembler could be as much as 1,400x better) for the speed the PIC was >> running at. Now, it is 10-50x better than the STAMP, but it's really pretty >> slow. > >Which Pic BASIC was he talking about? PBASIC from Parallax is an >interpreter. The "compile" option merely copies the interpreter and the >P-Code into a PIC. > >There are also one or two true Pic BASIC compilers out there that produce >native PIC code. I know 5 PIC Basic "compilers" two of them are "pseudo" ie copy the interpreter to PIC code 1 Parallax Compiler: CODE.OBJ resides at 0400h in C58 prog mem 2 PIC Basic Compiler (FED): I think, (never seen, cani prove) is same style as Parallax Compiler, ie copies P-CODE to C64 prog mem 3 MEL Basic Compiler: True Compiler, asm output 4 TB84: (James) student project, free in source code form, generates asm 16C84 5 BASX: (Greg) never released, generates asm for 16CXX Q: which ones you did mean, by two native generating compilers? 5 was never released, 4 is useless, 2 isnt compiler i think, it leaves us with only one native code generating PIC compiler: 3 from MEL? and thats only one I can count? or are there some more compilers? I am really interested if... >The latter should be much faster than the former. MEL Basic compiler is pretty much as fast as PIC can be (in native exec) BTW I am writing a Basic compiler for AT89C2051 seems so easy that I might just add PIC code generator to it later. Comments? antti -- Silicon Studio Ltd. -- http://www.sistudio.com

>> I was really disappointed/shocked in the performance numbers Scott Edwards >> quoted in the article; they were something like 1,000x slower than what I >> would consider a "decent" compiler (I seem to remember that a hand-written >> assembler could be as much as 1,400x better) for the speed the PIC was >> running at. Now, it is 10-50x better than the STAMP, but it's really pretty >> slow. > >Which Pic BASIC was he talking about? PBASIC from Parallax is an >interpreter. The "compile" option merely copies the interpreter and the >P-Code into a PIC. Sorry for taking so long to reply; I had to find the original article. It's the Micro Engineering Labs BASIC - for $100.00. The article is in Scott Edward's April 1996 "Stamp Applications" of Nuts & Volts. In it, Scott shows the section of code: again: b1 = b1 + 1 ; increment b1 toggle 0 ; toggle pin 0 goto again and then goes on to give the following performance results: BS1, 4 MHZ 479 Hz . : 16C84, compiled 4 MHZ 7215 Hz Now, my thought was that any decent compiler would produce the following code: again incf b1 ; increment b1 movlw 0x01 ; toggle pin 0 xorwf PORTB ; Assume pin 0 is in PORTB goto again This can be improved to: movlw 0x01 ; Setup Pin to Toggle again incf b1 ; increment b1 xorwf PORTB ; toggle pin 0 goto again Although while I would expect this type of optimization for a workstation compiler, I wouldn't think that it would be reasonable for a Hobbyist one. The first loop takes five instruction cycles to run (the second four) - five instructions running at 4 Mhz (1 MHz Instruction cycle frequency) means that the loop would run at 200 KHz. I guess I exaggerated a bit for the relative improvement - I was talking about 1,000x when I should have said 30x. But, I think you can see that there is area for concern/improvement. Not only in terms of speed, but also in terms of instruction space; what is the PIC executing during this loop? >There are also one or two true Pic BASIC compilers out there that produce >native PIC code. > >The latter should be much faster than the former. According to the article, this Compiler is creating native code. myke Today, the commercial sector is advancing computer and communication technology at a breakneck pace. In 1992, optical fiber was being installed within the continental U.S. at rates approaching the speed of sound (if computed as total miles of fiber divided by the number of seconds in the year). Aviation Week and Space Technology, October 28, 1996

At 10:53 AM 12/1/96 EST, you wrote: {Quote hidden}>>> I was really disappointed/shocked in the performance numbers Scott Edwards >>> quoted in the article; they were something like 1,000x slower than what I >>> would consider a "decent" compiler (I seem to remember that a hand-written >>> assembler could be as much as 1,400x better) for the speed the PIC was >>> running at. Now, it is 10-50x better than the STAMP, but it's really pretty >>> slow. >> >>Which Pic BASIC was he talking about? PBASIC from Parallax is an >>interpreter. The "compile" option merely copies the interpreter and the >>P-Code into a PIC. > >Sorry for taking so long to reply; I had to find the original article. > >It's the Micro Engineering Labs BASIC - for $100.00. > >The article is in Scott Edward's April 1996 "Stamp Applications" of Nuts & >Volts. > >In it, Scott shows the section of code: > > again: > b1 = b1 + 1 ; increment b1 > toggle 0 ; toggle pin 0 > goto again > >and then goes on to give the following performance results: > > BS1, 4 MHZ 479 Hz > . > : > 16C84, compiled 4 MHZ 7215 Hz > > >Now, my thought was that any decent compiler would produce the following code: > >again > incf b1 ; increment b1 > movlw 0x01 ; toggle pin 0 > xorwf PORTB ; Assume pin 0 is in PORTB > goto again Myke, you forgot that MEL' PBASIC compiler is Compiler from Basic Stamp Basic, not a PIC Basic compiler. To be compatible with BS1 the compiler uses internal 16 bit mathm b1 = b1 + 1 will result in 16 bit addition! TOGGLE instruction makes pin output and toggles state, those the compiler must access Bank 1 to access tristate control. and later toggle the port pin. so there are things todo in such simple code too :) >This can be improved to: > > movlw 0x01 ; Setup Pin to Toggle >again > incf b1 ; increment b1 > xorwf PORTB ; toggle pin 0 > goto again Yep this would be real nice. :) >Although while I would expect this type of optimization for a workstation >compiler, I wouldn't think that it would be reasonable for a Hobbyist one. > >The first loop takes five instruction cycles to run (the second four) - five >instructions running at 4 Mhz (1 MHz Instruction cycle frequency) means that >the loop would run at 200 KHz. I checked our multi-target Basic compiler with PIC as target with your code and got 50 KHz for the same loop. Well our compiler only supports byte vars. And does not make any optimising. >I guess I exaggerated a bit for the relative improvement - I was talking >about 1,000x when I should have said 30x. > >But, I think you can see that there is area for concern/improvement. Not >only in terms of speed, but also in terms of instruction space; what is the >PIC executing during this loop? see above, it is also translating pin number to bit mask. and resets watchdog at every basic instruction. >>There are also one or two true Pic BASIC compilers out there that produce >>native PIC code. >> >>The latter should be much faster than the former. > >According to the article, this Compiler is creating native code. Hm, I checked the native compiler and got 12.8 KHz for your loop. Maybe I did something wrong. antti -- Silicon Studio Ltd. -- http://www.sistudio.com

> > > >The article is in Scott Edward's April 1996 "Stamp Applications" of Nuts & > >Volts. > > > >In it, Scott shows the section of code: > > > > again: > > b1 = b1 + 1 ; increment b1 > > toggle 0 ; toggle pin 0 > > goto again > > > >and then goes on to give the following performance results: > > > > BS1, 4 MHZ 479 Hz > > . > > : > > 16C84, compiled 4 MHZ 7215 Hz > > > > > >Now, my thought was that any decent compiler would produce the following code: {Quote hidden}> > > >again > > incf b1 ; increment b1 > > movlw 0x01 ; toggle pin 0 > > xorwf PORTB ; Assume pin 0 is in PORTB > > goto again > > >This can be improved to: > > > > movlw 0x01 ; Setup Pin to Toggle > >again > > incf b1 ; increment b1 > > xorwf PORTB ; toggle pin 0 > > goto again > > Yep this would be real nice. :) > > >Although while I would expect this type of optimization for a workstation > >compiler, I wouldn't think that it would be reasonable for a Hobbyist one. > > > >The first loop takes five instruction cycles to run (the second four) - five > >instructions running at 4 Mhz (1 MHz Instruction cycle frequency) means that > >the loop would run at 200 KHz. I think the output would be more likely to be 100KHz. 5 instructions on and 5 instructions off. > > I checked our multi-target Basic compiler with PIC as target with your > code and got 50 KHz for the same loop. I just checked the MPC compiler and it generates the 5 instruction sequence first shown above. One of our other compilers surprised me with the following code sequence equivalent. movlw 0x01 ; Setup Pin to Toggle again xorwf PORTB ; toggle pin 0 goto again The missing increment was caused by a default non-volitile variable that was never again referenced in the program. Its value did not matter. True comparitive benchmarks are tough to write. Walter Banks

Walter Banks said: >> >The first loop takes five instruction cycles to run (the second four) - five >> >instructions running at 4 Mhz (1 MHz Instruction cycle frequency) means that >> >the loop would run at 200 KHz. > >I think the output would be more likely to be 100KHz. 5 instructions on and 5 >instructions off. Sorry, yes, you're right. I meant to say that the loop would execute at 200 KHz, not the LCD flashing. {Quote hidden}>> I checked our multi-target Basic compiler with PIC as target with your >> code and got 50 KHz for the same loop. > >I just checked the MPC compiler and it generates the 5 instruction sequence > first >shown above. > >One of our other compilers surprised me with the following code sequence > equivalent. > > > movlw 0x01 ; Setup Pin to Toggle >again > xorwf PORTB ; toggle pin 0 > goto again > >The missing increment was caused by a default non-volitile variable that was > never >again referenced in the program. Its value did not matter. I'm impressed; that's the sort of performance I would expect from a professional compiler. >True comparitive benchmarks are tough to write. This may sound cynical, but I don't know if there's any such beast as a "True comparitive benchmark". Any benchmarks I've seen seem to be more marketing tools than anything else (anybody else remember the Intel i86 vs. Motorola 68K benchmarking fiasco of the early '80s?). myke Today, the commercial sector is advancing computer and communication technology at a breakneck pace. In 1992, optical fiber was being installed within the continental U.S. at rates approaching the speed of sound (if computed as total miles of fiber divided by the number of seconds in the year). Aviation Week and Space Technology, October 28, 1996

Sanity check time: Someone else wrote: > I was really disappointed/shocked in the performance numbers Scott Edwards > quoted in the article; they were something like 1,000x slower than what I > would consider a "decent" compiler (I seem to remember that a hand-written > assembler could be as much as 1,400x better) for the speed the PIC was > running at. Now, it is 10-50x better than the STAMP, but it's really pretty > slow. The PIC is a computer, each interpreted BASIC statement takes some number of PIC instructions to execute, a compiler removes the interpreter part and substitutes for it just enough instructions to accomplish the computation. So ask yourself this: A.) "How many PIC instructions would it take me to implement TOGGLE 1 ?" B) "How many PIC instructions would it take to switch on the TOGGLE byte code, interpret an argument, and then change the state of the pin?" Now Divide B by A and that is your maximum speed up. If you *EXPECT* a 1000x improvement then you think it would take 1000 instructions to implement a single BASIC command. That is clearly unrealistic. 10x - 50x says to me "It takes between 10 and 50 times more instructions to interpret a byte code than it does to do it directly." Which is a reasonable statement. --Chuck

In message <spam_OUT32A25DCC.1E3FTakeThisOuTbytecraft.com> .....PICLISTKILLspam@spam@MITVMA.MIT.EDU writes: > > > > > >The article is in Scott Edward's April 1996 "Stamp Applications" of Nuts & > > >Volts. > > > > > >In it, Scott shows the section of code: > > > > > > again: > > > b1 = b1 + 1 ; increment b1 > > > toggle 0 ; toggle pin 0 > > > goto again > > > [much snipping] {Quote hidden}> One of our other compilers surprised me with the following code sequence > equivalent. > > > movlw 0x01 ; Setup Pin to Toggle > again > xorwf PORTB ; toggle pin 0 > goto again > > The missing increment was caused by a default non-volitile variable that was > never > again referenced in the program. Its value did not matter. > Walter, If it wasn't the MPC compiler, which one was it? Regards, Mike Watson

Here is the code produced when I ran it thru the PicBasic compiler: Basic: again: b1 = b1 + 1 ; increment b1 toggle 0 ; toggle pin 0 goto again Compiler output in asm: _again movf _B1,W call R0@0W movlw 001h call add@0W movf R0,W movwf _B1 movlw 000h call toggle@ @GOTO _again Note the three subroutine calls ... not quite as tight as Myke's code. The first call loads R0 from W. Then the constant "1" is loaded into W, and a subroutine is called to do the addition. Then registers are mucked about with and the toggle subroutine is called. I'm no compiler expert, althought I did study the subject years ago, and wrote some compiler code as a fun project. Converting "b=b+1" into "increment b" is what is called peephole (or local) optimisation ... look at a single statement, and see if the code can't be tightened up. Obviously the MEL compiler is not doing this in what is probably the most obvious case of peephole optimization, since most computers have an increment/decrement instruction, and this contruct is so commonplace. It is same, therefore, to assume that the MEL compiler doesn't do any optimization. But for $99, perhaps one should not expect much. What is real interesting about the MEL compiler is that they provide the library in source form, and the compiler produces ASM out the back end. It would be possible (although a fair bit of work) for a person to optmize code manually, assuming one knew assembler. Of course, if one did, one would probably write in assembler from the beginning, wouldn't one! We must recognize what the MEL PicBasic compiler was meant to do .... provide a means to write code for a 16C84, in Basic. The code will be faster for two reasons ... it does not have to be interpreted, and more important, it does not have to be read from S-L-O-W serial EEPPROM. Hopefully, it will also be small, since the compiler only includes those library routines it needs, whereas the real BASIC interpreter has all the library code builtin. I'm sure the folks at MEL could produce a much better version of the compiler if there was an economic incentive to do so. Larry >---------- >From: myke predko[SMTP:mykeKILLspamPASSPORT.CA] >Sent: Sunday, December 01, 1996 10:53 AM >To: Multiple recipients of list PICLIST >Subject: Re: Pic basic > (snip) {Quote hidden}>Now, my thought was that any decent compiler would produce the following >code: > >again > incf b1 ; increment b1 > movlw 0x01 ; toggle pin 0 > xorwf PORTB ; Assume pin 0 is in PORTB > goto again > >This can be improved to: > > movlw 0x01 ; Setup Pin to Toggle >again > incf b1 ; increment b1 > xorwf PORTB ; toggle pin 0 > goto again > >Although while I would expect this type of optimization for a workstation >compiler, I wouldn't think that it would be reasonable for a Hobbyist one. > >The first loop takes five instruction cycles to run (the second four) - five >instructions running at 4 Mhz (1 MHz Instruction cycle frequency) means that >the loop would run at 200 KHz. >(snip) >

Lester Wilson wrote: > > For those of you who use PICBASIC > > there is a PICBASIC mail list running > > EraseMEPICBASIC-Lspam_OUTTakeThisOuTqunos.net > > Its supported by MP Labs and Crownhill Associates ( UK Distributor) > > Regards > > Lester Wilson > Crownhill Associates Limited Where can users find instructions on how to subscibe Lester? I did ask mEL, but was told it would be posted but I still wonder where and when. Don McKenzie donspam_OUTdontronics.com http://www.dontronics.com Don's Download Dungeon http://www.dontronics.com/download.html For more details, send a blank message to @spam@infoKILLspamdontronics.com or KILLspamsimstickKILLspamdontronics.com or RemoveMEbasicsTakeThisOuTdontronics.com

>Did any body used PicBasic Pro Compiler?How does it works? I have used it, but you can learn to program PICs in assembly about as quickly as you can master PBP. And you'll have a better understanding of PICs if you habitually use assembly code too. Anyway, to answer your question, it works fairly well, is DOS based and stable, sort of integrates with MPLAB, has good support for I/O etc. You'll still need to use some assembly for tricky bits though. As someone else has said, the documentation isn't very well laid out and if you're a beginner you'll need some tutorial material too (there's plenty of that on the web of course). Overall I'd say it's a bit expensive for what it is, given that there are some perfectly good C/Forth/other compilers around for less (and indeed for free); but it does what it claims to do and does it without any fuss. .