On 27/04/2018 08:47, Joel Sherrill wrote: > On Wed, Apr 25, 2018 at 9:34 PM, Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org>> wrote: > On 25/04/2018 23:48, Joel Sherrill wrote: > > > > To answer your m68k question...I can't find the post to gcc@ but there > are only > > a handful > > of ports using the cc and that is a barrier to future changes. The > m68k, v850, > > and a few > > others are at risk until the port is updated to use more modern gcc > internals. > > It was > > discussed that if these ports are not updated, they will be deprecated. > > > > https://gcc.gnu.org/ml/gcc/2018-01/msg00089.html > <https://gcc.gnu.org/ml/gcc/2018-01/msg00089.html> > > Thanks! We need to watch this topic because the mc68040 is more important > than the mc68060 as a cutoff point. We may also want to consider what to > do about 6830x and cpu32 variants. If we want those to stay, that may increase > the cores needed a lot. That's effectively keeping the 68000 and 68020.
If the Coldfire and some m68k variants are import and we would like to maintain a current gcc on those devices then someone will have to migrate the architecture off cc0 and then to LRA. This may be directly with patches to gcc or via funding. I think it is only a matter of time before our requests are respectfully considered and rejected. We may need to be more pragmatic about how we move to the latest gcc. We may arrive at a point in time where we sit on a older version for architectures we want to support that gcc has dropped. I accept this is a change in our current policy and could result in functionality on those architecture being limited in some way. Chris _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
