> Sergio Masci <EraseMEpiclistspam_OUTTakeThisOuTmit.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

>Is it just me or is assembly sometimes easier than C?
>
>---
>James Newton: PICList webmaster/Admin
>@spam@jamesnewtonKILLspampiclist.com  1-619-652-0593 phone
>http://www.piclist.com/member/JMN-EFP-786
>PIC/PICList FAQ: http://www.piclist.com
>
>
>
>  
>

> On Oct 6, 2004, at 9:48 PM, piclistEraseME.....xargs.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

>
> --- Sergio Masci <smplxSTOPspamspam_OUTxcprod.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.

> On Oct 6, 2004, at 11:34 PM, EraseMEpiclistEraseMExargs.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

> Sergio Masci <TakeThisOuTpiclistKILLspamspammit.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.

> 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

>
> >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

> 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
>

> Sergio Masci wrote:>
> 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

> > 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.

>
>
> Sergio Masci wrote:
>
> > 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
> >
>
> 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

> 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

> > > >  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

>
> 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

> >
> >
> >>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.

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

>
> 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

> 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..
>

> 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