From: sevagK on

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

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

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