search for: btsl

1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) changed a bunch of btrl/btsl instructions to btr/bts, with the following justification: The inline assembly for the bit operations has been changed to remove explicit sizing hints on the instructions, so the assembler will pick the appropriate instruction forms depending on the architecture and the context. Unfortuna...

(resent without HTML) On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the assembler will pick > the appropriate instruction forms depending on the architecture and &...

Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. The Intel documentation implies that this is the case: > If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure 3-2). The offset...

...he memory reference versions which IIUC require a suffix. > > I want to make sure we do the right thing here and know why we’re doing it > rather than just adding some aliases because it matches gas’ behavior. The reason it's the right thing to do is that the mem/imm forms of btsw and btsl have exactly the same semantics. -Eli

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

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

On Sun, Jul 14, 2013 at 5:56 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the assembler will pick > the appropriate instruction forms depending on the architecture and &...

On 07/14/2013 12:23 PM, Jeremy Fitzhardinge wrote: > (resent without HTML) > > On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote: >> 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) >> changed a bunch of btrl/btsl instructions to btr/bts, with the following >> justification: >> >> The inline assembly for the bit operations has been changed to remove >> explicit sizing hints on the instructions, so the assembler will pick >> the appropriate instruction forms depending on th...

Linus Torvalds wrote: >> btrl $1, 0 >> btr $1, 0 >> btsl $1, 0 >> bts $1, 0 > > What the heck is that supposed to show? I was trying to show a reduced case where gas doesn't complain, but llvm-mc does. Try compiling this with llvm-mc, and you'll get: .text btrl $1, 0 in.s:2:1: error: ambiguous instructions r...

Stephen Checkoway wrote: > [...] Thanks for the absolutely splendid analysis! > For the memory, immediate form without the suffix, it seems like the options are > 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error; > 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed instructions are assumed to be long and alias bts to btsl and btr to btrl; or > 3. Always error even when there is no ambiguity...

Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.

...if it violates some transcendental (but unimplemented) authoritative standard [1]. If other mainstream assemblers handle btr/bts differently, I would see a cause for worry; otherwise, no. Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. Not sure I understand this. [1]: Especially considering that we can't seem to find one.

Hi guys, I am trying to compile some files using clang + llvm and I am encountering the following error during the linking step: <inline asm>:1:2: error: ambiguous instructions require an explicit suffix (could be 'btsw', 'btsl', or 'btsq') bts $14,(%eax) Which basically does not make any sense, because I don't have the mentioned inline assembly in any of the C files, and furthermore even if I did, that is completely valid inline assembly (BTS as per x86 assembly reference does not need w,l or q m...

.... I don't recall if there was a resolution. > Thanks for the link, completely missed when googled the issue. I think no consensus was reached (I cannot find any commit in the repository addressing such issues). I will try and search for the culprit of the inline assembly and replace it with btsl. As for the issue at hand, although after carefully reading both the thread and re-reading the sections from the instructions set reference it is a rather unpleasant behavior, the error thrown by the toolchain. Since Intel is nowadays by far the biggest vendor for x86/x86_64 hardware and they do n...

On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Hi, > > I happened to notice that linux.git uses plenty of btr and bts > instructions (not btrl, btrw, btsl, btsw). For examples, see > arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, > while GNU as is fine with them. Surely, there must be architectures > where the w/l variant is unavailable? Both variants have existed since the Intel 386. That said, we should probably...

On Nov 20, 2013, at 10:04 AM, Ghitulete Razvan <razvan.ghitulete at gmail.com> wrote: > <inline asm>:1:2: error: ambiguous instructions require an explicit > suffix (could be 'btsw', 'btsl', or 'btsq') > bts $14,(%eax) This has come up before <https://groups.google.com/forum/#!topic/llvm-dev/vomnIQjefzA>. I don't recall if there was a resolution. -- Stephen Checkoway

Hi, I am facing a problem.Suppose i made some QOS configuration using tc. But if system reboots, it disappears. How to make tc setting permanent. Regards, Raghuvendra Kumar | BTSL 414 | Ext 011-41619770 | Desk +91-9818143739 | Mobile raghuvendra.kumar@bhartitelesoft.com | EMail

...DSCP set 0x08 TOS udp -- anywhere anywhere TOS set Maximize-Th roughput TOS all -- anywhere anywhere TOS set Maximize-Th roughput Regards, Raghuvendra Kumar | BTSL 414 | Ext 011-41619770 | Desk +91-9818143739 | Mobile raghuvendra.kumar@bhartitelesoft.com | EMail

...its not working:- [root@scotch src]#tc filter add dev eth0 protocol ip u32 match ip dsfield 8 police drop its showing error "Illegal "match". Can any one of you guide me , what is the correct way of doing it. Its imporatnt, Please post reply ASAP. Raghuvendra Raghuvendra Kumar | BTSL 414 | Ext 011-41619770 | Desk +91-9818143739 | Mobile raghuvendra.kumar@bhartitelesoft.com | EMail

...AX: 2065676162726166 so rax is totally garbage, I think. It means obj_to_head returns garbage because get_first_obj_offset is utter crab because (page_idx / class->pages_per_zspage) was totally wrong. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 6408: f0 0f ba 28 00 lock btsl $0x0,(%rax) <snip> > > Could you test with [zsmalloc: keep first object offset in struct page] > > in mmotm? > > sure, I can. will it help, tho? we have a race condition here I think. I guess root cause is caused by get_first_obj_offset. Please test with it. Thanks!