Re: [Mspgcc-users] mspgcc4 MCU support

[Peter B. <pa...@us...>]

Although the older versions did list associate specific errata with specific
chips (hard-coded, again, and only in the assembler), the only erratum I
could ever find that was actually fixed was CPU4, patched by the assembler
during object code generation.  There's a comment in the compiler indicating
plans to record and support chip-specific errata also, but I don't see any
signs that ever happened.

Part of the data I get from TI includes a list of errata for the specific
chip, though it appears to be only valid for the more recent ones.  There's
infrastructure planned and partially implemented to provide the
chip-specific list to the tools that might pay attention to it, once there
really are chip-specific workarounds implemented.  Yes, this would be
automatic, the same way -mmcu=foo is translated into the -mcpu, -mivcnt, and
-mmpy options that actually control code generation: you would get an
-mcpu-errata option added.

Until that point, CPU4 is assumed to be present in any non-MSPX--based chip,
so attempts to push #4 and #8 end up taking one more word than is strictly
necessary on some MCUs (assuming the workaround works, which I haven't
tested).  Most of the other errata involve operations that the compiler will
not generate, such as attempts to call a subroutine using the stack pointer
as the destination.

In other words, uniarch is doing pretty much exactly what mspgcc has always
done.

Peter

On Wed, May 25, 2011 at 5:34 AM, JMGross <ms...@gr...> wrote:

>
> ----- Ursprüngliche Nachricht -----
> Von: Przemek Klosowski
> An: Luis Rossi
> Gesendet am: 24 Mai 2011 22:34:17
>
> > Now the original runtime interface in both versions was based on a
> > flawed model where lot of the MSP chip model-specific info (e.g.
> > differences in periphereal addresses, memory map, etc) was encoded in
> > the compiler. This became unsustainable as the model count balooned to
> > over 300, so MSP developers started shifting the chip dependent parts
> > to per-chip header files, provided by TI;
> > this is what is called 'uniarch'. It is of course based on the current
> > version of GCC, i.e. v.4.
>
> Leaves one question open: what happened to the device-specific
> workarounds for certain errata?
> Does the compiler now generate code that may hit the errata and
> work faulty on some processors?
> Or does the compiler always include the workarounds, leading to
> inefficient code on processors where the errata don't apply?
> Or does the translation from the processor type parameter to the
> uniarch parameters include a 'use workarounds x+y+z' setting?
> (haven't seen that mentioned before)
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Mspgcc-users mailing list
> Msp...@li...
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>