search for: as200

Does anyone have any instructions on how to connect a Quintum AS200 to Asterisk as a SIP phone? I currently have the AS200 sitting in a remote office and would like to use it as a SIP phone. It would register with Asterisk. Overall, I've had problems getting this work but I'm hoping that someone on this list might have some experience with this!

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

...is that dereferencing char* becomes relatively expensive, though for the sort of code being predominantly run on a DSP that might be acceptable. We're using multiple address spaces to describe two pointer representations for CHERI: AS0 is a 64-bit pointer that's represented as an integer, AS200 is a capability (256-bit fat pointer with base, length, permissions, enforced in hardware). We had to fix a few things where LLVM assumes that pointers are integers, but the different size pointers in different address spaces part works very well. The biggest weakness is in TableGen / SelectionDA...

> On Apr 30, 2018, at 15:05, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >>> The LLVM address space design has pushed well beyond the sensible boundaries >>> of

> On Apr 30, 2018, at 2:58 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > On Mon, Apr 30, 2018 at 11:14 AM, John McCall <rjmccall at apple.com> wrote: >> The LLVM address space design has pushed well beyond the sensible boundaries >> of less-is-more and really needs some concerted effort to actually define the expected >> properties of different

...2* %1 = addrspacecast i32* %0 to i32 addrspace(200)* call void @set(i32 addrspace(200)* %1) %add.ptr = getelementptr inbounds i32 addrspace(200)* %1, i64 41 call void @test(i32 addrspace(200)* %add.ptr) ret i32 0 } This is correct and semantically valid for our architecture. The cast to AS200 is creating a fat pointer with base and bounds information, the GEP is constructing a new fat pointer with the same base and bounds but a different offset within the object. This survives for a bit, but then: *** IR Dump After Combine redundant instructions *** ; Function Attrs: nounwind define i...

On 16 Mar 2015, at 08:25, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > The LangRef says this about addrspacecast: "Note that if the address > space conversion is legal then both result and operand refer to the > same memory location.". This brings forth two related questions: > > 1. what happens if you execute an "invalid" addrspacecast?

> It's definitely doable, but I'd be worried about the maintenance burden. Yes, that is a problem. We are currently not allowed to reveal our target (which has 16-bit bytes, and registers with non-power-of-two bit widths) fully, and therefore not able to submit it upstream. One idea we have toyed with is to create a simple "dummy" version of our target, just to be able