----- 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
