Searching \ for '[PIC] new optimisation in XCSB' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'new optimisation in XCSB'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] new optimisation in XCSB'
2004\10\06@140954 by Sergio Masci

flavicon
face
Hi all,

I hope you will agree that the following info is worth mentioning. Version 1.7.0
of the xcsb compiler now also implements result promotion optimisation. The
following xcsb source code is compiled into just 3 machine instructions

hwreg PORTA = 5
hwreg PORTB = 6

const RA3 = (&PORTA << 3) + 3
const RB4 = (&PORTB << 3) + 4

proc inline set_bit(uint id)
       *(id >> 3) |= (1 << (id & 7))
endproc

proc inline ubyte test_bit(uint id)
       return (*(id >> 3) & (1 << (id & 7))) != 0
endproc

proc main()
       if test_bit(RA3) == 1 then
               set_bit(RB4)
       endif
endproc


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\06@150610 by Andrew Warren

flavicon
face
Sergio Masci <spam_OUTpiclistTakeThisOuTspammit.edu> wrote:

> The following xcsb source code is compiled into just 3 machine
> instructions
> ....
> proc main()
>         if test_bit(RA3) == 1 then
>                 set_bit(RB4)
>         endif
> endproc

   It seems as though two instructions (BTFSC RA3 / BSF RB4) would
   suffice... What three instructions are generated by XCSB?

   -Andy

=== Andrew Warren -- .....aiwKILLspamspam@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\06@215104 by Sergio Masci

flavicon
face

----- Original Message -----
From: Andrew Warren <aiwspamKILLspamcypress.com>
To: Microcontroller discussion list - Public. <.....piclistKILLspamspam.....mit.edu>
Sent: Wednesday, October 06, 2004 8:10 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

Yes you are right two machine instructions would be better than three, but the
point is that three is still increadibly good going when you concider the amount
of source that has been condensed into these three instructions.

The three instructions generated by xcsb are:

       004D    1D 85           f:05                    btfss   5,3
       004E    28 50           p:0050                  goto    x_else_0000
       004F                            x_then_0000
       004F    16 06           f:06                    bsf     6,4

       0050                            x_else_0000
       0050                            x_endif_0000

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@000140 by James Newtons Massmind

face picon face
Is it just me or is assembly sometimes easier than C?

---
James Newton: PICList webmaster/Admin
jamesnewtonspamspam_OUTpiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



> {Original Message removed}

2004\10\07@000607 by Shawn Wilton

flavicon
face
Always.

James Newtons Massmind wrote:

{Quote hidden}

>>{Original Message removed}

2004\10\07@001744 by Dave VanHorn

flavicon
face

I'd say so, especially for the low level stuff, peripheral interfacing, and interrupts.



>James Newtons Massmind wrote:
>
>>Is it just me or is assembly sometimes easier than C?

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@004813 by piclist

flavicon
face
On Wed, 6 Oct 2004, James Newtons Massmind wrote:

> Is it just me or is assembly sometimes easier than C?

I'm not sure I understand how that conclusion can be drawn from the
BASIC code that was presented.  In any event, the corresponding C code
is:

#include <pic.h>

void main(void)
{
   if (RA3)
       RB4 = 1;
}

...and that generates the expected two instructions, not three.


> James Newton: PICList webmaster/Admin
> KILLspamjamesnewtonKILLspamspampiclist.com  1-619-652-0593 phone
> http://www.piclist.com/member/JMN-EFP-786
> PIC/PICList FAQ: http://www.piclist.com
>
>
>
> > {Original Message removed}

2004\10\07@012345 by William Chops Westfield

face picon face
On Oct 6, 2004, at 9:48 PM, RemoveMEpiclistTakeThisOuTspamxargs.com wrote:

> In any event, the corresponding C code
> is:
>
> #include <pic.h>
>
> void main(void)
> {    if (RA3)
>         RB4 = 1;
> }
>
> ...and that generates the expected two instructions, not three.
>
Not exactly a fair comparison; He's bragging about the optimizer, not
the quality of the original code.  Clearly xcsb COULD do something like

>> hwreg PORTA = 5
>> hwreg PORTB = 6

>> proc main()
>>         if  (*PORTA & (1<<3)) then
>>                 *PORTB |= (1<<4)
>>         endif
>> endproc

And not need as much optimization.  I don't know offhand whether there
are high-level language constructs for dealing with individual bits;
doing so in a language that doesn't have the concept can be just about
as painful as illustrated...  (like, try doing integer math on a
programmable calculator.)

Does the C compiler still only generate 2 instructions when you add
an equivalently convoluted "abstraction" of io port bits?  and define
functions?  It's a substantial accomplishment, IMO...

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@023429 by piclist

flavicon
face
On Wed, 6 Oct 2004, William Chops Westfield wrote:

> Not exactly a fair comparison; He's bragging about the optimizer,
> not the quality of the original code.

I don't see anything in that code that requires optimization.  It's
purely constant expressions that can be evaluated at compile time.

> Does the C compiler still only generate 2 instructions when you add
> an equivalently convoluted "abstraction" of io port bits?

They're almost identically "abstracted" in the compiler's header file:

> hwreg PORTA = 5
> const RA3 = (&PORTA << 3) + 3

static volatile unsigned char   PORTA   @ 0x05;
static volatile bit RA3 @ (unsigned)&PORTA * 8 + 3;

