Thanks for your input. (Note: Detailed discussion of the mechanics of
reconciling mspgcc/mspgcc4/msp430x is intended to be held on mspgcc-devel.
Please subscribe to that list if you're specifically interested in this
topic.)
Re errata: to whatever extent binutils or mspgcc{3,4} already supports
chip-specific errata I'll have to retain that. To whatever extent I can
come up with a way to add support, I'll do so. But I expect this'll be an
on-demand sort of thing: having gotten away from the need to read every data
sheet to figure out where the flash sections start, I'm not going to start
reading every errata document to figure out what's broken on which revision
of which chip.
Names are TBD, but yes, I foresee something like:
-msp430=cpu (cpux, cpuxv2)
-mpy=none (mpy, mpy32)
if I choose to be "cute" and use the "m" from the machine-specific option as
part of the option name, at least within gcc. Gonna have to review prior
art to see what's the best solution.
I'm going to do what I can to delay resolving peripheral addresses to the
final link phase. Having control of the standard header files should make
that easier.
I'm very sympathetic to your views on watchdogs, and would like to make it
easier to control that function. However, a large portion of the MSPGCC
user community is completely ignorant of the presence of WDT because it's
always been automatically turned off for them. I'm just not willing to deal
with the fallout from changing the existing default behavior.
Peter
On Tue, Aug 10, 2010 at 5:48 AM, JMGross <msp...@grossibaer.de> wrote:
>
> ----- Ursprüngliche Nachricht -----
> Von: Peter Bigot
> Gesendet am: 10 Aug 2010 01:17:03
>
> > What I propose to do instead is reduce the machines to those required
> > reflect the chip CPU architecture (MSP430, MSP430X, MSP430XV2), and not
> try
> > to indicate things like available peripherals and the like as distinct
> > machine types. The only other feature that affects generated code is
> > presence/absence of hardware multiply support (none, MPY, MPY32), and I
> > think that can be done without having to add another axis to the
> > architecture matrix.
>
> This is AFAIK the only part that needs care, besides the X/XV2 thing.
> Of course there are the errata which should be taken care of, or the
> compiler
> will possibly create code that will simply crash. This is mostly X/XV2
> related
> stuff (forbidden sequences of instruction, necessary NOPs, not doing some
> PC/SP manipulations etc.
> Unfortunately, this is machine dependent. SOmetimes it applies to whole
> families or groups of processors, sometimes only single ones are affected.
>
> I fear this could break the 'slim' concept you want to introduce.
>
> There can be, however, basic support for yet unsupported machines by
> supporting the base architecture and MPY through parameters or
> generic machine types. This allows compiler/assembler support for new
> processors. (of course, linker scripts and include files are necessary, but
> these can be written by 'normal' people)
>
> I propose that an unknown mmcu will recognize a -core and -mpy parameter
> and use the generic machines if given (or throw an error or assume non-X no
> MPY if not set). This way it would be compatible to the current mechanisms
> of forking inside header files etc.
>
> > If this works, the guts of binutils (the assembler and linker) becomes
> > independent of specific chip details, except for the location of ld
> sections
> > (RAM, ROM, etc) and the base address of a few peripherals. Since TI's
> now
> > providing me with a table containing, for each chip, the necessary
> addresses
> > all the way down to individual info sections, it should be much easier to
> do
> > this; plus, I believe it can be done in a way that allows new chips to be
> > targeted without having to rebuild the toolchain.
>
> Because of the silicon errata this can prove difficult to impossible.
> Except there is a way to manually set errata flags.
> But I don't know whether TI has a 'global' errata naming. I fear the
> errata names are independent for each group of processors and same name
> may mean different things for different processors.
>
> > Some of the questions that arise include:
>
> > *) Is it necessary to retain support for the existing machine definitions
> in
> > binutils, at least to allow linking to legacy libraries that can't be
> > rebuilt?
>
> I don't think existing libraries are a problem.
> If they cannot be rebuilt, they'll work or not.
> machine-dependent defines are already resolved during compilation.
> All that's left is resolving the symbols and this is a
> machine-independent process. Either they are provided in the
> (properly) compiled project object files or they are missing and
> linking is impossible.
> Some special code (like the startup) depends on machine-dependent
> information, but this is usually part of the linker scripts.
>
> > *) Can critical values like the address of the watchdog reset or multiply
> > peripheral registers be correctly resolved using separate compilation,
> in
> > such a way that attempts to link object files built for incompatible
> > platforms fail with an understandable error message?
>
> I know that the compiler-generated MPY16 inline code linked fine on
> machines with MPY32. Only the libraries didn't work as they were built
> with different register addresses. If global, unresolved symbols were used
> in these functions instead of static addresses, this should be doable.
>
> I can imagine a compiler attribute that forces a variable to be extern even
> if
> it has been defined with a 'fixed' location in the header files.
> So the linker can clean up things.
>
> Also, the functions using the MPY (or not) can be named differently, so the
> compiler will generate different function calls depending on whether MPY16
> is used or MPY32 or none (it already does so for none and MPY16).
> If they are in different compilation units, the linker will only link the
> required
> ones.
> This unfortunately won't work for precompiled library functions which use
> the MPY.
> Another approach would be to add different libraries which are selected
> depending on the MPY usage.
>
> There is, however, a problem with the watchdog register, which is
> differently
> for different MSPs.
>
> There I propose removing it completely from the init code.
> It should be documented that the user must provide a proper
> code snippet if he needs the WDT disabled at startup.
> Personally, I strongly discourage stopping the WTD at startup, as this
> renders the WDT practically useless. Either it is on all the time without
> exception, or you do not really need it at all.
>
> On newer MSPs, the default times are long enough so the WDR won't
> trigger even if you copy 18k of data (which is the maximum ram in any
> MSP so far). The timeout is long enough for even copying hundreds of
> kB.
>
> > *) What else am I not thinking of?
>
> Most problems are encountered during project progress.
> That's an inevitable rule.
>
> JMGross
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
