Re: x86 c++ exception handling

2020-09-12 Thread Joel Sherrill
On Sat, Sep 12, 2020, 3:14 PM Karel Gardas wrote: > On 9/12/20 10:00 PM, Joel Sherrill wrote: > > Thanks. But in case you missed my comment on the ticket. > > Can't find any related ticket in rtems trac. Which one is it? > > > The multi-lib is > > built with -mtune not -march so defaults to i386

Re: x86 c++ exception handling

2020-09-12 Thread Karel Gardas
On 9/12/20 10:00 PM, Joel Sherrill wrote: > Thanks. But in case you missed my comment on the ticket. Can't find any related ticket in rtems trac. Which one is it? > 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 t

Re: x86 c++ exception handling

2020-09-12 Thread Joel Sherrill
On Sat, Sep 12, 2020, 2:41 PM Karel Gardas wrote: > On 9/12/20 5:33 AM, Joel Sherrill wrote: > > I suspect if you want a common floor it is a Pentium II. That's where SMP > > appeared. > > > > We can't sanity check the cpu model if we don't know the rules. And if we > > know the rules, we should

Re: x86 c++ exception handling

2020-09-12 Thread Karel Gardas
Updated patch without debugging leftover. On 9/12/20 9:41 PM, Karel Gardas wrote: > On 9/12/20 5:33 AM, Joel Sherrill wrote: >> I suspect if you want a common floor it is a Pentium II. That's where SMP >> appeared. >> >> We can't sanity check the cpu model if we don't know the rules. And if we >>

Re: x86 c++ exception handling

2020-09-12 Thread Karel Gardas
On 9/12/20 5:33 AM, Joel Sherrill wrote: > I suspect if you want a common floor it is a Pentium II. That's where SMP > appeared. > > We can't sanity check the cpu model if we don't know the rules. And if we > know the rules, we should just drop those low models. And error if someone > runs on an o

Re: x86 c++ exception handling

2020-09-11 Thread Joel Sherrill
On Fri, Sep 11, 2020, 7:29 PM Chris Johns wrote: > On 12/9/20 12:41 am, Joel Sherrill wrote: > > On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas > > wrote: > > > > On 9/11/20 3:13 PM, Joel Sherrill wrote: > > > FWIW i386 is an 80s CPU introduced in 1985. i486

Re: x86 c++ exception handling

2020-09-11 Thread Chris Johns
On 12/9/20 12:41 am, Joel Sherrill wrote: > On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas > 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. Remembe

Re: x86 c++ exception handling

2020-09-11 Thread Joel Sherrill
On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas 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 setti

Re: x86 c++ exception handling

2020-09-11 Thread Karel Gardas
On 9/11/20 4:06 PM, Karel Gardas wrote: > One exception found is Vertex86 cpus which still sells and boards are Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listi

Re: x86 c++ exception handling

2020-09-11 Thread Karel Gardas
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 wh

Re: x86 c++ exception handling

2020-09-11 Thread Joel Sherrill
On Fri, Sep 11, 2020 at 5:12 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 11/09/2020 12:08, Karel Gardas wrote: > > > On 9/11/20 11:40 AM, Sebastian Huber wrote: > > > >>> If I'm not mistaken, then this is simply fixed by using other BSP's > >>> variant? Like pc486/pc586/pc

Re: x86 c++ exception handling

2020-09-11 Thread Sebastian Huber
On 11/09/2020 12:08, Karel Gardas wrote: On 9/11/20 11:40 AM, Sebastian Huber wrote: If I'm not mistaken, then this is simply fixed by using other BSP's variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs and gcc's lib provides necessary synchronization functions then... The

Re: x86 c++ exception handling

2020-09-11 Thread Karel Gardas
On 9/11/20 11:40 AM, Sebastian Huber wrote: >> If I'm not mistaken, then this is simply fixed by using other BSP's >> variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs >> and gcc's lib provides necessary synchronization functions then... > The question is if there are RTEMS use

Re: x86 c++ exception handling

2020-09-11 Thread Sebastian Huber
On 11/09/2020 11:21, Karel Gardas wrote: There is also an associated ticket: http://devel.rtems.org/ticket/2830 I think the i386 BSPs need to be cleaned up to use an instruction set which fits current the x86 hardware. I mean hardware which is still in use and not some stuff from the 1990s.

Re: x86 c++ exception handling

2020-09-11 Thread Karel Gardas
On 9/11/20 11:12 AM, Sebastian Huber wrote: > On 11/09/2020 10:48, Heinz Junkes wrote: > >> Here is a mail I received from a colleague. >> >> It concerns thereby an "old" problem which seemed already solved? >> >> FYI. I can run the unit tests, but I'm seeing a couple of hangs. >> The first I'm lo

Re: x86 c++ exception handling

2020-09-11 Thread Sebastian Huber
On 11/09/2020 10:48, Heinz Junkes wrote: Here is a mail I received from a colleague. It concerns thereby an "old" problem which seemed already solved? FYI. I can run the unit tests, but I'm seeing a couple of hangs. The first I'm looking at is epicsTimeTest which seems to be related to c++ exc