> and define functions?  It's a substantial accomplishment, IMO...

The functions were "inline", so they're probably interpreted more like
C macros than functions.  But something like this:

#define TEST_BIT(port, bit)     (((port) & (1 << ((bit) & 7))) != 0)
#define SET_BIT(port, bit)      ((port) |= (1 << ((bit) & 7)))

void main(void)
{
   if (TEST_BIT(PORTA, 3))
       SET_BIT(PORTB, 4);
}

still generates two instructions.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@024827 by cdb

flavicon
Well, 3 resultant asm lines from a compiled language is much better
than my C compiler offers for the Pic.

Colin

--
cdb, spamBeGonecdbspamBeGonespambarnard.name on Thursday,7 October,2004

I have always been a few Dendrites short of an Axon and believe me it
shows.

Light travels faster than sound. That's why some people appear bright
until they speak!



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@032440 by Wouter van Ooijen

face picon face
> Well, 3 resultant asm lines from a compiled language is much better
> than my C compiler offers for the Pic.

The original Jal compiler creates the 2 instructions (Im am not sure
what the current compiler does). But this is (was) much easier for the
compiler because Jal has a bit data type.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@092706 by Sergio Masci

flavicon
face

----- Original Message -----
From: William Chops Westfield <TakeThisOuTwestfwEraseMEspamspam_OUTmac.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclistspamTakeThisOuTmit.edu>
Sent: Thursday, October 07, 2004 6:23 AM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

Bingo!

I tried to show an example that included complexity and familiarity.
Unfortunately most people seem to have homed in on the familiarity without
understanding the complexity.

The problem is getting parameters and result through the function interface in
an optimised way.

Many C programmers do not realise that there is a brick wall between the C
pre-processor and the actual compiler. There is a certain illusion of
optimisation that comes from being able to expand macros into the source code.
Macros are not functions and there is no function interface to get in the way
when they are used.

The following XCSB example generates just 1 machine instruction but should
illustrate the C pre-processor brick wall effect since variable addresses cannot
be computed by the pre-processor.

byte jack

proc inline ubyte xtest(uint addr)
       return (addr == &jack)
endproc

proc main()
       byte fred

       if xtest(&fred) == 0 then
               set_bit(RB4)
       endif
endproc

It would be interesting to see how many C compilers can do better ;-)

In hind sight the "bit" example was probably a bad one to choose since C
supports bit fields and XCSB does not. Also given the nature of the PIC I would
expect that a fair amount of effort has gone into optimising single bit access
through C bit fields.

I really don't want to get into a C vs. XCSB debate, all I am trying to show is
that the compiler does in fact generate highly optimised code and is worth
looking at.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@110124 by Stephen R Phillips

picon face

--- Sergio Masci <EraseMEsmplxspamxcprod.com> wrote:
> It would be interesting to see how many C compilers can do better ;-)
>
> In hind sight the "bit" example was probably a bad one to choose
> since C
> supports bit fields and XCSB does not. Also given the nature of the
> PIC I would
> expect that a fair amount of effort has gone into optimising single
> bit access
> through C bit fields.

