On Fri, Sep 11, 2020, 7:29 PM Chris Johns <chr...@rtems.org> wrote: > On 12/9/20 12:41 am, Joel Sherrill wrote: > > On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas <karel.gar...@centrum.cz > > <mailto:karel.gar...@centrum.cz>> wrote: > > > > On 9/11/20 3:13 PM, Joel Sherrill wrote: > > > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced > > > in 1989. The Pentium was 1993. Remember It's All About the Pentium! > > > Pentium II was 1997 and first with SMP but maybe not setting the > baseline > > > we want. > > > > What about to support in master what man can currently purchase? If > so, > > then based on my limited research it looks like the cpu family > > (orderable) goes back to 2016/2015 which support architecture of > more or > > less NetBurst uarch isn set (both intel and amd). > > > > One exception found is Vertex86 cpus which still sells and boards are > > available and which are compatible only with i586/p5 from as you > noted > > 1993... > > > > Karel: Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86 > > > > If I am reading that right, we may be ok dumping i386 and i486 completely > > and assuming around a Pentium II as default. Rather than a blanket drop > > 32-bit support which kills a LOT of usable functionality, I would rather > find > > a new floor for the CPU model. > > We have been thinking the BSP is working and technically it is not. I > think this > is the issue we should look at first. > > Would adding into the BSP a way of detecting and reporting the CPU details > be > worth doing? We could then match the specifics of the models to the build > of > RTEMS running and if wrong generate a fatal error. This way a user will > know if > they have made a mistake selecting a configuration. If there is no > configuration > they can report the model and we can take a look. I think this would be > better > than an application "almost" working until a specific case like we have > with > this thread is hit. >
I asked on gcc's mailing list and base i386 has no native atomic instructions. Unless we are doing something special for that base multilib, we need to bump up to i486 which does. That may be sufficient to address this situation. Broadly speaking I think there is a minimum model for uniprocessor and another for SMP. Below a certain model SMP did not exist. No one appears to have a solid technical answer beyond that. The rationale for Linux was can't buy CPU model in desktop or server in N years. That's not usually our type of rationale. I suspect if you want a common floor it is a Pentium II. That's where SMP appeared. We can't sanity check the cpu model if we don't know the rules. And if we know the rules, we should just drop those low models. And error if someone runs on an older model. > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
