Re: PicBASIC speed and code efficiency

Started by Eirik Karlsen August 8, 2005
I'm about to start on a major program, which I
expect to be some 32K in assembly.
To save me getting some additional gray hairs
I'm sniffing at BASIC for this project.
But I need -SPEED- can't afford to loose much
of it compared to a well-written assembler program. Can anyone say something about PicBASIC's
execution speed and code efficiency, compared
to manually (well)written assembly programs ?

--
*******************************************
VISIT MY HOME PAGE:
<http://home.online.no/~eikarlse/index.htm>
LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen


--- In piclist@picl..., Eirik Karlsen <eikarlse@o...> wrote:
> I'm about to start on a major program, which I
> expect to be some 32K in assembly.
> To save me getting some additional gray hairs
> I'm sniffing at BASIC for this project.
> But I need -SPEED- can't afford to loose much
> of it compared to a well-written assembler program. > Can anyone say something about PicBASIC's
> execution speed and code efficiency, compared
> to manually (well)written assembly programs ?

Hi Eirik,

As you are concerned with efficiency you should look at the XSCB
compiler. This generates VERY efficient code.

Example

proc inline bit_set(ubye *ptr, int bit_id)

*ptr = *ptr | (1 << bit_id)

endproc

proc inline bit_clear(ubye *ptr, int bit_id)

*ptr = *ptr & ~(1 << bit_id)

endproc

proc main()

ubyte fred

bit_set(&fred, 3)
bit_clear(&fred, 4)

endproc

These eleven high level statements compile down to just TWO machine
instructions

bsf fred, 3
bcf fred, 4

BTW you have a very interesting hobby, building jet engines - wow!

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
.


Sergio,
I've been looking at their website and the XCSB looks very interesting, especially since
I'm familiar with structured programming ( VB and alike ).
The stated assembler/XCSB speed drop of max 20% is more than adequate....
up to 50% would be acceptable.

However I could not find any info on what chips XCSB supports ?
I'll be working exclusively with the upper range PIC18F series, maybe a smaller PIC18F
for a LCD display P/S interface.
Does it generate code for e.g 18F6527 ?
 

smxcu wrote:

Hi Eirik,

As you are concerned with efficiency you should look at the XSCB
compiler. This generates VERY efficient code....................
 

Regards
Sergio Masci
 

--
*******************************************
VISIT MY HOME PAGE:
<http://home.online.no/~eikarlse/index.htm>
LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen
 

--- In piclist@picl..., Eirik Karlsen <eikarlse@o...> wrote:
> Sergio,
> I've been looking at their website and the XCSB looks very interesting,
> especially since
> I'm familiar with structured programming ( VB and alike ).
> The stated assembler/XCSB speed drop of max 20% is more than
> adequate....
> up to 50% would be acceptable.

Actually the compiler optimisation has come a long way since the docs
were written and efficiency is even better than that now.

>
> However I could not find any info on what chips XCSB supports ?
> I'll be working exclusively with the upper range PIC18F series, maybe a
> smaller PIC18F
> for a LCD display P/S interface.
> Does it generate code for e.g 18F6527 ?
>

No sorry it currently only supports 14 bit cores (most 16F and some
12F). Any particular reason you are looking at the 18 series? This
compiler can pack a hell of a lot into just the 2k or a 16f628.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

.


Sergio,
sorry to hear that, guess I'll just have to cope with assembly then....
its not so bad except it'll be a helluva lot of code to keep track of.

 I'll simultaneously be running :
2 SPIs, 2 UARTs, 4 ADCs plus 14 external ADCs (SPI),
6 external DACs (SPI), a lot of timer circuitry,
4 full 16bit PID loops. All of this at fairly high speed.
All DAC/ADCs running trough time consuming 16bit FIR filters.
I'll also be needing about 1K RAM and at least 1/4K EEPROM.
Will be running slightly complex code, including
2 command interpreters ( Host PC, and local LCD/keypad).

Only the 18F will do, the controlpoints for the look-up tables alone
(sensor linearization) will probably be more than 2KB.
 
 

smxcu wrote:

 

No sorry it currently only supports 14 bit cores (most 16F and some
12F). Any particular reason you are looking at the 18 series? This
compiler can pack a hell of a lot into just the 2k or a 16f628.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
 

--
*******************************************
VISIT MY HOME PAGE:
<http://home.online.no/~eikarlse/index.htm>
LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen
 

Hi Eirik,

 

Sounds like some interesting code!  Multi threaded? What will you do for a task manager?

 

How about PICC 18 compiler?

 

I’d be interested in hearing more about your project.

 

Alan  KM6VV

 

From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of Eirik Karlsen
Sent: Tuesday, August 09, 2005 1:56 PM
To: p...@yahoogroups.com
Subject: Re: [piclist] Re: PicBASIC speed and code efficiency

 