C support for bit fields however is 'undefined'.  By that I mean YES it
supports bit fields but the actual arrangement of the bits within
memory is completely undefined.  Only through non ANSI extensions can a
deterministic bit field behavior be realized.  It would have been nice
to have some standard, but I understand there rational for not having
such a standard (because the underlying hardware could be negatively
affected with weird bit ordering). However I think it was still short
sighted.  If you use bit fields in C you are cursed with this problem.
So if you plan on storing bit fields or use them, you can't use them
with hardware addressed registers for example (like in the PIC's case),
without having it become non portable as a result.
>
> I really don't want to get into a C vs. XCSB debate, all I am trying
> to show is
> that the compiler does in fact generate highly optimised code and is
> worth
> looking at.
>
Are you using and intermediate code and performing transformation
optimization on that? (That's what GNU C does at least).

Stephen


               
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@114812 by William Chops Westfield

face picon face
On Oct 6, 2004, at 11:34 PM, RemoveMEpiclistEraseMEspamEraseMExargs.com wrote:

>
>> and define functions?  It's a substantial accomplishment, IMO...
>
> The functions were "inline", so they're probably interpreted more like
> C macros than functions.

Agreed, if xcsb processes "inline" functions the same as C macros,
it's less impressive.  I don't know if that's the case...

>
>  But something like this:
>
> #define TEST_BIT(port, bit)     (((port) & (1 << ((bit) & 7))) != 0)

What does your C compiler do if you use a C inline function instead
of a macro?

I guess, one of the (main?) impressive things is getting the info
that the expressions are constants across that function call boundry.
If inline functions are just macro-like, that's not such a big deal.
If they're really inline functions (and my compiler internals
expertise isn't enough to list all the ways that's different), then
it IS a pretty big deal...

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@131453 by piclist

flavicon
face
On Thu, 7 Oct 2004, William Chops Westfield wrote:

> What does your C compiler do if you use a C inline function instead
> of a macro?

I don't know of any C compilers for the PIC that support "inline".

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@142512 by Andrew Warren

flavicon
face
Sergio Masci <RemoveMEpiclistspam_OUTspamKILLspammit.edu> wrote:

> > It seems as though two instructions (BTFSC RA3 / BSF RB4) would
> > suffice... What three instructions are generated by XCSB?
>
> Yes you are right two machine instructions would be better than three,
> but the point is that three is still increadibly good going when you
> concider the amount of source that has been condensed into these three
> instructions.
>
> The three instructions generated by xcsb are:
>
>    btfss   5,3
>    goto   x_else_0000
>    bsf     6,4
> x_else_0000

Sergio:

I'm sorry if my comment was misunderstood... I'm aware of the point
you were making; I asked about the three instructions only because I
was curious.  

Your compiler's ability to understand what the function parameters
actually mean is impressive; I assume that you'll eventually add some
peephole optimization as a final step, to clean up simple cases like
this one.  

By the way, do both of these also generate three instructions?  

   proc main()
     if test_bit(RA3) == 0 then    // was originally "== 1"
       set_bit(RB4)
     endif

   proc main()
     if test_bit(RA3) == 1 then
       {}
     else
       set_bit(RB4)
     endif

-Andy

=== Andrew Warren -- RemoveMEaiwTakeThisOuTspamspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@145238 by Walter Banks

picon face


Sergio Masci wrote:

> Many C programmers do not realise that there is a brick wall between the C
> pre-processor and the actual compiler. There is a certain illusion of
> optimisation that comes from being able to expand macros into the source code.
> Macros are not functions and there is no function interface to get in the way
> when they are used.

The brick wall is an illusion based on very old C compiler technology. Most
current compilers abstract the program and then optimize. Constant folding
strength reduction and skip or jump determination occur so much after
parsing that the code that does these operations in unaware of the source
structure.

w..



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@150222 by Dave VanHorn

flavicon
face

>
>The brick wall is an illusion based on very old C compiler technology. Most
>current compilers abstract the program and then optimize. Constant folding
>strength reduction and skip or jump determination occur so much after
>parsing that the code that does these operations in unaware of the source
>structure.

These questions aren't particularly processor-centric:

Is it true that C compilers do/must push and pop ALL registers on interrupts?

Is it possible to reserve registers for interrupts?
If not, WHY?


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@152631 by Alexandre Guimaraes

face picon face
Hi, Dave

> These questions aren't particularly processor-centric:
>
> Is it true that C compilers do/must push and pop ALL registers on
interrupts?
>
> Is it possible to reserve registers for interrupts?
> If not, WHY?

   I am sure Codevision for the AVR's do not push all registers on
interrupts and I believe most modern compilers will not. You can use some
registers as "globals" and reserve them for using just inside the interrupts
or you can use "temporary" registers to process your data just when you are
inside the int routine. Nowadays I code most of the stuff in C and when I
get at time critical routines I use assembler mixed with C. Some stuff is as
efficient in C as it is in assembler, that is the case of if statments for
example and they are much easier to mantain in C. I hate to admit that :-)
Some other stuff I prefer to code directly in assembler.

Best regards,
Alexandre Guimaraes


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@160825 by Walter Banks

picon face
There are a bunch of interrupt context saving and restoring strategies for compilers.
>From a compilers perspective an interrupt is an execution thread (almost) randomly
executed while main line code is executing. When an interrupt is serviced a means
must be found to save the context of the currently running code and restore the
execution context at the end of an interrupt. That means any resource that the
interrupt needs has to be accounted for, condition codes, registers, sometimes
state information RAM and all functions that the interrupt and main line both can
call simultaneously  must be re-entrant.

> Is it true that C compilers do/must push and pop ALL registers on interrupts?

To answer your question.
 It is safe for a compiler to save everything.
 It is fast for the compiler  to save what is needed.
 It is better if the compiler determines what is needed

> Is it possible to reserve registers for interrupts?

It is possible in Byte Craft's compilers to reserve resources for interrupts including
registers. This many not be possible in all architectures where some resources are
essential in main line code.

w..


Dave VanHorn wrote:

> These questions aren't particularly processor-centric:
>
> Is it true that C compilers do/must push and pop ALL registers on interrupts?
>
> Is it possible to reserve registers for interrupts?
> If not, WHY?


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@161754 by Dave VanHorn

flavicon
face

> When an interrupt is serviced a means
>must be found to save the context of the currently running code and restore the
>execution context at the end of an interrupt. That means any resource that the
>interrupt needs has to be accounted for, condition codes, registers, sometimes
>state information RAM and all functions that the interrupt and main line both can
>call simultaneously  must be re-entrant.

Well, this is what I assumed the compiler would do..
Scan the int code, find out what is used/needed, and only push what is needed.
In the case of the AVR, pushing 32 registers is enormously expensive in a machine with 192 bytes of ram or less.

