@F eax,eax
xor ecx,ecx
@B edx,edx
;;NOW I DONT HAVE TO TYPE XOR 3 times saves *** 2 *** ascii characters of my time !
    

If your porting older (or just from another assembler) code that uses anonymous labels why not improve the code by adding labels like .loop, .else, .ifnull, etc.

There might be a lot of RIGHT ways to do something but there's only ONE STANDARD way to do something. ASM like everything else that's useful needs a STANDARD way of doing things.

This may really apply more to macro creation and including files as well, but one old fool in the 1960's thought 'well I don't like typing label names lets use @ signs' and instead of doing something about it back then, everyone just accepted it and now every ASM compiler from then on had to implement anonymous labels.

I just can't see how an old totally useless feature is allowed to live on for so long. It's like having a [ CD\ ] key on a modern keyboard, no one's used DOS for ages, no one would find it useful, and anyone that WOULD find it useful should have no say in how modern technology should be developed.

I think the @ sign is stupid to use we should use Z because no opcode names start with z so zf and zb and z2f and z2b are easier to type (having to hold the shift key down to make @'s is asinine!).

"In all truthfulness and not trying to be rude, I do not care what you have to say on the subject."

About anonymous labels I prefer to avoid them but sometimes I think them suit perfectly. But, definitively, no more than one level of anonymous labels should be allowed (current implementation), because it really start to be a pain with more levels.

Anyway, do you know the way GAS does anonymous labels?

Imagine if just FASM, MASM, NASM, YASM where fully syntax compatible with eachother (even the macros). Sharing code would be so much easier and the COMMUNITY AS A WHOLE would benefit.

MACRO javascriptRegisterShift(){
  if(arguments.length > 1){
    writeln("PUSH " + arguments[arguments.length-1];
  }
  for(var i=arguments.length-2; i>=0; i--){
    writeln("MOV " + arguments[i+1] + ", " + arguments[i];
  }
  if(arguments.length > 1){
    writeln("POP " + arguments[0]);
  }
}

jsRegisterShift('eax','ebx','ecx','edx')
=
PUSH edx
MOV edx,ecx
MOV ecx,ebx
MOV ebx,eax
POP eax
    

Now Compiler3_User creates a great code snippet that Compiler1_User wants to use.

Imagine if just FASM, MASM, NASM, YASM where fully syntax compatible with each other (even the macros). Sharing code would be so much easier and the COMMUNITY AS A WHOLE would benefit. And if a new syntax feature was found to be really useful by the majority then i'd would be added.

Jeronimus Linuxius, I don't know why my ANONYMOUS OPCODE idea is any more rediculous than the ANONYMOUS LABELS you like to use

Imagine if just FASM, MASM, NASM, YASM where fully syntax compatible with eachother (even the macros). Sharing code would be so much easier and the COMMUNITY AS A WHOLE would benefit. And if a new syntax feature was found to be really useful by the majority then i'd would be added.

I think the whole anonymous thing was a bad feature when it was firswt implemented and we should finally deprecate it.

Whats the biggest problem in ASM? I have this code in X assembler and I want to port it to Y assembler. ARE WE ALL SO FREAKEN STUBBORN THAT WE CAN'T SETTLE ON A UNIFIED SYNTAX? The 'just let them do what they want' and 'me using it doesn't hurt you' doesn't fly, it causes variation and extra bloat in the syntax WE ALL use.

I just can't see how an old totally useless feature is allowed to live on for so long.

I obviously missed a topic... Oh well... too lazy to read everything here, but i'll point out that i think annonymous lables are annoying, but within a macro they have their purpose when used with fasm.

It's not like they need anonymous labels in these situations either... The way i see it, you're just setting yourself up for bugs when you use anonymous labels and plan on expanding your code. Who knows what all can happen from abuse of them.

Macros are the only place in fasm where you don't need anonymous labels for anything, because you can declare the symbols local...

Setting yourself up for bugs is what happens when you start naming labels as loop1:, loop2:, loop3:, etc... What if you want to repeat that same code many times and don't want to use macros?

And when you start renumbering the labels, you end up forgetting to update a bunch of them?

And macro should be there as well as offset and ptr (compatibility).

But I dislike struc because no one seems to agree on it (heck, I hate 'em but some people love 'em to death). Even macros (which can be useful in theory) are often overutilized and the syntax becomes more HLLish (and hellish) than plain "vanilla" assembly.

But whatever. Good luck getting anybody to agree. FASM is not NASM is not MASM. They are wildly different, intended for wholly different audiences (well, maybe less so NASM and FASM, but you know what I mean).

Quote:

Setting yourself up for bugs is what happens when you start naming labels as loop1:, loop2:, loop3:, etc... What if you want to repeat that same code many times and don't want to use macros?

Numbered loops isn't an intelligent idea, but at least it can be control+Fed... Also, it's much more readable than guessing which label it's supposed to be. @@ is just plain unreadable.

Quote:

And when you start renumbering the labels, you end up forgetting to update a bunch of them?

Your own dumb fault for not giving them a better name, perhaps one that has something to do with what that loop does.

@@ is just plain unreadable.

procA:
  .label1:
  .label2:
  .label3:
procB:
  .label1:
  .label2:
    

Jeronimus, if you want to repeat labels remember you can always take advantage of namespaces.

start:
                 mov edx, .filenm
                 mov ecx, .filenm.size
                 mov edi, 0x100000
                 call floppy:readfile

                  jmp 0x100000

                  jmp $

.filenm db "KERNEL.IMG", 0
     .filenm.size = $-.filenm



namespace floppy{

read_file:
      .sectorloop:
      .directory_entry_loop:
                   ret


delete_file:
      .sectorloop:
      .directory_entry_loop:
                   ret

}

namespace ata{

read_file:
      .sectorloop:
      .directory_entry_loop:
                   ret


delete_file:
      .sectorloop:
      .directory_entry_loop:
                   ret

}