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 <msp...@grossibaer.de> 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
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
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
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
