x86 c++ exception handling

[Joel Sherrill]

On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas <karel.gardas at 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.

My recollection from SMP testing i386 on qemu was that the lowest CPU
model on Qemu that worked was core2duo which pc586-sse matches for
GCC arguments.

CPU_CFLAGS = -mtune=pentium -march=pentium -msse2

Is that lower than the broken code in GCC? What's the lowest multilib
where the atomics are right? Assuming that it isn't just a bug below that
level.

I would like to pick a floor based on some reasonable rationale
like GCC needs feature X for atomics which appears in CPU model Y.

I don't think Qemu provides a rationale for a floor. Availability of SoCs
for embedded systems seems like a short list and the wikipedia page
doesn't encourage me that they are viable options as most look dead
or barely breathing (parrot is dead):

https://en.wikipedia.org/wiki/List_of_x86_manufacturers

That leaves us with what's the lowest multilib in GCC where atomics
work (or can be fixed, assuming this is a bug).

--joel


> Karel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200911/2e4a2bc1/attachment.html>