From: sevagK on 17 Mar 2006 23:49 o//annabee wrote: > På Fri, 17 Mar 2006 03:25:27 +0100, skrev sevagK <kahlinor(a)yahoo.com>: > > > > > randyhyde(a)earthlink.net wrote: > >> > >> > > >> > This was tested on an AMD 64, 3700+ running win2000, > >> > >> And mine was tested on a PIV running XP. > >> > >> Randy Hyde > > > > I have an AMD 64 3400+ and the 2 routines run with your routine just > > *slightly* faster. > > Thats sound more and more incredible. In all tests here, on the new > machine, the RosAsm code ran faster for all iterations, and the same > diffrence applied for 10000 and 2 iterations. > For the Athlon, the RosAsm version was nearly twice as slow. > > > After 100 iterations of each loop, Wannabee's version falls behind by > > an average of about 400. > > What does this mean? Where are the code you tested, and are you to be > understood that the code ran slower and slower? > > > Of course, when dealing with billions of iterations, the score adds up, > > but if it you're pinching cycles, you probably won't be using macros! > > 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 With an average difference of about 50_000 advantage for Randall's version, which is smaller than I expected, but still an advantage. 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. -sevag.k www.geocities.com/kahlinor
From: Betov on 18 Mar 2006 02:59 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:441B2D8F.28D48BC4(a)unibwm.de: >> Then, explain what _you_ call "True Local Labels". > > abc: ... > bne.b _xy > ... > _10: ... > ... > beq.b _10 > ... > _xy: ... > ... > def: ... > > A label is local to the code between the two normal > labels abc: and def: if there is no way to access this > labels from code before abc: or after def: OK. This is exactely what RosAsm does. Simple difference, we use '@', instead of '_': abc: ... jne @xy ... @10: ... ... je @10 ... @xy: ... ... def: ... Another difference, is that RosAsm Pseudo Local Symbols can be evocated from outside the local scope: jmp abc(a)10 > I use four types of labels: > > abc:: A global label which scope is the complete file > abc: A normal label which scope is between two "label_block" > directives > _abc: A local label which scope is between two normal labels > .abc: Same as abc: but doesn't start a new scope for local > labels (allows an alternative entry point without > splitting the scope for local labels). > > With the label_block directive you can group the source in > modules. There is no problem to use the same names for normal > labels in different modules. You can access code in a different > module only by a global label. OK. This is a good solution for some types of Assemblers. If i would be interrested with this (i am not at all), i would do something similar by using the RosAsm TITLEs concept and by using them for defining a scope for pseudo locals. But as there is absolutely no need of this... Betov. < http://rosasm.org >
From: Betov on 18 Mar 2006 03:06 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:441B7226.C3FAA487 @unibwm.de: > Any label has a scope where it is defined and outside this > scope it is undefined. This is true for ANY label and has nothing > to do with local or not local labels. In assembly programming > a "local label" is label which scope is exactly the space between > two normal labels. This implicit defined scope for "local labels" > reduces the need to explicitly define the scope for a label Exactly, and this is what RosAsm does with Pseudo Local Symbols. Though, True Local Labels (My "True"), have no other scope than themselves, and no limitation, as required in _Assembly_, and as opposed to HLL Containment. Betov. < http://rosasm.org >
From: rhyde on 18 Mar 2006 14:45 Herbert Kleebauer wrote: > > No. Any label has a scope where it is defined and outside this > scope it is undefined. This is true for ANY label and has nothing > to do with local or not local labels. In assembly programming > a "local label" is label which scope is exactly the space between > two normal labels. This implicit defined scope for "local labels" > reduces the need to explicitly define the scope for a label. My, how limited your definition of "local label in assembly language" is. Like Rene, you seem to feel that the definition of a local symbol in *your* assembler is the only valid one. "There is only *one* true local symbol, the one *I've* defined", eh? How do you explain, then, the concept of local labels in most languages? They are *not* defined to be local between two symbols, but local when a given scope in the program. Indeed, a Google search for "Local Symbols" and "Local Labels" turns up *many* different variations on this theme. But don't take my word for it. Pick up a programming language design text book and see what it has to say about local symbols. Cheers, Randy Hyde
From: rhyde on 18 Mar 2006 14:47
Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> écrivait news:441B7226.C3FAA487 > @unibwm.de: > > > Any label has a scope where it is defined and outside this > > scope it is undefined. This is true for ANY label and has nothing > > to do with local or not local labels. In assembly programming > > a "local label" is label which scope is exactly the space between > > two normal labels. This implicit defined scope for "local labels" > > reduces the need to explicitly define the scope for a label > > Exactly, and this is what RosAsm does with Pseudo Local Symbols. > > Though, True Local Labels (My "True"), have no other scope than > themselves, and no limitation, as required in _Assembly_, and as > opposed to HLL Containment. Amusing. Both you and Herbert should look up the definition of "scope" sometime. I really like the <<(My "True")>>. That pretty much says it all. Cheers, Randy Hyde |