precision in hardware.
Another name could be powerpc_spe.
Sebastian
From 7638777164cc938819622745be550ed51aca94b7 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior bige...@linutronix.de
Date: Tue, 2 Feb 2010 12:14:56 +0100
Subject: [PATCH] Add gnuspe Debian arch
its gcc target is powerpc-linux
tags 568123 + patch
thanks
* Sebastian Andrzej Siewior | 2010-02-02 15:58:29 [+0100]:
Another name could be powerpc_spe.
Okay powerpc-spe is not working because spe is not a CPU.
Besides spe as addition to the gnu name there is eabi (armel) and lp
(lpia). Based on this I come up
* Guillem Jover | 2010-02-16 15:22:55 [+0100]:
Hi!
Hi,
Besides spe as addition to the gnu name there is eabi (armel) and lp
(lpia). Based on this I come up with powerpcgspe. I added a g there
because ps3 cell blades are powerpcs and have spe units. This should
avoid confusion.
Sorry, don't
* Guillem Jover | 2010-02-17 21:51:37 [+0100]:
Yesterday did some superficial research, and I might have
missunderstood stuff, but isn't the SPE in the E500 the same as the one
on the Cells?
Nope, tottally different thing: A Cell CPU (the PPU) has (usually) 8
SPEs (and SPE here is an acronym for
* Moffett, Kyle D | 2010-03-23 17:52:57 [-0500]:
Ah, my apologies. I'd actually already seen that one, but wasn't paying
enough attention when submitting the bugreport.
I saw in your earlier bug report that you don't have everything built
(yet). At [0] I have more or less complete port of an
* Moffett, Kyle D | 2010-03-24 19:28:06 [-0500]:
So it is my belief that e500 is the correct and appropriate name for the
architecture.
Which brings me to the following question: There are currently two types
of the core: e500v1 and e500v2. The latter implements also the floating
point type
* Moffett, Kyle D | 2010-03-25 17:49:33 [-0500]:
We can just use --enable-e500-double when building (recent?) GCC.
Yep, looks good.
Ok, so hopefully we can all agree on e500v2? That's the name I'm going to
go ahead and use in my newest build-cycle.
Yep, I think so. However we will see what will
* Guillem Jover | 2010-04-16 09:01:16 [+0200]:
Hi!
Hi Guillem,
On Thu, 2010-02-18 at 11:38:34 +0100, Sebastian Andrzej Siewior wrote:
- variant two: a operation like a + b where we call in a library to
compute the floating point operation. Here we would put the
computation itself
* Moffett, Kyle D | 2010-04-22 19:17:17 [-0500]:
Not really... If you build GCC with --enable-e500_double it produces code
that is not quite binary compatible with code generated without that option,
because it indicates that the GPRs have an extra shadow 32 high bits that
can be only accessed by
, I'll gladly add the new architecture.
Yes, double precision is what we want, so here you go:
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
From: Kyle Moffett kyle.d.moff...@boeing.com
Date: Thu, 29 Apr 2010 21:47:25 -0400
Subject: [PATCH] powerpcspe: New unofficial Debian
Package: inn2
Version: 2.6.1-1
Severity: serious
In the last build on buildds [0] there is piece:
|dh_shlibdeps --exclude=/usr/lib/news/bin/auth/passwd/auth_krb5 -- \
| -dSuggests
/«PKGBUILDDIR»/debian/inn2/usr/lib/news/bin/auth/passwd/auth_krb5 \
|
Can this be closed?
Sebastian
Package: dpkg
Version: 1.19.7
Severity: wishlist
I've been thinking about parallel decompression for dpkg/xz. Is there
any interest in doing this? I hacked parallel-unxz [0] in the meantime
to see what is missing from the API point of view (query block offsets
is missing).
My idea of
On 2018-03-11 21:51:05 [+0100], Balint Reczey wrote:
> For the recompressed firefox .deb (Ubuntu's
> firefox_58.0.2+build1-0ubuntu0.17.10.1_amd64.deb) increased ~9% in
> size but decompressed in <20% of the original time:
So you are saying that the decompression speed that is the bottleneck
here?
On 2020-06-16 03:36:22 [+0200], Guillem Jover wrote:
> Hi!
Hi,
> > I've been thinking about parallel decompression for dpkg/xz. Is there
> > any interest in doing this? I hacked parallel-unxz [0] in the meantime
> > to see what is missing from the API point of view (query block offsets
> > is
On 2020-04-09 19:43:34 [+0800], Paul Wise wrote:
> On Thu, 9 Apr 2020 11:45:49 +0200 Sebastian Andrzej Siewior wrote:
>
> > Can this be closed?
>
> Since the patch and feature hasn't been merged, I don't think so.
What about now given that #956452 has been closed?
Sebastian
Package: dpkg
Version: 1.22.4
Severity: important
xz-utils 5.6.0 has been uploaded to unstable. A changed behaviour of
`xz' is now that mutlti threaded compress/ decompression is now enabled
by default. This in turn leads to warnings if the requested amount of
memory exceeds the available amount.
On 2024-02-26 19:23:58 [+0100], Guillem Jover wrote:
> Hi!
Hi Guillem,
> > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the
> > memory usage limit of 1400 MiB
> > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the
> > memory usage limit of 1400 MiB
>
On 2024-02-26 20:46:43 [+0100], Guillem Jover wrote:
> > > Ignoring stderr could be a workaround, but I'd need to do something as
> > > well for the libdpkg code and the perl code calling xz, which will get
> > > very annoying.
> > >
> > > This is also going to get in the way of migrating both xz
19 matches
Mail list logo