I have a few situations where I use very fast int code, that doesn't even preserve the status reg, because it doesn't need to. (the int code doesn't affect the flags.)

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@170011 by William Chops Westfield

face picon face
On Oct 7, 2004, at 12:03 PM, Dave VanHorn wrote:

> Is it true that C compilers do/must push and pop ALL registers on
> interrupts?
>
Certainly NOT.  You only have to save the registers that are modified by
the ISR, which is typically a couple more than for a normal function
call (most C compilers designate a couple registers that the calling
function preserves rather than the called function.)

> Is it possible to reserve registers for interrupts?
I think this is possible in some of the register-intensive RISC
architectures.

> If not, WHY?
Many CPU don't have enough registers to start with?  And don't forget
that many architectures have hierarchical interrupts; interrupt code
itself might be interrupted by a higher-priority interrupt; that would
mean you'd need to reserve registers for EACH interrupt level...

Assembly language "shims" can do sneaky things behind the back of a
C compiler.  Code I've seen uses a separate stack for each (C-level)
interrupt routine, and/or uses otherwise unused floating point registers
of a CPU as scratch space (that doesn't need to be saved.)

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@180212 by piclist

flavicon
face
On Thu, 7 Oct 2004, Dave VanHorn wrote:

> Is it true that C compilers do/must push and pop ALL registers on interrupts?

No.  On the PIC18, the compiler may not need to save any registers at
all.

> Is it possible to reserve registers for interrupts?
> If not, WHY?

Reserve them for what purpose?

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@203337 by Sergio Masci

flavicon
face

----- Original Message -----
From: Stephen R Phillips <EraseMEcyberman_phillipsspamspamspamBeGoneyahoo.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclistKILLspamspammit.edu>
Sent: Thursday, October 07, 2004 4:01 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

Regardless of this, the fact that you can easily identify an operation in C as a
bit operation makes it much easier to generate special optimisations for it.

struct {
unsigned int RA0 : 1;
unsigned int RA1 : 1;
unsigned int RA2 : 1;
unsigned int RA3 : 1;
unsigned int RA4 : 1;
unsigned int RA5 : 1;
unsigned int RA6 : 1;
} PORTA;

PORTA.RA1 = 1;

is easily identified as a bit operation.

PORTA = PORTA | (1 << n)

is much harder. Likewise

if (PORTA.RA0 != 0)

is much easier than

if ((PORTA & (1 << n)) != 0)

> >
> > I really don't want to get into a C vs. XCSB debate, all I am trying
> > to show is
> > that the compiler does in fact generate highly optimised code and is
> > worth
> > looking at.
> >
> Are you using and intermediate code and performing transformation
> optimization on that? (That's what GNU C does at least).

Yes this is part of the process..

>
> Stephen


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@203344 by Sergio Masci

flavicon
face

----- Original Message -----
From: William Chops Westfield <spamBeGonewestfwSTOPspamspamEraseMEmac.com>
To: Microcontroller discussion list - Public. <KILLspampiclistspamBeGonespammit.edu>
Sent: Thursday, October 07, 2004 4:48 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

No xcsb does not treat inline functions the same as C macros.

xcsb uses an inline function as a template to generate specialised code at the
point where it is invoked. The use of the formal parameters within the function
and the actual parameters at the point of invokation determin how the code is
generated.

e.g.

in C

   #define max(a,b) (a > b ? a : b)

   c = max(d+=1, 5);

is equivalent to

   c = (d+=1 > 5 ? d+=1 : 5)

in xcsb

   proc inline int max(int a, int b)
       if  a > b then
           return a
       else
           return b
       endif
   endproc

   c = max(d+=1, 5);

is equivalent to

   arg0 = d+=1

   if arg0 > 5 then
       c = arg0
   else
       c = 5
   endif

{Quote hidden}

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@203401 by Sergio Masci

flavicon
face

----- Original Message -----
From: Walter Banks <@spam@walter@spam@spamspam_OUTbytecraft.com>
To: Microcontroller discussion list - Public. <spamBeGonepiclistspamKILLspammit.edu>
Sent: Thursday, October 07, 2004 7:49 PM
Subject: Re: [PIC] new optimisation in XCSB


>
>
> Sergio Masci wrote:
>
> > Many C programmers do not realise that there is a brick wall between the C
> > pre-processor and the actual compiler. There is a certain illusion of
> > optimisation that comes from being able to expand macros into the source
code.
> > Macros are not functions and there is no function interface to get in the
way
> > when they are used.
>
> The brick wall is an illusion based on very old C compiler technology. Most
> current compilers abstract the program and then optimize. Constant folding
> strength reduction and skip or jump determination occur so much after
> parsing that the code that does these operations in unaware of the source
> structure.
>
> w..

Sorry Walter could you clarify this for me. Are you saying that C pre-processor
understands variable types and scope? Are you sure we are not talking about
different brick walls here?

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@203406 by Sergio Masci

flavicon
face

----- Original Message -----
From: Andrew Warren <.....aiwspam_OUTspamcypress.com>
To: Microcontroller discussion list - Public. <TakeThisOuTpiclist.....spamTakeThisOuTmit.edu>
Sent: Thursday, October 07, 2004 7:28 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

You are right, a keyhole optimiser would put the cherry on the cake.

>
> By the way, do both of these also generate three instructions?
>
>     proc main()
>       if test_bit(RA3) == 0 then    // was originally "== 1"
>         set_bit(RB4)
>       endif

This generates 3 instructions

>
>     proc main()
>       if test_bit(RA3) == 1 then
>         {}
>       else
>         set_bit(RB4)
>       endif

This generates 4 instructions. Yes the empty true statement generates NO code
and a goto instruction which then jumps around the false statement :-( It would
be pretty trivial to simply bracket the condition and prefix it with NOT then
drop the true statement.

i.e.
       if !(test_bit(RA3) == 1) then
               set_bit(RB4)
       endif

An insteresting question is what does you favourite PIC C compiler make of

       if ((A == B) == 0)
or
       if ((A == B) != 1)

xcsb sees this as

       if  A != B then

>
> -Andy

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\07@221833 by piclist

flavicon
face
On Fri, 8 Oct 2004, Sergio Masci wrote:

> An insteresting question is what does you favourite PIC C compiler make of
>
>         if ((A == B) == 0)

  if ((A == B) == 0)
       RA4 = 1;

compiles to:

000028  5000                movf    _A,w,c
00002A  1801                xorwf   _B,w,c
00002C  A4D8                btfss   status,2,c
00002E  8880                bsf 3968,4,c    ;volatile

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@013429 by William Chops Westfield

face picon face

On Oct 7, 2004, at 11:49 AM, Walter Banks wrote:

>
>> Many C programmers do not realise that there is a brick wall between
>> the C
>> pre-processor and the actual compiler.

> The brick wall is an illusion based on very old C compiler technology.

Really?  I was under the impression the preprocessing was still
rather separated from compilation.  In fact, on a current project
I'm using one C compiler as a preprocessor and another for the actual
compilation, due to compatibility issues.

That's a separate issue from constant folding and optimization,
sort of.  C's preprocessor makes it easy to create things almost
like functions that are very easy for a compiler to optimize.
Other times they'll bite your butt...

BillW


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@033209 by Stef Mientki

flavicon
face

>An insteresting question is what does you favourite PIC C compiler make of
>
>        if ((A == B) == 0)
>or
>        if ((A == B) != 1)
>
>  
>
My favourit compiler generates an error, ...
... which is completly right !!
You're comparing boolean with integer.

Stef Mientki
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@034502 by William Chops Westfield

face picon face
On Oct 8, 2004, at 12:36 AM, Stef Mientki wrote:

> My favourit compiler generates an error, ...
> ... which is completly right !!
> You're comparing boolean with integer.
>
C doesn't have booleans.

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@081528 by Sergio Masci

flavicon
face

----- Original Message -----
From: <.....piclistspamRemoveMExargs.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclistspamspamBeGonemit.edu>
Sent: Friday, October 08, 2004 3:18 AM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

Hi John,

That's very good. I've seen some really inefficient code generated for this in
the past. Which compiler is this?

Are A and B defined as global or local here?

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler




_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@081929 by Sergio Masci

flavicon
face

----- Original Message -----
From: William Chops Westfield <spamBeGonewestfw@spam@spamspam_OUTmac.com>
To: Microcontroller discussion list - Public. <TakeThisOuTpiclistspamspammit.edu>
Sent: Friday, October 08, 2004 6:34 AM
Subject: Re: [PIC] new optimisation in XCSB

> C's preprocessor makes it easy to create things almost
> like functions that are very easy for a compiler to optimize.
> Other times they'll bite your butt...
>
> BillW

Yeh, with iron teeth :-)

Regards
Sergio Masci

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@082932 by Sergio Masci

flavicon
face

----- Original Message -----
From: Stef Mientki <s.mientkiEraseMEspammailbox.kun.nl>
To: Microcontroller discussion list - Public. <RemoveMEpiclistEraseMEspamspam_OUTmit.edu>
Sent: Friday, October 08, 2004 8:36 AM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

Hi Stef,

I have yet to use a C compiler that does not allow this (trust me I have used a
great many in my time).

If your favourite PIC C compiler allows

       C = (A == B);

then it should allow the condition

       if ((A == B) == C)

This is important because if you define a C macro it should be able to generate
(x == y) without any problems and you should be able to use this in a condition

i.e.

       #define EQU(x, y) (x == y)

       if (EQU(A, B) == C)

Which compiler are you using?

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@085942 by Peter L. Peres

picon face

On Thu, 7 Oct 2004, William Chops Westfield wrote:

> I guess, one of the (main?) impressive things is getting the info
> that the expressions are constants across that function call boundry.
> If inline functions are just macro-like, that's not such a big deal.
> If they're really inline functions (and my compiler internals
> expertise isn't enough to list all the ways that's different), then
> it IS a pretty big deal...

I think that it is facilitated by passing the data by reference. This
allows the function to 'see' the original storage location and its type
tag. I just assume this of course. C++ should also be able to do this
(when passing arguments by reference) but its startup code size ...

Peter
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@114234 by Walter Banks

picon face


Sergio Masci wrote:

{Quote hidden}

C logical operations return 0 or 1. 0 is false 1 is true
When logically testing 0 is false non zero is true

case of A != B

if ((A == B) == 0)

if ( (0) == 0)

if (0 == 0)

if (1)  The if condition is true

=====================

if ((A == B) != 1)

if ((0) != 0)
if (0 != 0)
if (1)    The if condition is true

=======================

I agree that it is the same as
if (A !=B)

Walter..


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@115417 by piclist

flavicon
face
On Fri, 8 Oct 2004, Stef Mientki wrote:

> >An insteresting question is what does you favourite PIC C compiler make of
> >
> >        if ((A == B) == 0)

> My favourit compiler generates an error, ...
> ... which is completly right !!

No, your compiler is broken.

> You're comparing boolean with integer.

>From the standard: "The [== operator] yields 1 if the specified relation is
true and 0 if it is false. The result has type int."

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@115626 by piclist

flavicon
face
On Fri, 8 Oct 2004, William Chops Westfield wrote:

> C doesn't have booleans.

That's true in C90, on which all PIC compilers are based, but C99
introduced the _Bool type.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@115829 by piclist

flavicon
face
On Fri, 8 Oct 2004, Sergio Masci wrote:

> > > An insteresting question is what does you favourite PIC C compiler make of
> > >
> > >         if ((A == B) == 0)

> That's very good. I've seen some really inefficient code generated for this in
> the past. Which compiler is this?

Hi-Tech PICC.

> Are A and B defined as global or local here?

They were global to make the assembly listing more readable.  When
local, it looks like this:

 00000A  50E1                movf    fsr1l,w,c
 00000C  18D9                xorwf   fsr2l,w,c
 00000E  A4D8                btfss   status,2,c
 000010  8880                bsf 3968,4,c    ;volatile

since no RAM is allocated for A and B.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@120405 by Walter Banks

picon face


Sergio Masci wrote:>

> > The brick wall is an illusion based on very old C compiler technology. Most
> > current compilers abstract the program and then optimize. Constant folding
> > strength reduction and skip or jump determination occur so much after
> > parsing that the code that does these operations in unaware of the source
> > structure..
>
> Sorry Walter could you clarify this for me. Are you saying that C pre-processor
> understands variable types and scope? Are you sure we are not talking about
> different brick walls here?

The C pre-processor performs string substitution with some rules. In your example
there is no need to for the pre-processor to know about types or variables when it is
re-written as a define. xtest is expanded in the source and then processed by the
compiler. All of the the referenced variables are then in scope.

w..

{Quote hidden}

#define xtest(addr) ((ubyte) ((uint)addr == &jack)

byte jack;
void main ()
 {
  byte fred;
  if (xtest(&fred) == 0)
      set_bit(RB4);
 }

The compiler when it is optimizing the program it doesn't know the difference
between the inline source and #defines that have been expanded.


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@121255 by Walter Banks

picon face


@spam@piclistRemoveMEspamEraseMExargs.com wrote:

> > C doesn't have booleans.
>
> That's true in C90, on which all PIC compilers are based, but C99
> introduced the _Bool type.

C99's _Bool is a one bit int with the same rules to deal with
logical testing and logical results.

w..



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@130513 by Wouter van Ooijen

face picon face
> > >  if ((A == B) == 0)
>
> > My favourit compiler generates an error, ...
> > ... which is completly right !!
>
> No, your compiler is broken.

Did any of you notice that Stef did not say that his favourite compiler
is a C compiler?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@143331 by Sergio Masci

flavicon
face

----- Original Message -----
From: <EraseMEpiclistspam@spam@xargs.com>
To: Microcontroller discussion list - Public. <@spam@piclistspam_OUTspam.....mit.edu>
Sent: Friday, October 08, 2004 4:58 PM
Subject: Re: [PIC] new optimisation in XCSB


> On Fri, 8 Oct 2004, Sergio Masci wrote:
>
> > > > An insteresting question is what does you favourite PIC C compiler make
of
> > > >
> > > >         if ((A == B) == 0)
>
> > That's very good. I've seen some really inefficient code generated for this
in
> > the past. Which compiler is this?
>
> Hi-Tech PICC.
>

Thanks for the info.

{Quote hidden}

But this is only part of the code, you still need to include the code that
calculates the addresses of A and B at run time and prepares fsr1l and fsr2l.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@143338 by Sergio Masci

flavicon
face

----- Original Message -----
From: Walter Banks <spamBeGonewalterEraseMEspambytecraft.com>
To: Microcontroller discussion list - Public. <piclistspamBeGonespammit.edu>
Sent: Friday, October 08, 2004 4:39 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

No "(A == B)" can return 0 or 1 so the result is not known at compile time. "(A
== B)" cannot be reduced to 0 at compile time.

>
> =====================
>
> if ((A == B) != 1)
>
> if ((0) != 0)
> if (0 != 0)
> if (1)    The if condition is true

Again "(A == B)" cannot be reduced to 0 at compile time, however it is known
that the result of "(A == B)" can only be 0 or 1 so in this case "!= 1" is the
same as "== 0"

>
> =======================
>
> I agree that it is the same as
>  if (A !=B)
>
> Walter..

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@143344 by Sergio Masci

flavicon
face

----- Original Message -----
From: <RemoveMEpiclist@spam@spamspamBeGonexargs.com>
To: Microcontroller discussion list - Public. <.....piclist@spam@spamEraseMEmit.edu>
Sent: Thursday, October 07, 2004 7:34 AM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

Ok John, the following still generates only 3 instructions.

proc inline set_bit(uint id)
       *(id >> 3) |= (1 << (id & 7))
endproc

proc inline ubyte test_bit(uint id)
       return (*(id >> 3) & (1 << (id & 7))) != 0
endproc

proc fred()

       byte flags

       if test_bit((&flags * 8) + 0) == 1 then
               set_bit((&flags * 8) + 1)
       endif
endproc

I would be grateful if you could tell me how this compares with the Hi-Tech PICC
you are using.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler




_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@144331 by Sergio Masci

flavicon
face

----- Original Message -----
From: Wouter van Ooijen <.....wouterRemoveMEspamvoti.nl>
To: 'Microcontroller discussion list - Public.' <.....piclistSTOPspamspam@spam@mit.edu>
Sent: Friday, October 08, 2004 6:05 PM
Subject: RE: [PIC] new optimisation in XCSB


{Quote hidden}

I did notice that it's not XCSB ;-)

Regards
Sergio

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@150530 by Walter Banks

picon face
You missed my point or perhaps I missed yours.

The generated code in our compiler code is the same  as
(A != B) which is generally implemented as a XOR. I assumed
you were referring a well known common compiler bug where
if ((A == B) != 1) the (A==B) part implemented as a XOR
and is then compared to 1 fails. I walked through the ISO
definitions in my example. BTW this has shown up in different
forms as a WG-14 question at ISO an number of times in the
last few years.

w..

Sergio Masci wrote:

> {Original Message removed}

2004\10\08@150612 by Sergio Masci

flavicon
face

----- Original Message -----
From: Peter L. Peres <plpEraseMEspam@spam@actcom.co.il>
To: Microcontroller discussion list - Public. <RemoveMEpiclistspamspamBeGonemit.edu>
Sent: Friday, October 08, 2004 1:58 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

If you are talking about passing the information at compile time then no.
Several things need to be done with the function as a whole in order to determin
how best to deal with actual parameters.

consider

       proc inline byte fred(byte arg0)
               arg0 = arg0 + jack
               return arg0
       endproc

how would you deal with arg0 in these cases

       byte jack

       fred(7)
       fred(jack)

Also if you write the code

       byte c

       proc inline byte sum(byte arg0, byte arg1)
               return arg0 + arg1
       endproc

       c = sum(a, b)

xcsb will generate code equivalent to

       c = a + b

which is 3 machine instructions


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler




_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@154326 by piclist

flavicon
face
On Fri, 8 Oct 2004, Sergio Masci wrote:

> >   00000A  50E1                movf    fsr1l,w,c
> >   00000C  18D9                xorwf   fsr2l,w,c
> >   00000E  A4D8                btfss   status,2,c
> >   000010  8880                bsf 3968,4,c    ;volatile

> But this is only part of the code, you still need to include the code that
> calculates the addresses of A and B at run time and prepares fsr1l and fsr2l.

This is the complete code.  FSR1L/FSR2L are being used as temporary
registers to store the actual values of A and B, not for indirect
addressing (note there is no INDF reference).  Since they are local
variables, they don't to be placed in file registers.  Since they're
in a function that isn't using indirection, the FSRs are available as
temporary registers.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\08@160421 by piclist

flavicon
face
On Fri, 8 Oct 2004, Sergio Masci wrote:

> proc inline set_bit(uint id)
>         *(id >> 3) |= (1 << (id & 7))
> endproc
>
> proc inline ubyte test_bit(uint id)
>         return (*(id >> 3) & (1 << (id & 7))) != 0
> endproc
>
> proc fred()
>
>         byte flags
>
>         if test_bit((&flags * 8) + 0) == 1 then
>                 set_bit((&flags * 8) + 1)
>         endif
> endproc
>
> I would be grateful if you could tell me how this compares with the Hi-Tech PICC
> you are using.

I'm not sure I can translate that into C.  Multiplying and shifting
addresses of objects isn't meaningful (I'm assuming your "&" operator
is "address of").  The syntax used for declaring bit addresses of SFRs
is a Hi-Tech extension that doesn't normally get used in programs, and
I'm not sure that it can be used without the "@" operator.

