Displaying 20 results from an estimated 439 matches for "disambiguation".
2013 Jul 11
1
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote:
> http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/
> asm/bitops.h#L68
>
> Here is one example that I found. Are the inline assembly arguments
> ambiguous in size?
It would help us for sure to build the kernel and others.
--
JS
2013 Jul 10
3
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386. GNU as supports them fine. Unfortunately, LLVM does not
> support them, and barfs with:
>
> error: ambiguous instructions require an explicit suffix
>
> Fix this problem by disambiguating it
2009 Feb 18
4
Disambiguate List Item Followed by Code Block
Howdy,
Quick question: Since list items with multiple paragraphs need to be
indented four spaces, and code blocks are also indented four spaces,
is there any way to disambiguate a list followed by a code block?
Example:
* This is a list
item.
* And so is this.
Is this a second paragraph in the second list item,
or a code block?
It looks like Markdown.pl and discount
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Also, please elaborate on why this is a good change. Because gas accepts it isn’t sufficient reason in and of itself.
-Jim
On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra
> <artagnon at gmail.com> wrote:
>> The instructions btr and bts are perfectly valid, and have existed since
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote:
> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants.
>
> The best reference I know of for the AT&T syntax is: http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf
I'm not sure
2020 Jul 07
3
BUILD_VECTOR disambiguation
...-----
> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Cameron
> > McInally via llvm-dev
> > Sent: Tuesday, July 7, 2020 9:53 AM
> > To: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> > Subject: [EXT] [llvm-dev] BUILD_VECTOR disambiguation
> >
> > Hey devs,
> >
> > From ISDOpcodes.h...
> >
> > /// BUILD_VECTOR(ELT0, ELT1, ELT2, ELT3,...) - Return a fixed-width vector
> > /// with the specified, possibly variable, elements. The number of elements
> > /// is required to be a power of two....
2020 Jul 07
2
BUILD_VECTOR disambiguation
...--Original Message-----
> > From: Cameron McInally <cameron.mcinally at nyu.edu>
> > Sent: Tuesday, July 7, 2020 10:10 AM
> > To: Krzysztof Parzyszek <kparzysz at quicinc.com>
> > Cc: llvm-dev at lists.llvm.org
> > Subject: [EXT] Re: [llvm-dev] BUILD_VECTOR disambiguation
> >
> > Thanks for the clarification. The `except` seemed dangling to me, but
> it's
> > early here.
> >
> > Just curious... how do we end up with a mixed type BUILD_VECTOR?
> > That's counterintuitive.
> >
> > On Tue, Jul 7, 2020 at 10:58...
2007 Mar 21
0
[909] branches/wxruby2/wxwidgets_282/doc/textile/combobox.txtl: Correct disambiguated method names in methods listing
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><style type="text/css"><!--
#msg dl { border: 1px #006 solid; background: #369; padding:
2020 Jul 07
3
BUILD_VECTOR disambiguation
Hey devs,
>From ISDOpcodes.h...
/// BUILD_VECTOR(ELT0, ELT1, ELT2, ELT3,...) - Return a fixed-width vector
/// with the specified, possibly variable, elements. The number of elements
/// is required to be a power of two. The types of the operands must all be
/// the same and must match the vector element type, except that integer types
/// are allowed to be larger than the element type, in
2013 Jul 11
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote:
> On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote:
>> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants.
>>
>> The best reference I know of for the
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wed, Jul 10, 2013 at 7:15 PM, Jim Grosbach <grosbach at apple.com> wrote:
>
> On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote:
>
> On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote:
>
> The length specifier is, as I understand it, required when the instruction
> references memory but is optional (and inferred from
2005 Oct 06
8
accessing extra request parameters
hi all,
how are other people passing and accessing ''get'' parameters from their apps?
what is the best way to do it?
ie:
www.example.com/controller/action/id/extra/extra2/ ??
or
www.example.com/controller/action/id/~extra/extra2/
or what ever....
are there built in methods for passing and accessing extra parameters?
thanks for your suggestions
-felix
2013 Oct 11
0
[LLVMdev] Request for comments: TBAA on call
...9;s again, entirely possible for a load to conflict with
> both a tbaa type, and a partitioned heap. In Filip's scheme, there is no
> way to represent this.
>
>
> I'm not sure what you mean.
>
I mean it's not possible, in this scheme, to specify both to be used for
disambiguation.
Right now, you get *one* tbaa tag on the load.
So you have to choose which tree you use if you want if you choose option
#2 above.
You always have to choose one or the other, or else the lose the
disambiguation.
> The compiler will handle this conservatively.
>
Only if you drop the t...
2013 Jul 10
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> Also, please elaborate on why this is a good change. Because gas accepts it
> isn’t sufficient reason in and of itself.
That they're valid instructions isn't sufficient reason? Should I
additionally say that linux.git uses them?
I wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386.
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> Jim Grosbach wrote:
>> Also, please elaborate on why this is a good change. Because gas accepts it
>> isn’t sufficient reason in and of itself.
>
> That they're valid instructions isn't sufficient reason? Should I
> additionally say that linux.git uses them?
>
Is the
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> That does raise a clarifying question here. Is the code you’re interested in
> using Intel or AT&T syntax?
>
> Also note that the question isn’t whether we should support the btr/bts
> instructions. We absolutely must (and do). The question is whether we are
> properly handling the un-suffixed mnemonic form of the assembly syntax.
>
> Perhaps you
2013 Jul 17
0
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> Jim Grosbach wrote:
> > No. The above rule is absolutely the wrong thing to do, as has been
> > previously noted.
>
> I don't give a shit about whether you think it is "absolutely wrong"
> or not; I did what hpa and the Intel manual outlined. If you have
> some _reason_ not to do
2013 Jul 17
1
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Jul 17, 2013 7:41 AM, "Joerg Sonnenberger" <joerg at britannica.bec.de>
wrote:
>
> On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> > Jim Grosbach wrote:
> > > No. The above rule is absolutely the wrong thing to do, as has been
> > > previously noted.
> >
> > I don't give a shit about whether you think it is
2004 Apr 05
2
Disambiguating incoming IAXTel calls
I have two 1-700 numbers from IAXTel. Both get registered from the same
Asterisk server. I can make and receive calls on each without any
difficulty. What I can't figure out how to do is route the incoming calls
differently based on which 1-700 number is dialed. I must be missing
something obvious.
Thanks
-brian
-------------- next part --------------
An HTML attachment was scrubbed...
2014 May 13
2
[LLVMdev] Instructions with overlapping encodings that are disambiguated by field comparisons
Hi,
I'm not sure how to handle some of the trickier instruction encodings in MIPS64r6. My problem is that some instructions determine the operation based on the relationship between two fields. For example, 'beqc $rs, $rt, offset' (branch if equal, no delay slot) and bovc (branch if addition would overflow, no delay slot) share the same major opcode and field layout. When the register