Re: HPPA and Squeeze
Mike Hommey schrieb:
> On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
>> Luk Claes schrieb:
>>> Matthias Klose wrote:
>>>> Grant Grundler schrieb:
>>>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>>>>>> Grant Grundler wrote:
>>>>>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
>>>>>> Note that it's wrong to assume we will come with the answers.
>>>>> I was expecting a summary of specific issues from an organization
>>>>> that claims to operate transperently. The hand waving is easy. But
>>>>> doesn't resolve problems and doesn't meet my expectation of an "open"
>>>>> organization that I've donated money, time, and materials to.
>>>> +1. dropping hppa as a release architecture was not communicated by the release
>>>> team at all. I did spend some time to get gcj / default-jdk working on hppa,
>>>> and some money (buying a new disk for a hppa machine) to help this port. The
>>>> time and the money could have spent better, if d-r would have better
>>>> communicated about their intent.
>>> There are issues with the hppa port where the release team considered
>>> dropping it since 2005 communicated to the porter list...
>>>> hppa is not in a good shape, but there are other architectures which are not
>>>> better (sparc, mips*) from a toolchain point of view. what about these?
>>> I'm not aware of current toolchain issues on sparc and the issues on
>>> mips* still seem to be manageable, no?
>> sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests
>> to move to v9 optimization by default, which requires some work in the compiler.
>> I don't plan to update this for upcoming GCC versions, and there's no interest
>> by upstream to help with this kind of setup. You can't buy v8 software for years
>> now, but afaik all our machines run 64bit kernels. Maybe it's time to
>> acknowledge this, remove sparc from the list of release architectures and go on
>> with sparc64?
> Isn't sparc64 a full 64 bits port ? sparc is unfortunately not amd64,
> where the pros of the added registers overcome the cons of bigger
> pointers. In other words, 64 bits code is slower, fatter and more memory
> hungry than 32 bits code on sparc.
which of the previous statements did you check? E.g. speed comparing the current
32bit v8 with 64bit ultrasparc code?
and even then I wouldn't care that much if it becomes maintainable.