<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020 at 5:12 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/09/2020 12:08, Karel Gardas wrote:<br>
<br>
> On 9/11/20 11:40 AM, Sebastian Huber wrote:<br>
><br>
>>> If I'm not mistaken, then this is simply fixed by using other BSP's<br>
>>> variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs<br>
>>> and gcc's lib provides necessary synchronization functions then...<br>
>> The question is if there are RTEMS users in this universe which have x64<br>
>> hardware in use which understands only the pc486/pc586/pc686 instruction<br>
>> sets. This is stuff from the 1990s.<br>
> OK! So first uarch from 2000s is NetBurts and later core. Would you like<br>
> to stop on that? Honestly I'm a bit confused since if you are talking<br>
> about obsoleting '90s then we're in amd64 territory and then the<br>
> question is if to keep 32bit BSP or go straight to 64bit. Unfortunately<br>
> amd64 BSP provides just clock and console IIRC and and in comparison<br>
> with that pc386 supports a lot more features (VESA fb, libbsd)...<br>
><br>
> Or do you propose to just add more BSP variants to pc386 to support<br>
> optimization/isns generation for more modern CPUs and deprecate older<br>
> variants?<br>
I don't know. I think we should somehow figure out which x86 hardware is <br>
in use by RTEMS users.<br></blockquote><div><br></div><div>Agreed. But 

I don't see removing the 32-bit port/BSP.</div><div><br></div><div>it is simple to remove the lower end configurations and</div><div>ensure the lowest one includes the appropriate instructions.</div><div>The cleanup side-effects I see so far are:</div><div><br></div><div>+ remove GCC multilibs < certain level<br></div><div>+ Clean up i386.h in port for removed variants which will at least <br></div><div>   result in removal of port code for bit scan on i386 (i486 had </div><div>   an efficient instruction)</div><div>+ remove BSP code for CPUs < 586 w/o TBR.<br></div><div>+ documenting the rationale clearly in the Users Guide<br></div><div><br></div><div>Removing the BSP config variants below a certain level is trivial</div><div>in code but like deleting sis likely will result in questions and fixing</div><div>odd documentation references for a while.</div><div><br></div><div>FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced</div><div>in 1989. The Pentium was 1993. Remember It's All About the Pentium!</div><div>Pentium II was 1997 and first with SMP but maybe not setting the baseline</div><div>we want.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>