search for: 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

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. Unfortun...

I'm confused a bit about the following and was hoping to get some answers on this group - What is exactly implied when we say asterisk can connect to a PSTN. Does it mean connecting to the PSTN via PRI/T1/E1? If yes, then I assume asterisk does not need to do any SS7 signaling and all it does (playing the role of a PBX) is to connect to a Class 5 Switch at the CO. Is this a correct statement?

(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...

Anyone on this list have extensive experience with BTS? http://deancollinsblog.blogspot.com/2009/03/open-bts.html Please email me, particularly if you have experience in deploying over multiple cells covering large geographical areas (200k's sq). Regards, Dean Collins Cognation Inc dean at cognation.net <mailto:dean at cognation...

...monics? Where are the authoritative instruction set pages? If such a thing were readily available, why are there gaps in the current implementation? A quick Googling gets me [1], but I can't say it's authoritative. What's important is that there certainly are architectures where btr/bts are valid instructions, and they must be supported. btr/bts are certainly not invalid instructions that we're bending over backwards to support, because linux.git/gas works with them. [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html

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 correctly, following the exam...

...sbach 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.

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 can help by clarifying via explicit example what code you > believe should work but does that. Descriptions are great,...

...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 >> 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 corr...

...p, it’s the 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

...he authoritative instruction set pages? If such a thing > were readily available, why are there gaps in the current > implementation? A quick Googling gets me [1], but I can't say it's > authoritative. What's important is that there certainly are > architectures where btr/bts are valid instructions, and they must be > supported. btr/bts are certainly not invalid instructions that we're > bending over backwards to support, because linux.git/gas works with > them. > > [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html > _ The correct answer h...

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)....

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.

...rectly according the the documented Intel assembly mnemonics? If the former, the fix belongs in the project, not the assembler. If the latter, then we should absolutely fix the assembler. From your emails, it is unclear to me which is the case. -Jim > I wrote: >> The instructions btr and bts are perfectly valid, and have existed since >> Intel 386. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/4f50d063/attachment.html>

...instruction set pages? If such a thing >> were readily available, why are there gaps in the current >> implementation? A quick Googling gets me [1], but I can't say it's >> authoritative. What's important is that there certainly are >> architectures where btr/bts are valid instructions, and they must be >> supported. btr/bts are certainly not invalid instructions that we're >> bending over backwards to support, because linux.git/gas works with >> them. >> >> [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html >&gt...

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 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 t...

...onics? Where are the authoritative instruction set pages? If such a thing were readily available, why are there gaps in the current implementation? A quick Googling gets me [1], but I can't say it's authoritative. What's important is that there certainly are architectures where btr/bts are valid instructions, and they must be supported. btr/bts are certainly not invalid instructions that we're bending over backwards to support, because linux.git/gas works with them. [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html _ The correct answer here is "Vol 2a of the I...

I have Civ4 BTS 3.17 installed and running on Ubuntu 8.10 using Wine 1.1.13. The game seems to be OK but I have been playing the Fall from Heaven 2 mod recently and the data for the Great Library used within the game is corrupted (sages being given ridiculously large espionage bonuses). The xml files on disk are f...