Those could be implemented, but they were designed based on the Itanium instruction set and don't correspond to what the MSP430 instruction does. The "sync_op" part corresponds to an MSP430 RMW instruction, but the "and_fetch" would require a second read to get the resulting value. I.e., they're equivalent to "c = (a op= b);" rather than just "a op= b".
I still feel the right solution is to either revise the MSP430 instruction cost assignments combiner patterns so gcc can put the split read and write operations back together again, or to provide specific intrinsics. At this time I have no plans to pursue either approach. Peter On Tue, Oct 2, 2012 at 12:41 AM, Alex Orange <crazyca...@gmail.com> wrote: > I hate to dig this back up, but I just realized another slightly more > friendly way of doing this would be to use the atomic gcc builtins (like > __sync_and_and_fetch, __sync_or_and_fetch, etc.). Do we support these > functions, if not how hard would it be to add them. It would seem that this > would be the most portable code between different gcc targets (obviously it > wouldn't port outside gcc, though you could fake the __sync functions for > other targets). > > On Tue, Sep 4, 2012 at 11:19 AM, Peter Bigot <big...@acm.org> wrote: > >> On Tue, Sep 4, 2012 at 11:52 AM, JMGross <msp...@grossibaer.de> wrote: >> > ----- Ursprüngliche Nachricht ----- >> >>True, but that won't matter. Compilers do not usually track the state >> >>of status bits over a longer range than one instruction pattern. >> > >> > There's more in the status register than just the status bits. >> > There are the LPM bits too. Besides CPUOFF, which is of >> > course never set when the CPU is running, there is the control >> > for XT1 or DCO. And in 3x/5x family, one of them controls the FLL. >> > Just overwriting the status register may unintendedly reactivate the >> > FLL, that might have been deactivated inside the atomic block, >> > with desastrous results. And the others might have impact on >> > current consumption. >> > Well, one could declare it as a coding bug to deactivate the FLL inside >> > an atomic block, but I prefer not creating dependencies where I can >> avoid it. >> > And if the atomic block is a timing calibration function, it might be >> > necessary. >> > >> > How does the latest MCPGCC handle this on funcitons with critical >> > attribute? >> >> The "critical" function attribute in mspgcc saves and restores the >> entire status register. Any changes within the function are >> discarded. Use of "biX_status_register_on_exit()" may or may not >> work; I haven't tried it, and wouldn't count on it if it did. >> >> As you point out, there are reasons why somebody might want to control >> SCG0, and the fact that __set_interrupt_status() might overwrite that >> is a concern. When implementing the intrinsic I asked on E2E how it >> behaved on other platforms, and was told it restored all the bits. I >> considered alternatives that would save only GIE, but decided that >> doing so wasn't worth the hassle and loss in performance and >> compatibility. Besides, a benefit of explicitly using >> __set_interrupt_status() and __get_interrupt_status() is that the >> application gets full control of what bits are restored. Any >> intentional changes to the live status register can be replicated in >> the saved state before restoring it. (Though really, if you're going >> to play those games, you should probably use __read_status_register() >> and __write_status_register() instead; it's unfortunate that IAR and >> CCS chose a name that implies only the interrupt status is >> manipulated.) >> >> In the MSP430 infrastructure environment I'm developing (both >> standalone and for FreeRTOS) I allow the application to control what >> bits are cleared on LPM exit, and ensure any infrastructure routines >> such as ISRs that manipulate the status register don't clear SCG0 when >> they shouldn't. This was specifically a result of the severity of the >> UCS errata in the 5xx family and the importance of controlling FLL >> behavior via SCG0 to avoid them. >> >> Peter >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Mspgcc-users mailing list >> Mspgcc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
