"We Never Use Assembly Language"
in [ASM]
|
From: Frank Kotler on 19 Mar 2006 05:01 Betov wrote: > Betv. Well, that's one way to avoid naming conflicts! :) Best, Frnk
From: Betov on 19 Mar 2006 07:18 Frank Kotler <fbkotler(a)comcast.net> ?crivait news:P9udnYZA6 _SlsYDZnZ2dnUVZ_vydnZ2d(a)comcast.com: > Betov wrote: > >> Betv. > > Well, that's one way to avoid naming conflicts! :) Avoids also conflicting with the mnemonic: BTV :) Betov. < http://rosasm.org >
From: o//annabee on 19 Mar 2006 10:21 P? Sat, 18 Mar 2006 05:49:22 +0100, skrev sevagK <kahlinor(a)yahoo.com>: >> >> This are my timings on the AMD64 3700+ for 1_000_000_000 iterations >> >> Randall: 774c_e5f7 >> Mine: 774C_C9B3 >> > > I don't know about your mutant machine, Bee. > > Results vary, but typically on 1_000_000_000 iterations: > > Bee: 019D_24AA > Randall: 0192_9C75 This looks like you counter has ran over. But it is a strange result anyhow. > > With an average difference of about 50_000 advantage for Randall's > version, which is smaller than I expected, but still an advantage. Very strange results. > > Let's look at the workhorse loops: > > Wannabee: Randall: > w: w: > cmp ecx, 0 ... > jna endw ... > add eax, ecx add eax, ecx > dec ecx dec ecx > jmp w jnz w > endw: > > You're telling us that on your machine, the Wannabee is faster! Could > be, I don't know. I'm not there. Thats the result I get, yes. But it becomes slower when one insert more instructions. And Randall code is faster on the Athlon. > > -sevag.k > www.geocities.com/kahlinor >
From: o//annabee on 19 Mar 2006 10:57 P? Sun, 19 Mar 2006 01:35:13 +0100, skrev <rhyde(a)cs.ucr.edu>: >> To see how it should really be done. I looked at you page, >> and came up clean. Cant you just post the links? > > http://webster.cs.ucr.edu. > Whiner. Do a little work yourself. Again, if you were serious about > this, I'd help you out a little. But you're simply playing games, so > I'll continue to play along. I am not playing at all. I really want to see this 6 socalled non-trivial applications you wrote in assembly. I can find them. I found this link. Is this the applications you are talking about ? < http://webster.cs.ucr.edu/AsmTools/HLA/hla_examples/index.html > > Cheers, > Randy Hyde >
From: rhyde on 19 Mar 2006 19:54
Herbert Kleebauer wrote: > > > You can define any scope for variables or labels you like: > the whole program, a module, a procedure, a macro or > even 10 lines of code. Forgive me. I think I misled you. *I* did not define this term and I cannot take credit for its definition. I certainly don't want to give you that impression. I've simply used the well-accepted definition of the term in this discussion. > And any of this definitions gives > you a label which is local within this scope. But that doesn't > change anything on the fact, that the term "local label" > in assembly programming means a label which scope is limited > by the enclosing normal labels. The only person I know of who think thats *your* definition of a local label is the only valid definition for an "assembly" local label is you. Of course, Rene feels the same way about *his* definition. I find this whole point amusing. You are both correct insofar as what you are describing is *one* example of a local label. You are both wrong in insisting that your definitions are the "one true" definition of local labels in assembly language. Literally dozens of other assemblers have their own variants. Some assemblers have even more that one type of local label. How ego-centric of the two of you to think that *you're* the only ones who know what an "assembly" local label is. For that matter, for the life of me I cannot see why this concept is somehow tied to assembly language. The whole concept of a local label is relatively independent of the underlying language. For example, there is no reason your definition couldn't be used in Pascal, nor why Rene's definition couldn't be used in C, for example. > > Maybe you should read before writing. I said 'In assembly programming > a "local label" is ..' and not 'In most languages a "local label" is ...'. In most assemblers, local symbols are handled completely different than the way you handle them in your assembler. Yes, I've seen other assemblers (and, indeed, other languages) that use the same definition you use for one particular style of local symbol. That doesn't make your definition the "one true way" any more than Rene's method is the "one try way". Assembly language has nothing to do with this. > > When I say "in assembly programming an OR instruction is the bitwise > OR of two operands", then you answer: 'My, how limited your definition > of "OR in assembly language" is. > How do you explain, then, the concept > of "OR" in most languages? They are *not* defined to be only a > bitwise OR but can also be a logical OR'. Your problem seems to be, > that you never completely read a posting and then try to argue with > arguments completely out of the current context. Or when we're talking about what a local label is, how you change the subject to bitwise OR? Cheers, Randy Hyde |