Sergio,
sorry to hear that, guess I'll just have to cope with assembly then....
its not so bad except it'll be a helluva lot of code to keep track of.

 I'll simultaneously be running :
2 SPIs, 2 UARTs, 4 ADCs plus 14 external ADCs (SPI),
6 external DACs (SPI), a lot of timer circuitry,
4 full 16bit PID loops. All of this at fairly high speed.
All DAC/ADCs running trough time consuming 16bit FIR filters.
I'll also be needing about 1K RAM and at least 1/4K EEPROM.
Will be running slightly complex code, including
2 command interpreters ( Host PC, and local LCD/keypad).

Only the 18F will do, the controlpoints for the look-up tables alone
(sensor linearization) will probably be more than 2KB.
 



--- In piclist@picl..., "Alan Marconett" <KM6VV@a...> wrote:
> Hi Eirik,
>
> Sounds like some interesting code! Multi threaded? What will you do
for a
> task manager?
>
> How about PICC 18 compiler?
>
> I'd be interested in hearing more about your project.

Yes so would I.

BTW XCSB provides multitasking facilities.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

.



Well,
it is basically a logging device for logging various engine parameters, by tapping
into the key sensors on gasoline injection engines, typically car engines.
It can also log some other vehicle parameters like speed and accelerations.
In addition it fully controls two independent wideband lambda sensors, each
requiring two PID loops. Also inputs data to the Engine Control Unit (ECU).
-Onboard LCD+keys for data readout & config/setup.
-Interfacing to PC for retrieval of logs, and config.
That's about it.

Will almost certainly be using a state machine or multi threading to keep things
orderly.
Unfortunately I've never gotten around to learn C, and I don't think its a good idea
to start messing with a new language in the midst of all this...so it looks like it will be
assembly.
 
 

smxcu wrote:

 --- In p...@yahoogroups.com, "Alan Marconett" <KM6VV@a...> wrote:
> Hi Eirik,
>
> Sounds like some interesting code!  Multi threaded? What will you do
for a
> task manager?
>
> How about PICC 18 compiler?
>
> I'd be interested in hearing more about your project.

Yes so would I.

BTW XCSB provides multitasking facilities.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

--
*******************************************
VISIT MY HOME PAGE:
<http://home.online.no/~eikarlse/index.htm>
LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen
 

HI Eirik,

 

I can understand why you wouldn’t want to take on ‘C’ when with a project like this.

 

OBDII can provide a lot of information, but back probing the ECU connector can provide the analog signals as well. 

 

Alan  KM6VV

 

From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of Eirik Karlsen
Sent: Tuesday, August 09, 2005 3:42 PM
To: p...@yahoogroups.com
Subject: Re: [piclist] Re: PicBASIC speed and code efficiency

 

Well,
it is basically a logging device for logging various engine parameters, by tapping
into the key sensors on gasoline injection engines, typically car engines.
It can also log some other vehicle parameters like speed and accelerations.
In addition it fully controls two independent wideband lambda sensors, each
requiring two PID loops. Also inputs data to the Engine Control Unit (ECU).
-Onboard LCD+keys for data readout & config/setup.
-Interfacing to PC for retrieval of logs, and config.
That's about it.

Will almost certainly be using a state machine or multi threading to keep things
orderly.
Unfortunately I've never gotten around to learn C, and I don't think its a good idea
to start messing with a new language in the midst of all this...so it looks like it will be
assembly.
 
 

smxcu wrote:

 --- In p...@yahoogroups.com, "Alan Marconett" <KM6VV@a...> wrote:
> Hi Eirik,
>
> Sounds like some interesting code!  Multi threaded? What will you do
for a
> task manager?
>
> How about PICC 18 compiler?
>
> I'd be interested in hearing more about your project.

Yes so would I.

BTW XCSB provides multitasking facilities.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

--
*******************************************
VISIT MY HOME PAGE:
<http://home.online.no/~eikarlse/index.htm>
LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen
 



--- In piclist@picl..., Eirik Karlsen <eikarlse@o...> wrote:
> Well,
> it is basically a logging device for logging various engine parameters,
> by tapping
> into the key sensors on gasoline injection engines, typically car
> engines.
> It can also log some other vehicle parameters like speed and
> accelerations.
> In addition it fully controls two independent wideband lambda sensors,
> each
> requiring two PID loops. Also inputs data to the Engine Control Unit
> (ECU).
> -Onboard LCD+keys for data readout & config/setup.
> -Interfacing to PC for retrieval of logs, and config.
> That's about it.
>
> Will almost certainly be using a state machine or multi threading to
> keep things
> orderly.
> Unfortunately I've never gotten around to learn C, and I don't think its
> a good idea
> to start messing with a new language in the midst of all this...so it
> looks like it will be assembly.

speaking of state machines

http://www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/block-indx.html

Shame the only PIC target for this tool is the 16 series (unless of
course you want to go with a third party C compiler).

Some day I'll get around to integrating XCSB into ZMech.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
.