--
John W. Temples, III
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\09@090154 by Stef Mientki

flavicon
face
>
>
>>My favourit compiler generates an error, ...
>>.... which is completly right !!
>>You're comparing boolean with integer.
>>
>>Stef Mientki
>>    
>>
>
>Hi Stef,
>
>I have yet to use a C compiler that does not allow this (trust me I have used a
>great many in my time).
>
>  
>
<snip>

>Which compiler are you using?
>
>  
>
hi Sergio,

Yes I have to admit still not using XCSB nor any C-compiler,
just a quiet un-optimized compiler, called JAL.
The problem is that, with an increasing installed base (which must be
maintained),
it's becoming more difficult every day to switch to another compiler.

The discussion is interesting from an theoretical point of view,
but what's it's practical relevance.
If I look at our own projects (prototypes and very small series, <200),
If the PIC is too small, we take a larger one (in fact we start with the
largest even for small projects).
If the code is too slow, we add a few lines of assembler.
Some figures,
We USE about 60% assembler in our code.
But we WRITE only about 5% in assembler.
Knowing the weakness of the compiler,
and working around these weakness by writing some (assembler) libraries,
you'll have a perfect tool.

I think that of more practical importance (then the ultime optimization,
which was already very good for XCSB a few years ago),
is the availability of libraries, to control the special IO-devices in a
easy way.
I thought I last read, there is still no SPI library, ...
...  Dallas 1-wire, ... stepper control, ... ?

