In the past I used the normal PowerPC port which was sufficient for most
things, however it got very slowly once it came to floating point.
Starting with gcc 4.2 (I think but starting with Lenny is correct) the
gcc starts using the lwsync opcode more frequently and every C++ program
is effected via libstdc++ as you can see in #495120. Replacing the opcode
in the PowerPc port would cost performance on all other PowerPCs.
Now, I wanted to ask if there are more people that could be interrested
in this port.
Any comments are welcome.
[0] http://download.breakpoint.cc/debian/linutronix-lenny-gnuspe/
[1] http://en.wikipedia.org/wiki/PowerPC_e500
Sebastian
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
I seriously doubt it's going to be interesting for Debian as a whole,
since book E is so much from the embedded world :) You could try
debian-embedded@, they might be interested to merge your port into
their efforts.
--
Regards, Wartan.
>On Tue, Feb 24, 2009 at 5:16 PM, Sebastian Andrzej Siewior
><seba...@breakpoint.cc> wrote:
>> Hello PowerPC team,
>>
>> I have a Lenny snapshot of a new Debian architecture called gnuspe
>> located at [0]. I haven't announced it anywhere (until now). It is
>> called gnuspe because the gcc triplet is powerpc-linux-gnuspe-. This
>> port is for all PowerPCs which have an E500 core [1]. The main important
>> differences between PowerPC and this one are:
>
>I seriously doubt it's going to be interesting for Debian as a whole,
>since book E is so much from the embedded world :) You could try
ARM, M68K and most MIPS are embedded es well and there is an offical
Debian port. I don't understand your point. Are you pointing out that
there will be a tiny user base?
>debian-embedded@, they might be interested to merge your port into
>their efforts.
okay.
Sebastian
Well, for sure I can't speak for all the users, but I can forsee
problems setting up a reasonably fast buildd, providing storage space
for a full-blown port and so on. MIPS is already a PITA for the buildd
maintainers, and m68k is no more exactly because of that. However, I
might be wrong :)
--
Regards, Wartan.
On Tue, Feb 24, 2009 at 03:16:02PM +0100, Sebastian Andrzej Siewior wrote:
> Hello PowerPC team,
>
> I have a Lenny snapshot of a new Debian architecture called gnuspe
> located at [0]. I haven't announced it anywhere (until now). It is
> called gnuspe because the gcc triplet is powerpc-linux-gnuspe-. This
> port is for all PowerPCs which have an E500 core [1]. The main important
> differences between PowerPC and this one are:
Are you building userspace with SPE instructions enabled, or are you
using only the base power ISA for the binaries?
> - the "normal" FPU unit is not present. Instead the APU offers float
> point operations. This is _not_ SW-emulation it is HW support but
> different at the assembly level. The ABI is also different (there are
> no dedicated FPU regs).
> - those opcodes (or some of them) have the same binary representation
> like AltiVec. The spec forbids AltiVec.
No BookE cores have altivec, besides I don't think the base distro uses
any altivec since it would not be usable on IBM big iron before power6,
nor on 603/604 (G3) systems.
> - It is not 100% compatible with the PowerPC ISA. An opcode, lwsync,
> is not supported by the core and raises an invalid opcode exception.
> This is a core bug.
This is not a core bug per se, but somewhat annoying interpretation of
the spec by FSL, as far as I know?
> In the past I used the normal PowerPC port which was sufficient for most
> things, however it got very slowly once it came to floating point.
> Starting with gcc 4.2 (I think but starting with Lenny is correct) the
> gcc starts using the lwsync opcode more frequently and every C++ program
> is effected via libstdc++ as you can see in #495120. Replacing the opcode
> in the PowerPc port would cost performance on all other PowerPCs.
Another alternative is to have the kernel rewrite the instruction to be
a sync instead (which is the expected behaviour on cores not implementing
lwsync), when the fault is taken.
> Now, I wanted to ask if there are more people that could be interrested
> in this port.
>
> Any comments are welcome.
I don't have a personal stake in this, but I think a regular booke port
(compiled for softfpu and no SPE) would be more valuable, since that
would also run on IBM/AMCC 4xx CPUs.
-Olof
>Hi,
Hi,
>On Tue, Feb 24, 2009 at 03:16:02PM +0100, Sebastian Andrzej Siewior wrote:
>> Hello PowerPC team,
>>
>> I have a Lenny snapshot of a new Debian architecture called gnuspe
>> located at [0]. I haven't announced it anywhere (until now). It is
>> called gnuspe because the gcc triplet is powerpc-linux-gnuspe-. This
>> port is for all PowerPCs which have an E500 core [1]. The main important
>> differences between PowerPC and this one are:
>
>Are you building userspace with SPE instructions enabled, or are you
>using only the base power ISA for the binaries?
SPE enabled.
>> - the "normal" FPU unit is not present. Instead the APU offers float
>> point operations. This is _not_ SW-emulation it is HW support but
>> different at the assembly level. The ABI is also different (there are
>> no dedicated FPU regs).
>> - those opcodes (or some of them) have the same binary representation
>> like AltiVec. The spec forbids AltiVec.
>
>No BookE cores have altivec, besides I don't think the base distro uses
>any altivec since it would not be usable on IBM big iron before power6,
>nor on 603/604 (G3) systems.
SDL/KDE for instance, has AltiVec auto detection via vor v0,v0,v0. If
that one fails the AltiVec support is disabled. Fortunately that one
does not clash with any SPE opcodes. That's what I meant here.
>> - It is not 100% compatible with the PowerPC ISA. An opcode, lwsync,
>> is not supported by the core and raises an invalid opcode exception.
>> This is a core bug.
>
>This is not a core bug per se, but somewhat annoying interpretation of
>the spec by FSL, as far as I know?
The last time I heared Benh talking about, he was refering to it as a
core bug.
>> In the past I used the normal PowerPC port which was sufficient for most
>> things, however it got very slowly once it came to floating point.
>> Starting with gcc 4.2 (I think but starting with Lenny is correct) the
>> gcc starts using the lwsync opcode more frequently and every C++ program
>> is effected via libstdc++ as you can see in #495120. Replacing the opcode
>> in the PowerPc port would cost performance on all other PowerPCs.
>
>Another alternative is to have the kernel rewrite the instruction to be
>a sync instead (which is the expected behaviour on cores not implementing
>lwsync), when the fault is taken.
Yep, that would fix at a price of a fault handler.
>> Now, I wanted to ask if there are more people that could be interrested
>> in this port.
>>
>> Any comments are welcome.
>
>I don't have a personal stake in this, but I think a regular booke port
>(compiled for softfpu and no SPE) would be more valuable, since that
>would also run on IBM/AMCC 4xx CPUs.
You mean a normal PowerPC port with soft float instead of hardfloat?
>-Olof
Sebastian
On Tue, Feb 24, 2009 at 03:16:02PM +0100, Sebastian Andrzej Siewior wrote:
> I have a Lenny snapshot of a new Debian architecture called gnuspe
> located at [0]. I haven't announced it anywhere (until now). It is
> called gnuspe because the gcc triplet is powerpc-linux-gnuspe-.
You did well to announce it there.
> Now, I wanted to ask if there are more people that could be interrested
> in this port.
I am interested in Book-E for quite some time already, but the cost of
Freescale evalboards prohibits me from starting a Debian port. I would
rather call it "ppce" or "powerpce" which is a bit less confusing than
"gnuspe", WRT other architectures.
What kind of hardware are you using?
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Debian Developer
`- Unix Sys & Net Admin
On Tue, Feb 24, 2009 at 10:44:54PM +0300, Wartan Hachaturow wrote:
> On Tue, Feb 24, 2009 at 10:07 PM, Sebastian Andrzej Siewior
> <seba...@breakpoint.cc> wrote:
> > ARM, M68K and most MIPS are embedded es well and there is an offical
> > Debian port. I don't understand your point. Are you pointing out that
> > there will be a tiny user base?
>
> Well, for sure I can't speak for all the users, but I can forsee
> problems setting up a reasonably fast buildd, providing storage space
> for a full-blown port and so on. MIPS is already a PITA for the buildd
> maintainers, and m68k is no more exactly because of that. However, I
> might be wrong :)
You are probably misinformed.
Debian has powerful mips buildds[1][2][3][4]. Why would they be a PITA
to build Debian?
You also might want to check [5][6]. As you can see, Freescale
PowerQUICC III processors (and later QorIQ processors) are largely
sufficient to build Debian natively.
Actual mips and powerpc cannot be compared with legacy m68k which is
no longer even produced nowadays.
The open question is when we will get non-NDA commercial public
hardware to play with, because evalboards at $4000 USD do not qualify
for an official Debian port.
Cheers,
[1] <http://db.debian.org/machines.cgi?host=mayer>
[2] <http://db.debian.org/machines.cgi?host=mayr>
[3] <http://db.debian.org/machines.cgi?host=rem>
[4] <http://db.debian.org/machines.cgi?host=ball>
[5] <http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8536E>
[6] <http://www.freescale.com/files/32bit/doc/fact_sheet/MPC8536DSFS.pdf>
We are in the process to get hardware for this which can be made
accessible for developers. Give us a couple of days to sort that out.
Thanks,
tglx
Well, in case you are interested (I would but I don't have the time)
it seems that Freescale is offering a somwhat cheaper board:
Dual core (not found the frequency) with 1 GB of RAM, still ~$600 (they
could/should have saved on the Ethernet switch, why 6 ports ?),
but the other one is $3500...
Regards,
Gabriel
Nice news! I will probably get one.