x86 c++ exception handling
Chris Johns
chrisj at rtems.org
Sat Sep 12 00:28:50 UTC 2020
On 12/9/20 12:41 am, Joel Sherrill wrote:
> On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas <karel.gardas at centrum.cz
> <mailto: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.
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.
Chris
More information about the devel
mailing list