similar to: Theora Hardware: Integration with LEON is completed!

Theora hardware with LEON3 is runinng!!! My video was too slow, then I discovered that the problem was on LINUX! I don't exactly, but I suppose that the time of LINUX Call systems (like fread()) is the problem. If I don't use the linux (like is done on NIOS), I can to decode much faster than the time of exibition! Now we have two points on software (the hardware is the same,

Hi, Now I am working on BCC Cross-compiler in order to get the binaries for LEON3 (Google SoC 2007). I changed these lines of Makefile ... CC = gcc CPP = gcc -E ... to these : CC = sparc-elf-gcc -mv8 -msoft-float CPP = sparc-elf-gcc -mv8 -msoft-float -E The options means: -mv8 : generate SPARC V8 instructions -msoft-float : emulate floating-point When I run "make", there is a

Hi, I applied for GSoC 2007 and I received just one comment that I can read, the others are occult for me. If it is possible, I would like to know If there is any thing that I should change or not, any comments. The Title of my apply is "Hardware implementation of Theora decoding" and I am "Andre Luiz Nazareth da Costa" Thanks, Andr? Costa -- Andr? Costa Gerente T?cnico

Hi, I am sending my application I submitted for the GSoC. There are still some hours left before the deadline, so if you have any remarks or a tip, I can still update it. thanks... i think there are some grammatical errors =(... == Name and Contact details == Andr? Luiz Nazareth da Costa Primary e-mail: andre.lnc@gmail.com Secondary e-mail: andre.lnc@lsc.ic.unicamp.br Gtalk:

Hi all, I'm trying to use libspeex 1.1.10 on an ARM926EJ-Sid(wb) rev 3 (v5l). I executed the speexenc and speexdec test files and they can encode and decode. But I'm getting 95% of cpu utilization on the codification and 44% on the decodification. I saw in the post: http://lists.xiph.org/pipermail/speex-dev/2005-June/003485.html that this version of speex works fine on ARM

Hello, First of all, I would like to say that my work that I wrote in the other email would be to do in hardware the functions: CopyRecon, LoopFilter and UpdateUMVBorder. These are modules that Leonardo had made, but it wasn't ok in FPGA. When I had a chat with Leonardo we were thinking in rewrite these module for to do this running in FPGA (to debug in a Hardware level is much more

Hi, I tried the same options suggested in your post and the problem continues. What do you suggest? 2005/9/15, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca>: > Hi Eduardo, > > All I can say is that the timings you have are a bit odd. What > optimizations options are you using (I suggest -O3)? Also, perhaps you > can try --enable-arm4-asm just in case. I've had the

Hi Eduardo, All I can say is that the timings you have are a bit odd. What optimizations options are you using (I suggest -O3)? Also, perhaps you can try --enable-arm4-asm just in case. I've had the encoder running in real-time on a chip that's at least twice slower than yours with the settings you're using. Jean-Marc Le jeudi 15 septembre 2005 ? 16:23 -0400, Eduardo Bezerra a

At the moment I am using LLVM to target our proprietary SHAVE processor, but the Movidius "Myriad" chip also utilises a Sparc Leon for executive functions. For this I use the GCC compiler. This all works fine, but I would like to consolidate code generation for both targets in the same LLVM derived compiler to simplify things and I have a couple of questions about the Sparc backend

This should help us to: - More easily add or remove machine initialization arguments without having to change every single machine init function; - More easily make mechanical changes involving the machine init functions in the future; - Let machine initialization forward the init arguments to other functions more easily. This change was half-mechanical process: first the struct was added

Hi, in section B.29. (Write State Register Instructions) of 'The SPARC Architecture Manual Version 8' it is said that the "The write state register instructions are delayed-write instructions." The Y-register is a state-register. Furthermore in the B.29-secion there is a programming note saying: MULScc, RDY, SDIV, SDIVcc, UDIV, and UDIVcc implicitly read the Y register.

I'm removing old targets that no longer appear actively maintained, to reduce the burden for target-independent codegen maintenance. Does anyone object to the removal of the Sparc backend? Dan