<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020, 7:29 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/9/20 12:41 am, Joel Sherrill wrote:<br>
> On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas <<a href="mailto:karel.gardas@centrum.cz" target="_blank" rel="noreferrer">karel.gardas@centrum.cz</a><br>
> <mailto:<a href="mailto:karel.gardas@centrum.cz" target="_blank" rel="noreferrer">karel.gardas@centrum.cz</a>>> wrote:<br>
> <br>
>     On 9/11/20 3:13 PM, Joel Sherrill wrote:<br>
>     > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced<br>
>     > in 1989. The Pentium was 1993. Remember It's All About the Pentium!<br>
>     > Pentium II was 1997 and first with SMP but maybe not setting the baseline<br>
>     > we want.<br>
> <br>
>     What about to support in master what man can currently purchase? If so,<br>
>     then based on my limited research it looks like the cpu family<br>
>     (orderable) goes back to 2016/2015 which support architecture of more or<br>
>     less NetBurst uarch isn set (both intel and amd).<br>
> <br>
>     One exception found is Vertex86 cpus which still sells and boards are<br>
>     available and which are compatible only with i586/p5 from as you noted<br>
>     1993...<br>
> <br>
> Karel: Typo correction: Vortex86: <a href="https://en.wikipedia.org/wiki/Vortex86" rel="noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Vortex86</a><br>
> <br>
> If I am reading that right, we may be ok dumping i386 and i486 completely<br>
> and assuming around a Pentium II as default. Rather than a blanket drop <br>
> 32-bit support which kills a LOT of usable functionality, I would rather find<br>
> a new floor for the CPU model. <br>
<br>
We have been thinking the BSP is working and technically it is not. I think this<br>
is the issue we should look at first.<br>
<br>
Would adding into the BSP a way of detecting and reporting the CPU details be<br>
worth doing? We could then match the specifics of the models to the build of<br>
RTEMS running and if wrong generate a fatal error. This way a user will know if<br>
they have made a mistake selecting a configuration. If there is no configuration<br>
they can report the model and we can take a look. I think this would be better<br>
than an application "almost" working until a specific case like we have with<br>
this thread is hit.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">That may be sufficient to address this situation.</div><div dir="auto"><br></div><div dir="auto">Broadly speaking I think there is a minimum model for uniprocessor and another for SMP. Below a certain model SMP did not exist. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I suspect if you want a common floor it is a Pentium II. That's where SMP appeared.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div></div>