On 18/02/14 00:12, DJ Delorie wrote:
I presume these will be part of the headers for the library
distributed for msp430 gcc by TI/Redhat?
I can't speak for TI's or Red Hat's plans. GNU's typical non-custom
embedded runtime is newlib/libgloss, which usually doesn't have that
much in the way
I presume these will be part of the headers for the library
distributed for msp430 gcc by TI/Redhat?
I can't speak for TI's or Red Hat's plans. GNU's typical non-custom
embedded runtime is newlib/libgloss, which usually doesn't have that
much in the way of chip-specific headers or library
On 14/02/14 20:17, DJ Delorie wrote:
The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those). You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins as inline
I have built a crosscompiler for the MSP430, using a gcc4.9 snapshot
(gcc-4.9-20140112) and the compiler seems OK and builds a simple
blinky LED flashing example.
But my slightly larger example, originally built using Peter Bigot's
mspgcc backend, no longer compiles ...
mspgcc had a number of
The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those). You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins as inline assembler in a common
header file:
static
On Fri, 2014-02-14 at 14:17 -0500, DJ Delorie wrote:
The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those). You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins
