Control+Fed? What's that?

Sometimes this isn't possible, and you are not considering what I said: if I want to repeat the same code many times.

Also, HLL programmers don't use named labels when they program loops and still don't get confused!...

For example, if I'm processing a raw command arguments string, I need to catch many tokens that can separate the arguments, so I can't use "repne scasb". Now suppose that I need to repeat this same portion of code many times. WHAT different names am I supposed to give the loop?

Can you point me to some code that uses plenty of anonymous labels for me to make my own read test?

LANG OCTASM,0.1 \\RD\OCTA.ASM
{gui\new\t3(320,240,"%nb fire")
edi=[window] b[edi+gui\flags]|=4 ;window resizable
 wait_ms1(40) edi=Paleta
# stosd eax+=40100h cmp ah,63 jc <1
# stosd eax+=0fd0002h inc ah jns <1
# stosd inc al ah-=2 jnz <1
#l0 ebp=[winx] ecx=ebp ecx<<=7
 ecx=ecx+ebp*2 edi=[img]
 mresize() [img]=edi
#l1 edi=ebp edi<<=7 edi+=[img]
 ecx=ebp eax=[rnd] ecx>>=2
# ebx=eax-1 rol eax,9 ebx-=eax
 eax-=ebx stosd loop <1
 [rnd]=eax edi=[img] ecx=ebp ecx<<=7
# eax=b[edi-1+ebp] bx=[edi+ebp]
 al+=bl adc ah,0 al+=bh adc ah,0
 al+=[edi+ebp*2] adc ah,0 eax>>=2
 eax-=1 adc al,0 stosb loop <1
 al=11 setvideofuncion() d[bmp]=[img]
 d[paleta]=Paleta esi=[winy] ebx=esi
 ebx>>=7 edx=esi edx&=127 eax=0
 edx-=126 esi=128 ecx=ebp jmp >2
# d[bmp]-=ebp inc edx
# lh2() dec bh jns <2
# bh=bl inc edx dec esi jnz <2
# getd() jnc >1
 wait_ms2(40) jnc l1
 del_msg() cmp [winx],ebp je <1 jmp l0
# edi=[img] free() ret
D(rnd,img) #Paleta rb 1024}
    

Quote:

Control+Fed? What's that?

Hold down control and press f to find out...

Quote:

Sometimes this isn't possible, and you are not considering what I said: if I want to repeat the same code many times.

Why isn't it possible? And i did consider what you said. Every opcode in your program does something, every section does something, so i find it hard to believe some one can't come up with a half creative name.

Quote:

Also, HLL programmers don't use named labels when they program loops and still don't get confused!...

That's cause they enclose in brackets. They don't see the jmp and cmp and such.

Quote:

For example, if I'm processing a raw command arguments string, I need to catch many tokens that can separate the arguments, so I can't use "repne scasb". Now suppose that I need to repeat this same portion of code many times. WHAT different names am I supposed to give the loop?

Personally, I'd use the same loop and just change the base to the address of each argument and use a conditional jump for the number of remaining strings.

Here's FIRE.ASM from the latest OctaOS, see if you like it. ;)

Code:

(...)    

Of course, but if they enclose groups of statements in brackets (which don't have names), what's the problem if an asm programmer encloses groups of instructions in anonymous labels? That's just a matter of indentating the anonymous labels differently from normal code and from other labels.

For other uses where you might advocate anonymous labels, macros can be utilized instead (and are better than mindless copy-paste duplication anyway).

sub ebx, eax
jnb @f
mov ebx, 0 ;set to 0 in case of underflow
@@:    

sub ebx, eax
.if not CARRY?
  mov ebx, 0
.endif    

So do you really think that opening the find window and writing the label name makes it simpler to deal with local labels than with anonymous?

Difficult because at some point you may need to express similar ideas in more than one label.

Of course, but if they enclose groups of statements in brackets (which don't have names), what's the problem if an asm programmer encloses groups of instructions in anonymous labels? That's just a matter of indentating the anonymous labels differently from normal code and from other labels.

Sometimes we need to alternately test for a different set of characters, and this can complicate things...

Now, I don't understand what's your problem with anonymous labels. If you don't need them, that's your busyness, but I think their absence is a lack...

i wouldn't agree here. For simple small jump-over-something, anonymous label looks better than if to me:

Small jumps usually aren't a major problem... But how often do we have small jumps?

pretty often

Quote:

Small jumps usually aren't a major problem... But how often do we have small jumps?

pretty often ;)

WARNING: OFF TOPIC PARAGRAPH - Well how big are they? One op or more when they're frequent? From what i've been told by a few docs, jmps clear the prefetch queue (i think that's what it was called) every time you use them.

This is definitely a topic for another thread, but perhaps it would be slightly more speed efficient for that reson (though not very space efficient) to start implimention of conditional operations, such as movinb (move if not below) which could follow a cmp (verses compairing and conditionals in one operation which i feel dosn't allow as much freedom, but to everyone his own). Though, this is all based on old documentation.

Quote:

pretty often

I seldom have small jumps, perhaps why i'm so against them. Though, i can't argue with anonymous labels for small jumps. I'm just sick of seeing them used for really big jumps, especially when mixed with named labels, some of which are in between the jump. Though, i purposely loose track of such ugly code.

Quote:

So do you really think that opening the find window and writing the label name makes it simpler to deal with local labels than with anonymous?

Yelp...

Quote:

Difficult because at some point you may need to express similar ideas in more than one label.

I've come accross this situation once for multiple window procs. For when i don't handle a message, i usually name a lable such as "go" or "notsupported." Though, i've found that in a situation like that, you could just add the name of the window or the proc for the window infront of the lable.

Quote:

Of course, but if they enclose groups of statements in brackets (which don't have names), what's the problem if an asm programmer encloses groups of instructions in anonymous labels? That's just a matter of indentating the anonymous labels differently from normal code and from other labels.

The fact that brackets keep code together, anonymous labels have a tendency to sprawl themselves all out over a large distance of code.

Quote:

Sometimes we need to alternately test for a different set of characters, and this can complicate things...

You can always set the base to the base of the string.

Quote:

Now, I don't understand what's your problem with anonymous labels. If you don't need them, that's your busyness, but I think their absence is a lack...

The fact that we still have to read it. You may be writing it, but we end up reading it.

Quote:

i wouldn't agree here. For simple small jump-over-something, anonymous label looks better than if to me:

Small jumps usually aren't a major problem... But how often do we have small jumps?

I'm not an expert in CPU architecture, but as far as I know, branch predictors are there exactly to prevent this...

a theory about whether they are likely to be followed or not is built by the prefetch queue, and the prefetch advances accordingly

The only problem with cmov* is that they do not exist in processors prior to Pentium Pro... Conditional assembly can be the solution here...

cmp eax, 0
movib [eaxwentzero], 0    

PS: Please, *do* reread your posts and pass it through a spell checker before sending them... "anonymous" has only one "n", "labels" are not "lables", and "purposely" is not "purpously"... This is not a personal attack, but I'm tired of this kind of mistakes...

Namespace tricks are not absolute answers to the problem we are discussing because namespaces have limits.
Of course namespaces can help avoiding the problem to a great extend, but it still exists.

They only "tend" if the programmer wants to...

Correct if I'm wrong, but I think it was YOU who told that jumps flush the prefetch queue!...

What do you think about those who want to write code to fasm and have to look for free names every time they want to define a label, because the namespace is overfilled cause the code doesn't even use local labels?

Features can't be removed just because half a dozen of people think that they make it difficult to deal with the code.
Better having them used only be those who want them than removing and rendering them completely unusable.

We have them quite often... Think if you want to print something to the screen if a given condition is met...

cmovxx, wouldn't that be comparing and doing things in one operation or am i thinking of another instruction..? What i'm talking about is more along the lines of this...

Jeronimus Linuxius wrote:

PS: Please, *do* reread your posts and pass it through a spell checker before sending them... "anonymous" has only one "n", "labels" are not "lables", and "purposely" is not "purpously"... This is not a personal attack, but I'm tired of this kind of mistakes...

Have one handy that's not bloated.

Jeronimus Linuxius wrote:

What do you think about those who want to write code to fasm and have to look for free names every time they want to define a label, because the namespace is overfilled cause the code doesn't even use local labels?

I think they need to find a better namespace name.

While the CMOVxx instruction does get rid of branch prediction, it still imposes a dependency, so you should still try to do branchless solutions if you can.

The spell checker of firefox2 works pretty well and isn't too bad.

Also note that CMOVcc r32, r32 in 64bit mode clears upper 32 bits of destination operand even if condition is false

They need to use local labels... local labels are perfectly fine, and you'd be an idiot not to use them.

While the CMOVxx instruction does get rid of branch prediction, it still imposes a dependency, so you should still try to do branchless solutions if you can.

f0dder wrote:

I have a pentium 4, so i'm assuming that i can't use it anyway... Though i think people could benefit from more than just a mov that's like that.

vid wrote:

Also note that CMOVcc r32, r32 in 64bit mode clears upper 32 bits of destination operand even if condition is false

Oh fun...

f0dder wrote:

They need to use local labels... local labels are perfectly fine, and you'd be an idiot not to use them.

I personally don't bother with local lables, but then again, i've never had trouble with not having enough names either.

CMOV was introduced in the PPRO... PPRO was the cpu introduced between the pentium and the pentium-II. In other words, it's age old, and you can use it on your P4.

X86-64 is such a hack

If you have, say, a bunch of color-conversion routines for different source and dest formats, which is cleaner? Label names like cnvRGB888_RGB565_scanloop:, or simply .scanloop: inside your cnvXXX_XXX functions?