(btw, the next version JALcc will have user defineable file-associates ;-)

cheers,
Stef Mientki


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\09@110251 by Sergio Masci

flavicon
face

----- Original Message -----
From: Stef Mientki <spamBeGones.mientkiKILLspamspam@spam@mailbox.kun.nl>
To: Microcontroller discussion list - Public. <piclistspam_OUTspam@spam@mit.edu>
Sent: Saturday, October 09, 2004 2:06 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

Hi Stef,

I understand your point of view but there is something that you should consider.

When you write a program you are trying to describe a problem and how to solve
it to a computer. When you do all this in assembler you are relying on the
expertise of the programmer both within the programming domain and the problem
domain. The programmer may be an assembler / PIC guru but may not know much
about the problem his program is trying to solve. Ok so you relay on libraries
that know a lot about the problem. However no mater how much these libraries are
optimised by the problem domain expert there is still the issue of tying these
libraries together to form a usable runtime. The problem is the interface
between the functions and variables within the libraries. You end up with a
protocol that says how the functions must be invoked, how the parameters must be
set up, how the results must be returned, what globals must be prepared, what
order the functions must be called in, which registers must be preserved, and
the list goes on...

If you use an optimising compiler it will / should treat the library interface
as a fuzzy protocol which it can bend and reshape depending on how the
programmer writes his code and the libraries interact with each other. A
compiler would have a lot of trouble doing this if the body of a function is
written in assembler and set in concrete.

