<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 12, 2020, 2:41 PM Karel Gardas <<a href="mailto:karel.gardas@centrum.cz">karel.gardas@centrum.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/12/20 5:33 AM, Joel Sherrill wrote:<br>
> I suspect if you want a common floor it is a Pentium II. That's where SMP<br>
> appeared.<br>
> <br>
> We can't sanity check the cpu model if we don't know the rules. And if we<br>
> know the rules, we should just drop those low models. And error if someone<br>
> runs on an older model.<br>
<br>
Well, I think we may also change a perspective this way: RSB supports<br>
pc.set which builds pc686 by default. So this is SMP safe BSP. I guess<br>
that's what majority of user will use as it is very convenient.<br>
<br>
Once someone would like to build variant of pc386 BSP by hand, we may<br>
add clear error/warning about SMP being unsupported on the particular<br>
old BSP.<br>
<br>
Attached patch implements this (clear error). It basically allows<br>
--enable-smp only for pc686 and pcp4 BSPs.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thanks. But in case you missed my comment on the ticket. The multi-lib is built with -mtune not -march so defaults to i386 code. The file gcc/config/i386/t-rtems needs to be changed I think. When gcc changed from -mcpu, we apparently picked the wrong replacement argument. At least that's what I think explains this. </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>
Comments welcome!<br>
<br>
Thanks,<br>
Karel<br>
</blockquote></div></div></div>