Re: [Qemu-devel] [PATCH 1/6] softfloat: remove HPPA specific code

[Aurelien Jarno]

On Tue, Jan 04, 2011 at 11:53:01PM +0100, Andreas Färber wrote:
> Am 04.01.2011 um 21:07 schrieb Aurelien Jarno:
>
>> On Tue, Jan 04, 2011 at 08:54:04PM +0100, Andreas Färber wrote:
>>> Am 03.01.2011 um 15:34 schrieb Aurelien Jarno:
>>>
>>>> We don't have any HPPA target, so let's remove HPPA specific code.  
>>>> It
>>>> can be re-added when someone adds an HPPA target.
>>>>
>>>> Signed-off-by: Aurelien Jarno <address@hidden>
>>>
>>> There actually is such a project on SourceForge [1, 2].
>>
>> The project hasn't seen any commit for 1.5 year. It looks like dead.
>
> As we have begun to collect in the forks thread, there's many multi- 
> month-old repos around with features not in upstream. Even "dead"  
> doesn't mean useless. Considering that linux-user is incomplete even on 
> amd64, I don't see why we shouldn't have target-hppa in master. Then it 
> would at least allow for compile-testing and would benefit from general 
> refactoring rather than bitrotting. All it takes is someone to step up 
> for upstreaming patches, and I do not feel qualified to volunteer for 
> that architecture.

You are comparing apples and oranges, forks and dead code. linux-user on
x86_64 is able to run binaries. HPPA code has still to be ported to TCG.
Yes it still uses dyngen.

>>> Does it really hurt to leave TARGET_HPPA around?
>>
>> It means writing code for this target, in the current case for
>> floatXX_maybe_silence_NaN(). I don't see the point of writing and
>> maintaining unused code if we don't get the insurance the target is
>> going to be merged later. Unless someone volunteer to maintain this
>> code.
>
> For new code,
>
> #elif defined(TARGET_HPPA)
> #error Target not supported yet.
> ...
>
> shouldn't be too much work if you already handle architecture specifics 

That makes work, code less readable, without any benefit. The code should
be added when we have a real fork to reintegrate back.

Should we already start adding code provision about TARGET_DPTR (the
marvelous CPU I have dreamed last night)? And about TARGET_IPU (the one
I have dreamed the night before)?

> and is different from ripping out existing code, as you seemed to suggest 
> for linux-user.

Strange interpretation for "I personnally don't have a lot of interest
in linux-user, so I will let the linux-user maintainer (Cc) to decide."

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net