RFC: Dropping i386/soft-float and 386ex BSPs

Till Straumann strauman at slac.stanford.edu
Tue Mar 1 19:50:59 UTC 2011


Yep. I don't care much about the BSPs but I believe that the i386 and 
especially the soft-float multilibs still make sense for the reason
given earlier.

Related but IMO even more important:

We currently have the mtune=i486/mtune=pentium/... etc. multilibs
but these are really almost worthless since they still only emit
code that would run on a i386.

I'd propose to change those for march=i486/march=pentium/ etc.
and to adapt the BSP custom files accordingly.

In addition either a march=pentium4 variant or a separate -msse2
multilib may be desirable since RTEMS 4.10 does support sse and sse2.

Personally, I ordinarily create -march=pentium -msse2 multilibs and have
a custom/pc586-sse2.cfg file which uses these so I can benefit
from SSE2 in both RTEMS proper and application code.

-- Till


On 03/01/2011 05:24 PM, Joel Sherrill wrote:
> On 03/01/2011 10:16 AM, Rehab Massoud wrote:
>> Hi,
>>
>> I believe that some of the i386ex and ts386ex BSPs & the
>> i386/soft-float multilib are still used for educational purposes
>> and/or for some simulators.
> On the i386ex and ts386ex BSPs... If they are used, no one has spoken up
> about
> using them or complained about them possibly disappearing. They are in
> 4.10.0.
> If someone wants them back on the CVS head for 4.11, then they need to
> speak up. FWIW I don't think a bug report or improvement has been made to
> these BSPs in YEARS. So my guess is that those two BSPs don't have users
> or they are in maintenance mode with an old RTEMS version.
>
> Till's answer that there is still a CPU core out there without FP
> support was
> sufficient to keep the multilib around. So an old PC with an i386DX w/o FPU
> is still supported.
>> I'd vote for not removing them, and if anyway they will be removed it
>> would be nice to leave a remark somewhere to the latest version that
>> have them as a reference for who may be looking for them.
>>
> The BSP's page in the Wiki is supposed to capture this information.
>> --Rehab
>>
>> On Tue, Mar 1, 2011 at 6:04 PM, Ralf Corsepius
>> <ralf.corsepius at rtems.org <mailto:ralf.corsepius at rtems.org>> wrote:
>>
>> On 02/15/2011 03:34 PM, Joel Sherrill wrote:
>>
>> Hi,
>>
>> I am wondering if the time has come to drop support for
>> x86 w/o HW FPU (e.g. multilibs with software floating
>> point. I do not know of any CPUs currently available
>> which match this profile. If there are any x86
>> w/o HW FPU available, please correct me.
>>
>> Periodically gcc breaks for this because no one else even
>> builds this variation except RTEMS. This alone is not
>> justification but it is a serious hint this configuration is
>> WAY past its prime.
>>
>> From a practical viewpoint, this would likely involve:
>>
>> + dropping the i386ex and ts386ex BSPs
>> + dropping i386/soft-float multilib variant
>> + maybe dropping i486/soft-float
>> + probably moving minimum CPU assumption to 486
>> in GCC for i386-rtems gcc.
>>
>> Any thoughts? Anyone care about i386DX w/o FPU,
>> i386ex, and 486sx?
>>
>>
>> It's been 2 weeks since you asked ...
>>
>> ... Till responded he believes the i386 may have a user-base,
>>
>> ... I would expect these multilibs make sense for testing purposes
>> and could be required by some emulators.
>>
>> ... nobody replied to the proposal to remove "i386ex" and
>> "ts386ex"-BSPs.
>>
>>
>> From this, I conclude,
>> - it's not clear whether these multilib have a user-base.
>>
>> - the i386ex and ts386ex BSPs don't seem to have an active user-base.
>>
>> Proposal: Let's remove the i386ex and tx386ex BSP _NOW_.
>>
>> Should somebody start yelling in near future, we could resort to
>> restoring them in CVS, should somebody start yelling next month,
>> he simply "has lost".
>>
>> Ralf
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>>
>>
>
>




More information about the users mailing list