similar to: Altivec Optimizations

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

--- Chris Csanady <cc@137.org> wrote: > Hi, > > I have been playing with Altivec, and I rewrote a couple of the > routines > in assembly. Looking at the archives, I noticed that there may > already > be some effort on this. Anyways... > > Right now, I have two routines working. They need to be cleaned up, > made > relocatable, and documented; otherwise,

I've had this a long time but haven't submitted it yet. I've tried to mirror the ia32 setup, so there should be a new subdirectory src/libFLAC/ppc . The first two attachments go there. The third is a context diff for src/libFLAC/Makefile.am . I have some more modified files, which I figured I'd submit after the above are checked in and working for somebody other than me. If you

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

On Thu, 27 Jan 2005, John Steele Scott wrote: > That looks fine to me as well. However, the best solution is something which > Luca suggested a few months ago, which is to use the functions defined in > altivec.h. These are C functions which map directly to Altivec machine > instructions. I am willing to help out, but I don't find the current lpc_asm.s > very easy to follow, and

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

Howdy. I'm working on Altivec versions of some of the libFLAC functions. I figured the best candidates would be those that had MMX/SSE/3dnow versions, and I picked FLAC__lpc_restore_signal() to do first, since it's relatively simple. In stepping through some runs, it appears that 'order' mod 4 is always 0. Is that guaranteed, either by the format or by higher functions in the

hola a todos y todas, Estoy haciendo un estudio sobre las mareas y tengo dos variables que quiero relacionar, la altura del mar y el tipo de marea viva, muerta o intermedia. Unos datos simulados podrían ser: > datos <- data.frame(v1=sin(1:50), v2= rep(c("a","b","c"), each = 5, > len = 50)) Ahora mi pregunta, si dibujo la altura de la marea sería:

Dear R People: So thanks to your help, I have the following: > dog3.df <- read.delim("c:/Users/erin/Documents/dog1.txt",header=FALSE,sep="\t") > dog3.df V1 V2 1 1/1/2000 dog 2 1/1/2000 cat 3 1/1/2000 tree 4 1/1/2000 dog 5 1/2/2000 cat 6 1/2/2000 cat 7 1/2/2000 cat 8 1/2/2000 tree 9 1/3/2000 dog 10 1/3/2000 tree 11 1/6/2000 dog 12 1/6/2000

Sorry for the delay in getting back to you., I was working on something else and just now got FLAC to work. Ok., FLAC files are playing now :) Cheers. There is a slight noise happening in the background., which i'm figuring out. I hope that it'll be solved soon. However, i wanted to know if there are any ARM specific optimizations that can be done. The processor is a 166MHz processor. Do

Dear experts, I'm new in R and trying to learn by writing a version of the Perceptron Algorithm. How can I tell in the code below to stop the iteration when the condition in the "for loop" is not satisfied for all training examples? Thanks in advance for your help! ## Generate a linearly separable data set in R2 sample <- as.data.frame(cbind(runif(n=100),runif(n=100)))

Hi all, I'm trying to compile the flac-1.1.1 tarball on a Linux PPC system (a G3 iBook running Debian Testing). Configure is fine, but make bombs out almost immediately with: lpc_asm.s: Assembler messages: lpc_asm.s:1: Error: junk at end of line, first unrecognized character is `l' lpc_asm.s:2: Error: junk at end of line, first unrecognized character is `C' lpc_asm.s:4:

https://ffmpeg.org/pipermail/ffmpeg-user/2015-April/025906.html https://trac.ffmpeg.org/ticket/4421 Some ffmpeg-encoded FLAC files can be successfully decoded by ffmpeg, but not FLAC. So it's either a bug somewhere (presumably in ffmpeg, but maybe in FLAC), or ffmpeg treats something differently than FLAC. libFLAC has routines like FLAC__lpc_compute_residual_from_qlp_coefficients and

lvqcl wrote: > FLAC__fixed_restore_signal() is a part of flac *de*coder, so it makes > sense to test it on different architectures (ARM, MIPS?). But I have no > idea how to make it. Yes, but the code in FLAC__fixed_restore_signal() is (ignoring identifier name differences) identical to FLAC__fixed_compute_residual(), Maybe I should just publish my micro benchmarking code as part of the

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

finished hooking up the altivec stuff so it works in ProjectBuilder. I ran a test, doing a 'flac -t' on 400MB of files compresses at level 5. the runtime dropped from from 180 sec to 105 sec! once I get the latest autotools on my ibook I'll try and get asm compilation to work that way. Josh --- Josh Coalson <xflac@yahoo.com> wrote: > OK, checked it all in (only minor

Yes, this is such a case. However, implementing this in a future encoder/decoder would break compatibility with most (likely all) existing decoders, and only in some very, very rare cases where the material is such that the encoder chooses to use negative shifts, which makes it even harder to troubleshoot. Furthermore, as this can only be used in very rare cases, there is no benefit from allowing

Josh Coalson wrote: > --- Luca Barbato <lu_zero@gentoo.org> wrote: > >>Josh Coalson wrote: >> >>>since I don't know how to resolve this, in current CVS I have >>>checked in a system where there are src/libFLAC/ppc/as and >>>src/libFLAC/ppc/gas selected by configure. I have also checked >>>in as many patches as I could make sense of

Thanks. I was worried about the assembler invocation but it looks like you solved that problem. Smooth build on my pbook (G4, 10.2.8, gcc-3.3, ac-2.59, am-1.6.3). Only problem was lack of check for docbook-to-man; my patch is attachments 1-2. Not so smooth on my imac (G3, 10.2.8, gcc-3.3, ac-2.52, am-1.6.1; that's what came with the last 10.2-compatible dev tools). First problem: typo in

Hello, I just tried to compile libFLAC (using Borland C++ Builder 6 on Windows). The compilers yells at me on line 233 of libFLAC/lpc.c *(residual++) = *(data++) - (sum >> lp_quantization); --> data is const and cannot be modified Funny thing is, if data is declared: const FLAC__int32 *data instead of const FLAC__int32 data[] everything is ok. Is this a bug in my compiler, or