Consider the XCSB function:

       proc inline byte SUM(byte x, byte y)
               return x + y
       endproc

and its use in

       byte    a, b, c

       a = SUM(b, c)

the compiler can actually reshape the protocol so that the end result is
actually:

       a = b + c

instead of

       x_func_sum_arg = b
       y_func_sum_arg = c
       call sum_func
       a = result_func_sum

sum_func:
       result_func_sum = x_func_sum_arg + y_func_sum_arg
       return

A really important aspect of all this is maintenance. As the problem changes
(perhaps the hardware you are controlling has changed, bigger, faster, more of
it, or simply different), you may end up having to rewrite the whole library
just to get decent performance out of it, then you have to change the app to
take the changes into account.

>
> I think that of more practical importance (then the ultime optimization,
> which was already very good for XCSB a few years ago),
> is the availability of libraries, to control the special IO-devices in a
> easy way.
> I thought I last read, there is still no SPI library, ...
> ....  Dallas 1-wire, ... stepper control, ... ?

Yes I agree that the language is a little light on specialised libraries. But
this is something that a user CAN easily implement whereas compiler specific
modifications would be very hard for the average user. I have concentrated on
the compiler foundations rather than the libraries to make it easier to write
high quality libraries without the need to resort to assembler.

The latest major optimisation was introduced because users wanted an easy to use
set of bit functions and the bit test function was inefficient when used as part
of an "if" statement. Previously this would generate 7 instructions, now it
generates just 1.

