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 <aurel...@aurel32.net> >>> >>> 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 aurel...@aurel32.net http://www.aurel32.net