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