similar to: PATCH: CPU feature detection when NASM n/a

I found that FLAC__cpu_have_cpuid_x86() was removed in the commit <http://git.xiph.org/?p=flac.git;a=commitdiff;h=fa24613ad94ba8fb8e23bcb9ca80b4548bb617e6> with the message: "Remove `FLAC__cpu_have_cpuid_x86` altogether as it wasn't actually being used but that was difficult to tell because of all the #ifdef nonsense." But FLAC__cpu_have_cpuid_x86() actually WAS used

Is Nasm always available when the target architecture is IA-32? For example, FLAC has FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_NN() functions that require NASM presence, and FLAC__lpc_compute_autocorrelation_intrin_sse_lag_NN() functions that require x86 intrinsics support. FLAC makes use of the former (if NASM is available) but doesn't try to use the latter when NASM is not found.

It's not possible to use ia32/*.nasm code in 64-bit compiles. There's still no 64-bit asm code in FLAC. I'm not familiar with asm too, so I wrote SSE-accelerated code using intrinsics. This code uses two new preprocessor macros: FLAC__CPU_X86_64 (analogous to FLAC__CPU_IA32) and FLAC__HAS_X86INTRIN (analogous to FLAC__HAS_NASM) Patch for cpu.c/cpu.h adds CPU features (sse3, ssse3)

Hi Guys, The following code in CPU.c (line 155) won't link if you don't have NASM code built even if FLAC__HAS_X86INTRIN is true as FLAC__cpu_info_asm_ia32 don't exists and the else is compiled if there is no dead code stripping if (FLAC__HAS_X86INTRIN) { FLAC__cpu_info_x86(0, &flags_eax, &flags_ebx, &flags_ecx, &flags_edx); info->ia32.intel =

Erik de Castro Lopo wrote: > lvqcl.mail wrote: > >> Currently libFLAC doesn't check the existence of CPUID instruction if >> FLAC__HAS_X86INTRIN is set to 1. >> It's not a real problem because x86 CPUs without CPUID are probably >> extinct, but if libFLAC performs this check then it should do it >> in all cases (when NASM is available or intrinsics are

> > > Unfortunately, there is a bigger problem that affects both SDL > > > and FLAC, > > > which is that the assembly routines are not PIC. > > > > It's not? I think all the IA32 code only references data on the > > stack, and > > it doesn't call outside the library or export any functions outside > > the > > library. The

Hi, trying to build syslinux on Linux. Please help. bash-2.05b$ uname -a Linux bongo 2.4.32-ARXc3 COHERENT #4-ARX (Build 2660) Sun May 21 15:35:22 CEST 2006 i686 i686 i386 GNU/Linux bash-2.05b$ BUILD/syslinux-3.11/opt/nasm-0.98.38-2/bin/nasm -version NASM version 0.98.38 compiled on Jun 26 2006 But failed with: + make NASM=/home/axel/p/rpm/BUILD/syslinux-3.11/opt/nasm/bin /nasm

Hi folks, here's a patch which cleans up the nasm call from Makefiles. Abusing libtool and then having to drop in some additional wrapper script to rewrite the commandline again is rather stupid. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/

Despite being documented as the place for submitting bug reports and patches, it seems like the sf.net bug tracker isn't get much attention, so here it is: http://sourceforge.net/p/flac/bugs/400/ During x86-windows builds using mingw or mingw-w64, nasm complains: nasm.h:83: warning: COFF section names limited to 8 characters: truncating I think the section .note.GNU-stack stuff aren't

where can I get the lastest nasm to compile syslinux 1.75. http://www.cryogen.com/Nasm is not accessible and the latest on ftp://ftp.kernel.org/pub/software/devel/nasm/source/ is nasm-0.98.tar.bz2 Thanks, Jeff [ jchua at fedex.com ]

>> I am not really sure whether to do a X86NASMPrinter or whether to bypass >> that for now and work on an X86COFFWriter which would be more useful to >> me ? > > I wouldn't suggest writing an X86NASMPrinter: just change the current > Intel printer to do what you want. Noone is currently using the intel > printer, so you can do what you wish to it. Once I

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

> On Mon, 2005-07-11 at 19:24 +0100, Aaron Gray wrote: >> The NASM like the MASM does not have % symbols on the register names so >> will >> either inherit from the MASM printer or have its own TableGen class. > > Couldn't one conditionally output some macros for the assembler to > translate the reg names rather than having another .td file? or is '%'

Could generated assembly with option "-x86-asm-symtab=intel" be assembled by nasm directly? On Thu, Jun 21, 2012 at 2:30 PM, Sean Silva <silvas at purdue.edu> wrote: > If by "NASM format" you mean Intel syntax, then yes. In my experience most > LLVM tools refer to it with the option "-x86-asm-syntax=intel". For > example, tools/llvm-objdump has this

On Mon, 2005-07-11 at 19:24 +0100, Aaron Gray wrote: > The NASM like the MASM does not have % symbols on the register names so will > either inherit from the MASM printer or have its own TableGen class. Couldn't one conditionally output some macros for the assembler to translate the reg names rather than having another .td file? or is '%' not a valid part of a macro on NASM?

Builds fine on Linux, but there seems to be a problem building it on Cygwin, will look into this. Aaron ----- Original Message ----- From: Aaron Gray To: LLVM Developers Mailing List Sent: Thursday, June 30, 2005 7:12 PM Subject: [LLVMdev] X86AsmPrinter + MASM and NASM backends I have "refactored" the X86AsmPrinter into a number of files ready for the MASM and NASM

If by "NASM format" you mean Intel syntax, then yes. In my experience most LLVM tools refer to it with the option "-x86-asm-syntax=intel". For example, tools/llvm-objdump has this flag. --Sean Silva On Wed, Jun 20, 2012 at 10:12 PM, Thomson <lilotom at gmail.com> wrote: > I saw some LLVM generated assembly in NASM format, but did find this > support in the

On Jan 28, 2010, at 11:51 AM, Dustin Laurence wrote: > On 01/28/2010 11:41 AM, Anton Korobeynikov wrote: >> >> The required efforts equal to ones required to write new assembler. >> "Too weak to be usable" means "it's not possible to represent many >> important constructs with masm/nasm/fasm". > > Wow. It's perhaps too much of a

I saw some LLVM generated assembly in NASM format, but did find this support in the official release. Is this supported? -- Thanks Thomson Tan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/c571b488/attachment.html>

1) Two comments ";ASSERT(lp_quantization <= 31)" in the new functions ..._wide_asm_ia32() -- just to mention this constraint. (max. possible value of lp_quantization is 15, so it's not a problem) 2) "mov cl, ..." was replaced with "mov ecx, ..." (again Agner Fog, optimizing_assembly.pdf) summary: write to a partial register may result in false dependencies