On 3/22/2015 5:39 PM, Georg-Johann Lay wrote: > Joel Sherrill a écrit: >> I thought I would pass along a couple of data points from >> the *-rtems targets. >> >> Fourteen *-rtems target build OK on the head. The following >> do not even complete building gcc+newlib. >> >> v850 - PR65501. New and must be relatively recent. I built >> a C/C++ toolset on January 15. >> m32c - PR63683. Reported against 4.9 branch. DJ may have a >> patch for this. >> >> The avr is still broken. I don't know tha t it is worth the trouble >> to even dig up the PRs anymore. > Like some other 3ary platforms, avr is plagued by spill fails, > summarized as meta PR56183. This is what we seem to run into over and over. > Apart from that the device selection scheme changed some while ago: > Setting -mmcu= will trigger a target specific spec file to be applied. > The initial version didn't factor out libc and focused solely on > avr-libc. I tried to rectify that in PR65296, i.e. spec files generator > is now sensitive to avr-*-rtems configuration. What does not yet work > is spaces in the installation path. Well no one should do that. :) > Some of the avr core architectures are not well suited for "big" system > like rtems + newlib. There are even devices without RAM so that for > some of the core architecture it makes hardly any sense to build newlib > variants for them, in particular "avr1" and "avrtiny" maybe even more. Funny to refer to rtems as a big system but we are still working to push down further and further. The ATMega128 is the smallest target CPU we even attempt right now. It is a work in progress and gives us a goal for reducing footprint.
Our focus on smaller CPUs also helps since we target 16, 32, and 64-bit SPARC V9. This helps push the odd code that assumes CPU word size. > If parts of the device spec files are not generated as needed by rtems, > it might be the case that the avr backend needs more adjustments, in > particular specs.h, rtems.h, gen-avr-mmcu-specs.c, maybe also t-multilib > and its generator genmultilib.awk. I don't think we have seen any of this. We might even benefit from trimming our multilibs to the larger models. > Johann > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
