One reason it matters is it seems TI is moving to releasing binary-only
modules such as MSPMATHLIB. Much of the RF support for MSP430 devices is
similarly available only in binary form, though most of this has been from
third-party vendors. mspgcc has never been able to use these tools because
of ABI differences.
A benefit to the Red Hat / TI collaboration is that Red Hat was given
access to ABI information that was not available to mspgcc developers. Had
existence of such an ABI been public knowledge compatibility might have
happened years ago (certainly, I would have considered it at the point of
doing MSP430X enhancements had I been aware an ABI had been defined and
shared between TI/CCS and IAR).
Peter
On Mon, Jul 8, 2013 at 6:38 AM, David Brown <da...@westcontrol.com> wrote:
> On 08/07/13 13:06, Dmitry wrote:
> > Hi All,
> >
> > I'm quite distant from MSPs now yet just interesting -
> > is now gcc's ABI compatible with others (like IAR CS, etc.) ?
> >
> > Cheers,
> > Dmitry.
> >
>
> Why is that likely to matter? Are you mixing code compiled with one
> compiler with code compiled with another?
>
> It matters that the headers are the same (or at least compatible), so
> that you can use the same code to access peripherals in the same way.
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
