similar to: nasm?

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/

Hi all I have built a preliminary debian package for dev86, required to build xen with vmx support. you can get my packages here: http://debian.nsp.co.nz/dev86. I have also trivially patched the rules for xen 3 to build the vmxloader and include it in the resulting packages, my builds/sources for these packages are here: http://debian.nsp.co.nz/xen3/. I''m working with debian-mentors

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

>> 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 '%'

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.

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

Please, I would like to know how to generate a truncated multivariate normal distribution k - dimensional, X ~ NT(mu, Sigma), where the elements of X to be non-negative (except the first), and the first dimension is strictly larger than zero. Example: X ~ NT_2(mu, Sigma), where mu=c(0.5, 0.5) and Sigma=c([120, 191], [191,154]), with X_1>0 and X_2>=0 Could anybody help

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

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

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

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

There was a commit "Fall back to intrinsics if NASM is not available" ( http://git.xiph.org/?p=flac.git;a=commit;h=d163ef456797ef4807138b0ecb5da9ff05e147e2 ) But CPU detection code for IA-32 uses ASM code, and cpuinfo.use_asm == false when NASM isn't available. The attached patch fixes it. Now CPU features are also detected when only FLAC__HAS_X86INTRIN is defined. --------------

Some wheird problem, Target/X86 builds okay now. But there seems to be another problem with the Cygwin build :- make[4]: Entering directory `/usr/build/llvm/lib/Target/SparcV9/ModuloScheduling' llvm[4]: Compiling ModuloSchedulingSuperBlock.cpp for Debug build /usr/src/llvm/lib/Target/SparcV9/ModuloScheduling/ModuloSchedulingSuperBlock.cpp : In member function `virtual bool

On Sat, 2 Jul 2005, Aaron Gray wrote: >>> The only thing I did not like was a clsh between the enum X86 and the new >>> namespace X86, which I had to rename as x86 :( >>> >>> Anyway, I suppose the lower case 'x' in 'x86' fits in with the lowercase >>> 'llvm' namespace. >> >> I'm not sure I follow. X86 is a

I have "refactored" the X86AsmPrinter into a number of files ready for the MASM and NASM backends to be added. There is a new namespace llvm::X86 to replace the anomonous namespace as this does not work accross mutiple .h and .cpp files. Other than that everything is pritty straight forward, t may possibly need tweeking though. It has been built under MS VS2003, but I am not sure how