Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.

#1 Nov. 14, 2005 09:51:33

Roberto P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] iomacros.h


Hi all!

in <iomacros.h> i got these defs:

#define _BIS_SR(x) __asm__ __volatile__( "bis %0, r2" : :
"i" ((uint16_t)x) );
#define _BIC_SR(x) __asm__ __volatile__( "bic %0, r2" : :
"i" ((uint16_t)x) );

#define __bis_SR_register(x) __asm__ __volatile__( "bis %0, r2" : :
"i" ((uint16_t)x) );
#define __bic_SR_register(x) __asm__ __volatile__( "bic %0, r2" : :
"i" ((uint16_t)x) );

in the post "Constraints on inline asm operands" of 2005-01-20 the
author noted that the constraints "i" requires an immediate value
(i.e. a constant), otherwise an error is generated.
That's fine. So my question is: shouldn't the 3rd and 4th defs have
the constraint "r" ?

I mean, from their name I understand they were meant to operate
register to register, weren't they? Is that a copy-and-paste mistake
or is there a reason i can't get ?

For the moment I defined my own:

__my_bis_SR_register(x) __asm__ __volatile__( "bis %0, r2" : : "r"
((uint16_t)x) );


Roberto

Offline

#2 Nov. 15, 2005 09:12:13

Roberto P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] iomacros.h


>>Hi all!
>>
>>in <iomacros.h> i got these defs:
>>
>>#define _BIS_SR(x) __asm__ __volatile__( "bis %0, r2" : :
>>"i" ((uint16_t)x) );
>>#define _BIC_SR(x) __asm__ __volatile__( "bic %0, r2" : :
>>"i" ((uint16_t)x) );
>>
>>#define __bis_SR_register(x) __asm__ __volatile__( "bis %0, r2" : :
>>"i" ((uint16_t)x) );
>>#define __bic_SR_register(x) __asm__ __volatile__( "bic %0, r2" : :
>>"i" ((uint16_t)x) );
>>
>>in the post "Constraints on inline asm operands" of 2005-01-20 the
>>author noted that the constraints "i" requires an immediate value
>>(i.e. a constant), otherwise an error is generated.
>>That's fine. So my question is: shouldn't the 3rd and 4th defs have
>>the constraint "r" ?
>>
>>I mean, from their name I understand they were meant to operate
>>register to register, weren't they? Is that a copy-and-paste mistake
>>or is there a reason i can't get ?
>>
>>For the moment I defined my own:
>>
>>__my_bis_SR_register(x) __asm__ __volatile__( "bis %0, r2" : : "r"
>>((uint16_t)x) );
>>
>>
>>
>These macros exists with two different names for compatibility with
>other tool chains for the MSP430. They are intended to be identical, and
>I believe are correct as they stand.
>
>Regards,
>Steve

Ok. Then I'll add another def to my own collection. I think it's quite
useful to have something like:

__BIS_SR_reg2reg(x) __asm__ __volatile__( "bis %0, r2" : : "r"
((uint16_t)x) );

for example i use it in routines that cannot be interrupted, this way:

int_status = READ_SR & GIE; // read status register and mask GIE
dint(); // ensure this
routine in unninterruptible
...
...stuff...
...
__BIS_SR_reg2reg(int_status) // = eint() if irqs were enabled

so that the interrupt status is unaltered at the end of the routine
and no test and jump is required.

Roberto

Offline

#3 Nov. 15, 2005 11:40:24

Chris L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] iomacros.h


Roberto Padovani schrieb:Ok. Then I'll add another def to my own collection. I think it's quite
useful to have something like:

__BIS_SR_reg2reg(x) __asm__ __volatile__( "bis %0, r2" : : "r"
((uint16_t)x) );

for example i use it in routines that cannot be interrupted, this way:

int_status = READ_SR & GIE; // read status register and mask GIE
dint(); // ensure this
routine in unninterruptible
...
...stuff...
...
__BIS_SR_reg2reg(int_status) // = eint() if irqs were enabled

so that the interrupt status is unaltered at the end of the routine
and no test and jump is required.you could also use the "critical" function attribute that is provided bymspgcc (which generates less code that your solution)crititcal void some_function_with_disabled_interrupts(void) {}

chris

Offline

#4 Nov. 15, 2005 13:28:57

Roberto P.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] iomacros.h


Thanks Chris!

that's nice! "critical" actually generates 2 bytes less and it doesn't
make use of a register.
most of my routines will benefit from this!
However, if a routine is _really_ time critical and you have a
register to spare (I only have two such creatures ), that macro will
be more efficient:

instruction ---> cycles

mov r2, r14 ---> 1
dint ---> 1
and #8, r14 ---> 1 (this also saves us the nop instruction)
...
bis r14, SR ---> 1
ret ---> 3

which is a total of 7 cycles (without stack usage), while "critical"
generates the following:

push r2 ---> 3
dint ---> 1
nop ---> 1
...
reti ---> 5

which is a total of 10 cycles (with 2 bytes stack).

Roberto

2005/11/15, Chris Liechti <cliec***@*mx.net>:
> Roberto Padovani schrieb:
> > Ok. Then I'll add another def to my own collection. I think it's quite
> > useful to have something like:
> >
> > __BIS_SR_reg2reg(x) __asm__ __volatile__( "bis %0, r2" : : "r"
> > ((uint16_t)x) );
> >
> > for example i use it in routines that cannot be interrupted, this way:
> >
> > int_status = READ_SR & GIE; // read status register and mask GIE
> > dint(); // ensure this
> > routine in unninterruptible
> > ...
> > ...stuff...
> > ...
> > __BIS_SR_reg2reg(int_status) // = eint() if irqs were enabled
> >
> > so that the interrupt status is unaltered at the end of the routine
> > and no test and jump is required.
>
> you could also use the "critical" function attribute that is provided by
> mspgcc (which generates less code that your solution)
>
> crititcal void some_function_with_disabled_interrupts(void) {}
>
> chris
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
>http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/mspgcc-users>

Offline

Board footer

Moderator control

Enjoy the 20th of November
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support