search for: assebmly

Dear folks, If I want to setup a mapping between an LLVM instruction and the x86 assembly instructions it generates, is this possible? Or, an equavalent question is, when LLVM is emitting assebmly instructions, will it transform a set of LLVM instructions to a set of assembly instructions, or transform each LLVM instruction to assembly instructions independently? -- Regards, Heming Cui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...

George Bratis wrote: >Speex now runs on a fixed point DSP with relative little MIPS. >The main problem is that you must rewrite the hole code in assembly. > >George > > Why must you write it in assembly? What is wrong with running the C code on a DSP? Sure you can improve the efficiency if you use assembly, but why do you say it is *necessary*? Regards, Steve --- >8

Le mer 31/03/2004 à 02:51, George Bratis a écrit : > I think that if you want to use a low cost dsp you must rewrite ti in > assebmly. > In our tests you will need 4-5 times more MIPS just compiling C code. You may need to rewrite 3-4 compute-intensive, but definitely not the whole thing. Jean-Marc -- Jean-Marc Valin http://www.xiph.org/~jm/ LABORIUS Université de Sherbrooke, Québec, Canada -------------- next p...

On Mon, Oct 25, 2010 at 12:39 PM, Heming Cui <hc2428 at columbia.edu> wrote: > Dear folks, >     If I want to setup a mapping between an LLVM instruction and the x86 > assembly instructions it generates, is this possible? >     Or, an equavalent question is, when LLVM is emitting assebmly > instructions, will it transform a set of LLVM instructions to a set of > assembly instructions, or transform each LLVM instruction to assembly > instructions independently? Essentially, it's from a set to a set; if you're compiling without optimizations, the correlation will lik...

On Wed, Mar 31, 2004 at 10:51:20AM +0300, George Bratis wrote: > I think that if you want to use a low cost dsp you must rewrite ti in > assebmly. > In our tests you will need 4-5 times more MIPS just compiling C code. This was also our experience porting the Tremor vorbis decoder to a TI dsp. The vendor toolchain is useless; someone really needs to pay cygnus to port gcc. -r --- >8 ---- List archives: http://www.xiph.org/archive...

...launch.com> To: <speex-dev@xiph.org> Sent: Thursday, April 01, 2004 7:40 AM Subject: Re: [speex-dev] speex on a DSP chip? <p>> > Le mer 31/03/2004 à 02:51, George Bratis a écrit : > >> I think that if you want to use a low cost dsp you must rewrite ti in > >> assebmly. > >> In our tests you will need 4-5 times more MIPS just compiling C code. > > > > You may need to rewrite 3-4 compute-intensive, but definitely not the > > whole thing. > > > > Jean-Marc > > > What's your guess on the total MIPS the optimized an...

Hi, Anton, For a simple example, I took the machine assembly code generated by llc and with a little manual change on the assebmly code (the way how llc generates .text segment is not accepted by MASM), it is able to be assembled and linked by MASM. And it runs. Haven't tried it on NASM yet. I am sure that you've run into many problems when efforts were carried out to implement the Intel ASM printer between version 1...

Hello > Does anybody have an idea of roughly how much effort is required to make > intel asm printer to be usable? If it is within weeks, probably I can give > it a try. 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". -- With best

Thanks for Anton's reply. Does anybody have an idea of roughly how much effort is required to make intel asm printer to be usable? If it is within weeks, probably I can give it a try. Thanks, Bengu On Thu, Jan 28, 2010 at 12:18 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > Hello > > > system native assemlber and linker to generate executables. And it >

...a64-optimized-domu-binary-patch For the status of this patch series http://wiki.xensource.com/xenwiki/XenIA64/UpstreamMerge thanks, changes from take 1: - no essential change from the last one - rebased to 2.6.28-rc8 - don't use cmp_inst_t. define and use ia64_inst_t, instead. - improve some assebmly code. Diffstat: arch/ia64/include/asm/intrinsics.h | 6 +- arch/ia64/include/asm/module.h | 6 + arch/ia64/include/asm/paravirt.h | 8 + arch/ia64/include/asm/paravirt_patch.h | 143 +++++++ arch/ia64/include/asm/paravirt_privop.h | 347 ++++++++++++++++- arch/ia6...

...a64-optimized-domu-binary-patch For the status of this patch series http://wiki.xensource.com/xenwiki/XenIA64/UpstreamMerge thanks, changes from take 1: - no essential change from the last one - rebased to 2.6.28-rc8 - don't use cmp_inst_t. define and use ia64_inst_t, instead. - improve some assebmly code. Diffstat: arch/ia64/include/asm/intrinsics.h | 6 +- arch/ia64/include/asm/module.h | 6 + arch/ia64/include/asm/paravirt.h | 8 + arch/ia64/include/asm/paravirt_patch.h | 143 +++++++ arch/ia64/include/asm/paravirt_privop.h | 347 ++++++++++++++++- arch/ia6...

...i.xensource.com/xenwiki/XenIA64/UpstreamMerge thanks, changes from take 2: - removed trivial compilation error depending on .config changes from take 1: - no essential change from the last one - rebased to 2.6.28-rc8 - don't use cmp_inst_t. define and use ia64_inst_t, instead. - improve some assebmly code. Diffstat: arch/ia64/include/asm/intrinsics.h | 6 +- arch/ia64/include/asm/module.h | 6 + arch/ia64/include/asm/paravirt.h | 8 + arch/ia64/include/asm/paravirt_patch.h | 143 +++++++ arch/ia64/include/asm/paravirt_privop.h | 347 ++++++++++++++++- arch/ia6...

...i.xensource.com/xenwiki/XenIA64/UpstreamMerge thanks, changes from take 2: - removed trivial compilation error depending on .config changes from take 1: - no essential change from the last one - rebased to 2.6.28-rc8 - don't use cmp_inst_t. define and use ia64_inst_t, instead. - improve some assebmly code. Diffstat: arch/ia64/include/asm/intrinsics.h | 6 +- arch/ia64/include/asm/module.h | 6 + arch/ia64/include/asm/paravirt.h | 8 + arch/ia64/include/asm/paravirt_patch.h | 143 +++++++ arch/ia64/include/asm/paravirt_privop.h | 347 ++++++++++++++++- arch/ia6...

...UpstreamMerge thanks, changes from take 3: - rebased changes from take 2: - removed trivial compilation error depending on .config changes from take 1: - no essential change from the last one - rebased to 2.6.28-rc8 - don't use cmp_inst_t. define and use ia64_inst_t, instead. - improve some assebmly code. Diffstat: arch/ia64/include/asm/intrinsics.h | 6 +- arch/ia64/include/asm/module.h | 6 + arch/ia64/include/asm/paravirt.h | 8 + arch/ia64/include/asm/paravirt_patch.h | 143 +++++++ arch/ia64/include/asm/paravirt_privop.h | 347 ++++++++++++++++- arch/ia6...

...UpstreamMerge thanks, changes from take 3: - rebased changes from take 2: - removed trivial compilation error depending on .config changes from take 1: - no essential change from the last one - rebased to 2.6.28-rc8 - don't use cmp_inst_t. define and use ia64_inst_t, instead. - improve some assebmly code. Diffstat: arch/ia64/include/asm/intrinsics.h | 6 +- arch/ia64/include/asm/module.h | 6 + arch/ia64/include/asm/paravirt.h | 8 + arch/ia64/include/asm/paravirt_patch.h | 143 +++++++ arch/ia64/include/asm/paravirt_privop.h | 347 ++++++++++++++++- arch/ia6...