similar to: [LLVMdev] Saving/restoring executable code from the the JIT?

On 30 April 2010 11:43, Sherief N. Farouk <sherief at mganin.com> wrote: >>> I'm a software engineer. I'm terribly uncomfortable with C. > > Aaaaahahahahahahahaha Please be civil, guys. Different engineers have different skill levels, so what. If someone asks for some help with the reference implementation the least we can do is point them in a useful direction. If

I'm trying to build the sources from the svn trunk using VC2008, and I'm running into some problems. First, I have no idea what the configure project is for, and it fails with a manifest related error (the project lacks any .c* files anyway). This causes an avalanche of problems, initiated by TableGen not being able to build. Has anyone been successful in getting the LLVM libs to build

From: Sherief Farouk [mailto:sherief.farouk at twisted-works.com] Sent: Tuesday, November 03, 2009 5:34 PM To: 'speex-dev at xiph.org' Subject: Handling allocation failure in resampler init - patch Hi, Here's a patch that stops allocation failures during resampler init from segfaulting, now they fail gracefully and report the error through the error code parameter

How much latency are we talking about? It seems that this issue cannot be easily pinpointed, but if it turns out to be related to the Speex Resampler let me know and I will put it on my task list. - Sherief -----Original Message----- From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at xiph.org] On Behalf Of Colin Guthrie Sent: Monday, December 06, 2010 9:47 AM To: speex-dev at

> hton and ntoh intrinsics. These are needed to allow target code to > deal with endianness in a target independent way. (Ok, you could > potentially write code that detected endiannes at runtime and chose > multiversioned code based on that, but that is ugly and optimization > prohibiting). > Why not add types with explicit endianess? A trick I use for reading binary files

Hi, I've noticed that the opus-tools is using a really old version of Speex's resampler code - a version that I've seen fail in the wild first-hand under low resource circumstances. I've actually submitted patches for some issues in the Speex resampler a while ago (and IIRC they were accepted): http://lists.xiph.org/pipermail/speex-dev/2009-November/007541.html ,

On Mon, 2008-09-29 at 15:03 -0400, Sherief N. Farouk wrote: > Why not add types with explicit endianess?... The issues with architecture dependency are far broader than byte order. LLVM in its current form is simply not intended to be machine neutral. Quite the contrary: it is heavily machine dependent!

This is certainly an option... but keeping up an LLVM backend for the 360 seems like a bit much work. Using Clang's rewriter requires no real low-level maintenance, just creating and maintaining a C library for support functions emitted by the compiler (e.g. objc_msgSend). It seems to create a backend for LLVM targeting the 360 I wouldn't need to create something that outputs XEX's

If you can produce a simple minimal repro that exhibits this issue on some procedural signal (sine wave, etc) I'd love to look into it some more - I'm maintaining a hardened version of the Speex Resampler and would be very concerned if this bug made it into production. - Sherief -----Original Message----- From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at xiph.org] On

Le 27 mai 2010 à 08:48, Kevin Wooten a écrit : > This is certainly an option... but keeping up an LLVM backend for the 360 seems like a bit much work. Using Clang's rewriter requires no real low-level maintenance, just creating and maintaining a C library for support functions emitted by the compiler (e.g. objc_msgSend). > The clang rewriter is not the same than LLVM C backend.

Renato Golin <rengolin at systemcall.org> writes: > or what about register variables, or objects half as registers half in > memory, or optimizations that exists on one machine (presence of FPU, > MMU, etc) and not on others, byte sex, word size and many other > problems... All of this is the job of serialization engine. [snip] My goal is to avoid waiting several minutes on

I'm a software engineer. I'm terribly uncomfortable with C. I want someone to show me a simplified use of Speex decoding. FWIW I'm finally getting my head around the API but the example had me a little lost with its cryptic variable names and monolithic nature. The example I'm asking for is way simpler than the final code I will ship to production so in essence, I'm looking for

Just to be clear, nothing in the MS TCRs require that you use a certain compiler - it does, however, require that you link with the 360-specific C runtime libraries. That being said, I still believe that direct binary generation is not a feasible option, and the ObjC => C route is preferred. Kevin, hate to be asking this but do you have access to the XDK or are you just "aiming" for

> I could add that to my CMake build system TODO, but so far I'm a bit > skeptic about LLVM relevance on the non-Unix world. The Windows build > can be broken for a long period before anyone notices. The VS2003 > support is broken since a long time ago and, apart from myself, no > other > user cares. Seems that LLVM penetration on Windows, for instance, is > almost nil. Is

Yep... I have been a 360 developer since the days when it was a actual Macintosh G5. I went to all the early tech. seminars and learned way more about that wacky processor and MS's seemingly crazy ABI choices than I care to (I know, I know, they had their reasons for them). Knowing this is why I quickly turned toward rewriting objc instead of attempting to implement a backend. I have also

'Twas brillig, and Sherief N. Farouk at 06/12/10 14:29 did gyre and gimble: > If you can produce a simple minimal repro that exhibits this issue on some > procedural signal (sine wave, etc) I'd love to look into it some more - I'm > maintaining a hardened version of the Speex Resampler and would be very > concerned if this bug made it into production. Well at present,

'Twas brillig, and Colin Guthrie at 06/12/10 15:10 did gyre and gimble: > 'Twas brillig, and Sherief N. Farouk at 06/12/10 14:52 did gyre and gimble: >> How much latency are we talking about? It seems that this issue cannot be >> easily pinpointed, but if it turns out to be related to the Speex Resampler >> let me know and I will put it on my task list. > > Will

I'm slightly confused here, just to be clear: you're planning to go ObjC -> LLVM (via Clang or whatever) -> C, then use the 360 SDK compiler to build that, right? If that's the case, I think it'd be a better option than to use LLVM to directly generate XEXs, and you won't give the TCR guys fits (I checked the BAS TCRs, none of them say you can't do that, but the

Kevin, there're some unwritten rules on the 360 that seem to interfere with code generation - pointer load-stores seem to require zeroing the most significant 32 bits, for example - that was one issue that I ran into a while ago while fooling around with code generation on the 360 (and don't blame me if I'm slightly off the mark, it was quite a while ago). I didn't seem to find it

Hi Sherief, First thing is your data set did not make it If it is not too large, perhaps you could send the output of "dput" in the body of the message or send a CSV file with the extension changed to ".txt". If the data set is very large, perhaps you could send a subset as described above. Jim On Wed, Sep 20, 2017 at 11:18 AM, Sherief Ghozy via R-help <r-help at