On 14/02/14 11:19, Brian Drummond wrote:
> On Fri, 2014-02-14 at 09:39 +0100, David Brown wrote:
>> On 14/02/14 00:12, Brian Drummond wrote:
>>> I have built a crosscompiler for the MSP430, using a gcc4.9 snapshot
>>> (gcc-4.9-20140112)
>>> ... what C code fragment would
>>> cause the "enable_interrupts" instruction to be emitted, and generate
>>> "EINT" in the assembler or object output?
>>>
>>> - Brian
>>>
>>
>> If you want help about the guts of the compiler, you are probably better
>> posting to the gcc development mailing list at <gcc@xxxxxxxxxxx>. I
>> know that the guys doing the msp430 gcc port follow that list. Another
>> useful place is the mspgcc users' list <mspgcc-users@xxxxxxxxxxxxxxxxxxxxx>.
>
> Thanks. I have re-asked on gcc@ ...
> The mspgcc-users list seems to be mainly focussed on the mspgcc
> compiler, not surprisingly. (Its archive also doesn't seem to be
> browsable by thread title...)
That's true - so discussions about the internals of the new msp430 port
are not going to get a big following on the mspgcc users list. But we
on that list are certainly interested in /using/ the new port - once it
is considered fully stable and "released" by TI (including library,
debugger, etc., not just the compiler) then many people there will start
using it.
>
>> But if you just want a fix that you can use, then use inline assembly:
>> #define __eint() asm volatile(" eint" ::: "memory")
>
> I don't. If that was the right approach, then the existing mechanism
> should be ripped out of the msp430 backend. But it's there and I want to
> use it; it's just not clear to me how it should be used in place of the
> mspgcc builtins.
>
I agree that if these functions are available within the msp430 port of
gcc, then they should be exposed as builtins (and the documentation
should reflect that). So if they are to be defined using inline
assembly in header files, then they should be removed from the gcc sources.
I note that there are a couple of builtins documented:
<http://gcc.gnu.org/onlinedocs/gcc/MSP430-Built-in-Functions.html>
These two functions could not be implemented with inline assembly, and
thus /must/ be made as builtins.