This particular optimisation has been a thorn in my side for several months now.
I did not want to implement it as a specialised function where the optimisation
was only available for a built in bit test function. I wanted the optimisation
to be available to anyone that wanted to take advantage of it - hence the delay.
Now I will move back to implementing libraries, but these are really trivial in
comparision.

>
> (btw, the next version JALcc will have user defineable file-associates ;-)

Excellent! I've been meaning to get in touch with you regarding co-operation
between the XCSB self installer and JALcc. I will play with this new version
when it is available then get it touch with a view to collaborating on
installation.

{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\09@110911 by Sergio Masci

flavicon
face

----- Original Message -----
From: <spamBeGonepiclist@spam@spamxargs.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclistEraseMEspamKILLspammit.edu>
Sent: Friday, October 08, 2004 8:43 PM
Subject: Re: [PIC] new optimisation in XCSB


> On Fri, 8 Oct 2004, Sergio Masci wrote:
>
> > >   00000A  50E1                movf    fsr1l,w,c
> > >   00000C  18D9                xorwf   fsr2l,w,c
> > >   00000E  A4D8                btfss   status,2,c
> > >   000010  8880                bsf 3968,4,c    ;volatile
>
> > But this is only part of the code, you still need to include the code that
> > calculates the addresses of A and B at run time and prepares fsr1l and
fsr2l.
{Quote hidden}

I think the correct term here is - Doh...

I don't know what I was thinking, I saw the FSR and equated it to INDF.
Enthusiasm than took over whereas I should have asked myself "why the addresses
were not being set-up". As you say using these registers as locals does make
sense.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\09@111221 by Sergio Masci

flavicon
face

----- Original Message -----
From: Walter Banks <spamBeGonewalterspam_OUTspamRemoveMEbytecraft.com>
To: Microcontroller discussion list - Public. <.....piclistspamRemoveMEmit.edu>
Sent: Friday, October 08, 2004 8:02 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

No I wasn't but it is intesresting, thank you for pointing it out.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\09@112049 by Sergio Masci

flavicon
face

----- Original Message -----
From: <piclistspam@spam@xargs.com>
To: Microcontroller discussion list - Public. <EraseMEpiclistRemoveMEspamSTOPspammit.edu>
Sent: Friday, October 08, 2004 9:04 PM
Subject: Re: [PIC] new optimisation in XCSB


{Quote hidden}

PICC
> > you are using.
>
> I'm not sure I can translate that into C.  Multiplying and shifting
> addresses of objects isn't meaningful (I'm assuming your "&" operator
> is "address of").  The syntax used for declaring bit addresses of SFRs
> is a Hi-Tech extension that doesn't normally get used in programs, and
> I'm not sure that it can be used without the "@" operator.

Thank you anyway.

Yes "&" is the "address of" operator in XCSB. I tried keep the meaning of
operators consistant between C and XCSB to help porting.

I use the "(&m * 8 + n)" to calculate the absolute address of a bit within the
PIC data space. So each bit has an address just as each SFR or RAM location has
an address. The absolute bit address of the carry flag in the status register
thus becomes (&STATUS * 8 + C).

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...