similar to: compiling theora-mmx on AMD64

Hi all, I've patched theora-mmx to build on x86_64. The patch against SVN is attached. Basically all I did was to copy lib/i386 to lib/x86_64 and tweak the assembler code a bit: * added to each file: typedef unsigned long int ogg_uint64_t * converted all asm inputs to 64-bit in: dsp_mmxext.c, fdct_mmx.c, recon_mmx.c * left all asm outputs at 32-bit * I didn't patch dsp_mmx.c, since all

Hi, I can not anymore compile this version of theora. I get the following: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../i nclude -I../lib -I../lib/dec -I../lib/enc -I/usr/local/include -Wall -Wno-p arentheses -O3 -fforce-addr -fomit-frame-pointer -finline-functions -funroll-loo ps -MT mode.lo -MD -MP -MF .deps/mode.Tpo -c -o mode.lo `test -f

Hi, I'm trying to build a universal binary from libtheora-1.1alpha1. My configure line is as follows: env CFLAGS="-g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc" ./configure --disable-dependency-tracking But when I make, I get: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include

Is there any stable version of spandsp that works on a 64 bit Linux on an AMD64 machine. When compiling version 0.0.1k I get the following error: gcc -DHAVE_CONFIG_H -I. -I. -I. -I -g -O2 -c testcpuid.c -MT testcpuid.lo -MD -MP -MF .deps/testcpuid.TPlo -fPIC -DPIC -o .libs/testcpuid.lo /tmp/ccXxGHg6.s: Assembler messages: /tmp/ccXxGHg6.s:8: Error: suffix or operands invalid for `pushf'

Pavel Machek wrote: > Hi! > > >> 6) Interrupts must always be enabled when running code in userspace. >> > > I'd say this breaks userspace. > I agree. My claim is that this is not an issue in a virtual machine. What possible reason can you have to disable interrupts in userspace? Well, several. For one, the X server wants to disable

Pavel Machek wrote: > Hi! > > >> 6) Interrupts must always be enabled when running code in userspace. >> > > I'd say this breaks userspace. > I agree. My claim is that this is not an issue in a virtual machine. What possible reason can you have to disable interrupts in userspace? Well, several. For one, the X server wants to disable

I don't know enough about LLVM CodeGen to answer your questions. I'm just curious. What is the intended level of support for these intrinsics? Are they for reading ALU flags like CF, OF, etc, or for seldom changed control flags like TF and AC? Even DF is typically scratch, and could be used for an -Oz memmove lowering for example. I don't think LLVM will ever really support

Hello all, I am trying to implement intrinsics __readeflags and __writeeflags reading and writing EFLAGS register on x86. These intrinsics expand to two instructions popf and push to register for __readeflags and pushf and pop to register for __writeeflags. These instructions are not connected explicitly so I can't use patterns in .td file to match intrinsics. I tried to implement custom

Agreed, never emit pushf/popf. Sorry I never committed the patch, the cmov issue got hairy and I never got to debugging it :-) I can get back to it if there's interest! On Wed, Jul 29, 2015 at 4:12 PM, Reid Kleckner <rnk at google.com> wrote: > I remember this bug. :) IMO, LLVM should never emit pushf / popf. I'm not > sure this patch to fix it ever got committed: >

This intrinsic seems very ill-defined, apparently it can be freely reordered and does _not_ act like a compiler barrier. [1] Other than source compatibility, why would one want this intrinsic? What semantics is it supposed to give? [1] < http://connect.microsoft.com/VisualStudio/feedback/details/691456/-readeflags-intrinsic-can-be-reordered-by-the-compiler > On Tue, Dec 17, 2013 at 11:00

On 04/10/17 17:58, Josh Poimboeuf wrote: > Convert the hard-coded native patch assembly code strings to macros to > facilitate sharing common code between 32-bit and 64-bit. > > These macros will also be used by a future patch which requires the GCC > extended asm syntax of two '%' characters instead of one when specifying > a register name. > > Signed-off-by:

Convert the hard-coded native patch assembly code strings to macros to facilitate sharing common code between 32-bit and 64-bit. These macros will also be used by a future patch which requires the GCC extended asm syntax of two '%' characters instead of one when specifying a register name. Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> ---

Hi together, I have compiled so far a lot libs and already some programs on my Solaris 5.7 box (old, I know). When I try to compile libtheora the examples are not compiling: make[2]: Entering directory `/export/home/quix0r/more/libtheora-1.0/examples' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/local/include -I/usr/local/include/libpng12 -Wall -Wno-parentheses -O3

Hi there. I try to cross-compile the theora libraries to test my ARMv6 optimizations (almost done, time to do some benchmarking and testing). While doing so I found out that --with-ogg seems to do nothing. If I simply run: .configure --with-ogg=$HOME The build succeeds also it shouldn't (I don't have ogg installed at $HOME). As an example here is the last line that make executes.

On 7/29/15 18:35, JF Bastien wrote: > Agreed, never emit pushf/popf. Sorry I never committed the patch, the > cmov issue got hairy and I never got to debugging it :-) > I can get back to it if there's interest! You've definitely got some interest here. I've been looking at your patch on http://reviews.llvm.org/D6629 and I think I'm up to speed on where it's stuck.

Steven Hi, I'm unable to compile testcpuid.c with the __x86_64__ architecture (Athlon 64 processor). The messages are: /tmp/ccONleRV.s: Assembly messages: /tmp/ccONleRV.s: Error: suffix or operands invalid for 'pushf' " 'pop' " 'push' " 'popf' Is it safe to ignore this module? When I attempt to start asterisk, libspandsp.so.0 fails to load

On Thu, 21 Jul 2005, Long Fei wrote: > Does anyone know the "standard" commandline to compile and run spec95 > benchmarks ? > > I found some scripts in llvm test suite (External/SPEC/CINT95), but I am not > sure if they are the *default ref* configurations. <Some of them seem to use > smaller problem sizes.> SPEC95 was retired many years ago, so few people

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

Hi, Attached is a patch against 1.0alpha7 to speed up Theora decoding. It is about 15~20% faster in my test. It consists of following things: * MMX loop filter based on Rudolf Marek's patch in http://lists.xiph.org/pipermail/theora-dev/2005-August/002838.html * MMX IDCT based on Rudolf Marek's patch in http://lists.xiph.org/pipermail/theora-dev/2005-July/002816.html and the code in