similar to: Assembly on Mac OS needs to be relocatable

I've been putting some work into building Libflac into a game engine I'm working on. I ran into a few small issues in the process, and was able to fix them, so I thought I'd post with my fixes. These aren't generally applicable - I'm taking a "shortest path to functionality" approach - but with a little work could probably be turned into general patches. First,

Hi, I have read in an earlier post here on this list, that with Mac OS X Leopard it is now easier to build FLAC from source with Xcode. Because I want to automatically build FLAC from source (i.e. via bash scripting) I am looking for a way to compile it "the unix way" (i.e. via configure, make, make install) without Xcode. So I downloaded the source (v1.2.1), read its accompanying

Hi, I have read in an earlier post here on this list, that with Mac OS X Leopard it is now easier to build FLAC from source with Xcode. Because I want to automatically build FLAC from source (i.e. via bash scripting) I am looking for a way to compile it "the unix way" (i.e. via configure, make, make install) without Xcode. So I downloaded the source (v1.2.1), read its accompanying

I don't have time to look through error codes, but I can tell you that I have always compiled FLAC the Unix way, via the command line. I have not tried under Leopard, because for maximum compatibility it's better to compile under Tiger. Either something is wrong with your particular setup, or perhaps Leopard has changed some things which has broken FLAC. If you have Tiger

Don't use the assembly function since it seems to be slower than the current version of FLAC__bitreader_read_rice_signed_block. --- src/libFLAC/stream_decoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index f987c27..37934de 100644 --- a/src/libFLAC/stream_decoder.c +++ b/src/libFLAC/stream_decoder.c @@

On Fri, May 2, 2008 at 1:22 PM, Marc de Kruijf <dekruijf at cs.wisc.edu> wrote: > The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing > that it abstracts implementation details, in particular pointer size, from > the compiler. While it does this fine for pointer addresses, it does not > manage it for address offsets. Consider the following code: > >

They are not needed since the section is defined in nasm.h. --- src/libFLAC/ia32/bitreader_asm.nasm | 4 ---- src/libFLAC/ia32/cpu_asm.nasm | 4 ---- src/libFLAC/ia32/fixed_asm.nasm | 4 ---- src/libFLAC/ia32/lpc_asm.nasm | 4 ---- src/libFLAC/ia32/stream_encoder_asm.nasm | 4 ---- 5 files changed, 20 deletions(-) diff --git

Hello: This is a simple, I hope, question about the first example in section 3.6.4 of the manual, "Writing R extensions." I'm using R 1.1.0, and below I list some easy code that I got from section 3.6.4. When I try to compile the file out.c under NT 4, using VC++ 6.0, I get the following error messages: Compiling... out.c Linking... out.obj : error LNK2001: unresolved external

On 31.5.2013 13:04, Miroslav Lichvar wrote: > On Wed, May 29, 2013 at 04:08:57PM +0200, Martijn van Beurden wrote: >> I was surprised to see that the Windows compile on wine actually >> outperformed the native Linux one. Probably GCC 4.6 optimized a little >> better or something very weird is going on in wine, I don't know. The >> assembly optimizations work very

On Wed, May 29, 2013 at 04:08:57PM +0200, Martijn van Beurden wrote: > I was surprised to see that the Windows compile on wine actually > outperformed the native Linux one. Probably GCC 4.6 optimized a little > better or something very weird is going on in wine, I don't know. The > assembly optimizations work very well on encoding, but actually slow > things down when

On 1.6.2013 14:24, Janne Hyv?rinen wrote: > On 31.5.2013 13:04, Miroslav Lichvar wrote: >> On Wed, May 29, 2013 at 04:08:57PM +0200, Martijn van Beurden wrote: >>> I was surprised to see that the Windows compile on wine actually >>> outperformed the native Linux one. Probably GCC 4.6 optimized a little >>> better or something very weird is going on in wine, I

On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote: > attached are patches that improve decoding speed a bit. The first > patch improves the bit scan macro used for decoding unary values, the > second one adds a GCC inline assembly for bswap and the third patch > replaces the read_rice_block function. The third patch has a bug causing reading past input buffer, attaching

Hello everyone. Due to problems with libsndfile's handling of FLAC files, Mixxx is going to use libFLAC directly in v1.9.0. I'm the Windows packager and am trying to build libFLAC on Windows x64 using MSVC 2008 and the following steps that I've put together: http://mixxx.org/wiki/doku.php/build_windows_dependencies#libflac The problems I have are the following: If I try to build the

On 28-05-13 20:09, Janne Hyv?rinen wrote: > On Windows the 32-bit NASM enabled compiles are always fastest. If you > can run 32-bit code on your Linux box you should compile with assembly > optimizations. That depends on the way you define speed. For decoding this doesn't seem to be true. I reran my tests, it took a little longer because I couldn't believe the results I got.

The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing that it abstracts implementation details, in particular pointer size, from the compiler. While it does this fine for pointer addresses, it does not manage it for address offsets. Consider the following code: $ cat test.c int main() { int *x[2]; int **y = &x[1]; return (y - x); } $ llvm-gcc -O3 -c test.c

http://bugzilla.mindrot.org/show_bug.cgi?id=611 Summary: Unnecessary authentication attempt in auth2-none.c creates delay Product: Portable OpenSSH Version: 3.6.1p2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-bugs

Flac uses assembly code to improve performance for ix86 processors. This works under Linux, BSD and Windows, but not Mac OS X, because there is no support for creating Mach-O format binaries (the native binary format for OS X systems). The attached patch provides the necessary support to create ASM-optimised Mach-O binaries. This wasn't created by me but was sent to the audacity-devel list (I

Hi Sean, You may find that the attached patch helps. Builds perfectly here using it. John On 17/11/2010 14:02, Sean Pappalardo wrote: > Hello everyone. > > Due to problems with libsndfile's handling of FLAC files, Mixxx is > going to use libFLAC directly in v1.9.0. I'm the Windows packager and > am trying to build libFLAC on Windows x64 using MSVC 2008 and the >

Hi, attached are patches that improve decoding speed a bit. The first patch improves the bit scan macro used for decoding unary values, the second one adds a GCC inline assembly for bswap and the third patch replaces the read_rice_block function. In my testing it turned out to be even faster than the _ia32_bswap function. If the code produced by MSVC is faster as well, I'd suggest to remove

Previously I wrote that precompute_partition_info_sums_32bit_asm_ia32_() only makes encoding slower. Now I managed to compile flac with GCC 4.8.1, with this function enabled and disabled. NASM was enabled, SSE intrinsics disabled. Then I added -msse option (so that all C code was compiled with -msse), then -msse2 and so on. Input file for test: 44.1kHz/16bit/stereo; best compression mode (flac