search for: detangle

Displaying 13 results from an estimated 13 matches for "detangle".

Did you mean: demangle
2009 May 05
0
OT: Polycom handset cord detangler
Hello list, I wondered if those of you using Polycom phones could recommend a decent cord detangler. I've had quite a few handsets get the tabs broken off in the jack from cord detanglers due to the recessed nature of the jack. This seems like it would work but I wanted some opinions before I go buy some: http://www.voiplink.com/Extended_Handset_Cord_Detangler_p/detangler-e.htm I person...
2008 Aug 29
0
Detangling the ppbus/ppc interrupt stuff..
So I have a patch to try and straighten out the ppbus/ppc interrupt stuff a bit. Rather than passing IRQ numbers around as ivars, etc., ppc is smart enough to let child devices ask for SYS_RES_IRQ rid 0 and let them use its assigned IRQ resource. It then uses an interrupt event to mange the list of child interrupt handlers which it invokes from its own interrupt handler. I don't
2010 Dec 13
0
[LLVMdev] tblgen internals
...nt to Record's constructor, and a > corresponding factory method to RecordKeeper. This looks like great progress to me, applied in r121659. That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? Another random question: why is createRecord better than using "new Record"? If createRecord is better, it would be good to make the Record ctor private so the code doesn't evolve into sometimes using one and sometimes using the other. Som...
2010 Dec 12
2
[LLVMdev] tblgen internals
Hey Chris, The following patch removes all global references to a RecordKeeper instance for the tblgen utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files were touched, the main change was to Record.h. The patch takes the simple approach of adding a RecordKeeper reference to TGParser, and any needed emitter helper classes. In addition, since some of
2010 Dec 13
4
[LLVMdev] tblgen internals
...ferences to a RecordKeeper instance for the tblgen >> utility. > > This looks like great progress to me, applied in r121659. > > That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? I'll see if I can come up with another approach. This internal reference was motivated by the Record::setName(...) and UnOpInit::Fold(...) implementations accessing the previous global RecordKeeper instance. We could add a RecordKeeper& argument...
2015 Apr 06
0
[ANNOUNCE] xf86-input-keyboard 1.8.1
...s considered very much a legacy use case. Use evdev or the new libinput driver instead. Egbert's fix untangles overlaps between multimedia keys and the jp Henkan/Muhenkan keys. Alan Coopersmith (1): Mark xf86OSKbdPreInit as _X_EXPORT in header to match definitions Egbert Eich (1): Detangle inet keys and jp Henkan/ Muhenkan keys Peter Hutterer (3): Init LEDs to zero before querying the value linux: bring our process group to the foreground (#89653) keyboard 1.8.1 git tag: xf86-input-keyboard-1.8.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-ke...
2009 Nov 13
6
[LLVMdev] Proposal: intp type
...ions that should work with iptr: > Basic math: add, subtract, multiply, divide, mod. > Bitwise binary operators: shl, ashr, lshr, and, or, xor, etc. > Comparison operations. > alloca - currently doesn't work with i64, should it? Yes, alloca should work with i64. Recently malloc was detangled from alloca, but alloca should definitely support an arbitrary integer size. I don't know anyone planning to do this. In any case, for the first implementation stage of intptr, just converting to an i32 to do the alloca should be fine (no worse than what we have today). When alloc...
2010 Dec 13
0
[LLVMdev] tblgen internals
...Keeper instance for the tblgen >>> utility. >> >> This looks like great progress to me, applied in r121659. >> >> That said, it is suboptimal for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it? > > I'll see if I can come up with another approach. This internal reference was motivated by the > Record::setName(...) and UnOpInit::Fold(...) implementations accessing the previous > global RecordKeeper instance. We could add a RecordK...
2009 Nov 13
0
[LLVMdev] Proposal: intp type
...- Basic math: add, subtract, multiply, divide, mod. > - Bitwise binary operators: shl, ashr, lshr, and, or, xor, etc. > - Comparison operations. > - alloca - currently doesn't work with i64, should it? > > Yes, alloca should work with i64. Recently malloc was detangled from > alloca, but alloca should definitely support an arbitrary integer size. I > don't know anyone planning to do this. In any case, for the first > implementation stage of intptr, just converting to an i32 to do the alloca > should be fine (no worse than what we have today)....
2009 Nov 12
0
[LLVMdev] Proposal: intp type
On Wed, Nov 11, 2009 at 11:11 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 10, 2009, at 4:10 PM, Talin wrote: > > I realize that most users of LLVM aren't affected by this, because most > frontends aren't target-neutral, and thus know in advance how big a pointer > is. At least, that's my impression. > > I believe that. > > >
2009 Nov 11
4
[LLVMdev] Proposal: intp type
On Nov 10, 2009, at 4:10 PM, Talin wrote: > I realize that most users of LLVM aren't affected by this, because most frontends aren't target-neutral, and thus know in advance how big a pointer is. At least, that's my impression. I believe that. > There's only a tiny handful of fairly esoteric cases which require selecting a target before you generate IR. Unfortunately, the
2016 Jun 24
7
Representing MIPS ABI information in the triple as ARM/X86 do for EABI/EABIHF/X32
Hi, Having recently enabled IAS by default for the MIPS O32 ABI, I'm now trying to do the same thing for the MIPS N64 ABI. Unfortunately, it is not currently possible to enable IAS by default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. This would be fine if it N32 was
2016 Jul 05
2
Representing MIPS ABI information in the triple as ARM/X86 do for EABI/EABIHF/X32
...s then it shouldn't be too bad to do so. Even if it weren't an API problem I'm not sure it'd be a good idea. I think we could add a with-abi configuration option to match the current gcc one rather than tacking it onto triple parsing. That said, I'm more than happy to help you detangle the existing API and come up with a good strategy for the MC level API. Thanks! -eric ps. It also doesn't appear that Matthew (who took over my gcc responsibilities, thanks!) has added support for this in gcc yet either. echristo at dzur ~/b/build-gcc-mips64abin64> .../configure --target...