flat assembler
Message board for the users of flat assembler.

Index > Main > Anonymous labels not enough, need anonymous OPCODES

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
r22



Joined: 27 Dec 2004
Posts: 805
r22
I wouldn't recommend reading this ... it's long
Code:
@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 !
    


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!).

FYI: This WAS a joke

Anonymous labels don't add anything to the syntax. They promote spaghetti code especially if we start getting into the @2F and @9B extended variations of it. There's no gain in efficiency because you can just use .1 or .a for labels. (Maybe in macros where you have to define the labels as local... but then just adding extra functionality to the macro system would be a fix).

I don't care for the 'To each his own argument' or the 'other assemblers have anonymous labels in X variation' ... nor do I care for Tom Tobias's rambling 20page bull***t posts about Doctor Whats-His-Name's book about assembly that opposes anonymous labels.

Here's why I know anonymous labels are an annoyance...

It's another syntax variation that everyone else needs to be aware of so that they can quickly understand the minority's code.

If you just write code for yourself (not to share with the community or be used by others) than you using anonymous labels hurts absolutely no one, but its a feature that only you require so why not implement it yourself as your own custom feature? Why stop at using the @ sign why not use /\ and \/ infact have z/\ = jz @b and nz\/ = jnz @f. It's syntax that you want, that you can use and that you can implement without it being an issue.

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.

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.

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 we can all agree that writing your opinion on a subject won't change everyone's mind. So if you've read this whole post and have an opposing opinion I can honestly say "In all truthfulness and not trying to be rude, I do not care what you have to say on the subject."
Post 30 Jun 2007, 00:20
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
r22 wrote:
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.


Agreed.
So we would replace it by .loop, .else, .ifnull, right? WHAT?! So anonymous labels are stupid, but local labels are not... Why?

By the way, why not remove local labels too????????? Well... fasm is written completely without local labels. And I guess old assemblers didn't support them either...


So, we could use .loop1, .loop2, .loop3... I don't like it... whether you like it or not, it's just a matter of taste, but then you can still use your own approach. It doesn't hurt anybody...

If I had a big routine to process a file, my loop label would most likely be ".nextline" or ".nextopcode" or ".nextcommand" or else ".flagsloop" than an anonymous one. But if I just want to skip over 3 instructions on a specific condition, I wouldn't create a new name just for it...
OTOH, if I need a bunch of loops that all do the same thing, I do need anonymous. For example, If I needed to repeat many times some lines of code that will waste the rest of the current line of a file loaded in memory. Macros? No, thanks...

I don't like to put code in macros, unless it's very simple and changes no register. It's my coding style: I don't like to create macros that adulterate the language's semantics. For example, in C I don't like to define macros that look like functions able to modify variables that are not passed as pointers. Why? Because that's against C semantics: under normal conditions, functions cannot modify input arguments.
But I don't ask anyone to remove macro support from assemblers nor HLL, because people may have different coding styles, and that's entirely their problem.


GAS doesn't support local labels. Why?
GAS was invented to be able to compile GCC code. But GCC simply counts the order number of the label it's writing and increments it before writing the new label, so it doesn't need local labels.

Quote:
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.


And of course it's you who are going to define that "standard", aren't you?

I don't like "standard" ways of doing things.
If I thought that way, I wouldn't write assembly programs.

I don't understand how someone who supposedly uses fasm can talk about standard says of doing things...

Quote:
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.


Guess what kind of attitudes gives ASM programmers their bad reputation...

Quote:
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'll not comment this because here you just contradict yourself... after all, anonymous labels are old, or are they modern?

JJ
Post 30 Jun 2007, 03:05
View user's profile Send private message MSN Messenger Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
r22 wrote:
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!).


I forgot to mention that your entire analogy is just stupid, with nothing more to say about it...

JJ
Post 30 Jun 2007, 03:11
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
r22 wrote:
"In all truthfulness and not trying to be rude, I do not care what you have to say on the subject."


OK, so I'll speech freely because it will not bother you Wink

Now seriously, I think local labels is a great feature (actually the ability to define namespaces which in fasm is limited to one level only). 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.
Post 30 Jun 2007, 03:34
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Octasm supports 7 preceding anonymous labels and 8 forward anonymous labels. Granted, when reading code, you do have to count each one to find where it goes, but that (plus multiple instructions per line ... plus a few other things like ah=9 or push ax,bx etc.) has allowed OctaOS to be relatively terse compared to other "bloated" assembly code. Granted, I don't necessarily suggest that for everything, but it's a nice option to have, IMO.
Post 30 Jun 2007, 03:57
View user's profile Send private message Visit poster's website Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
LocoDelAssembly wrote:
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.


I try to avoid them too.

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

JJ
Post 30 Jun 2007, 05:02
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:
Anyway, do you know the way GAS does anonymous labels?
Well, you explained it here.
Since you can define N labels that way then I need to have a brain to be able to handle N counterintuitive numbers to know why execution can reach there and also I have to see the instruction sequence to know what it do (like if I were disassembling with symbol information stripped). Labels has to be self explanatory as much as possible, taking the license to use one level of anonimity I think it's good on some situations but more than that exceeds my preferences. If you still want GAS like syntax for anonymous labels a macrosed approach could be possible (though, the label has to start with some non-digit char and then followed by a number).

Altough I dislike the usage of this, preparing some macroses to support this syntax could be great since the already done macroses works by duplicating N times a character instead of using a number that obviously has less changes of typo errors.
Post 30 Jun 2007, 05:47
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
LocoDelAssembly, it's that sort of opinion that lead to half a dozen different syntax styles and no standardization.
Compiler1 ' I use anonymous labels, but only 1 layer deep'
Compiler2 'One layer isn't enough I'll support 2 layers!'
Compiler3 'I won't use the @ sign I'll use ^ sign and make it 9 layers.
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 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.

****************

rugxulo, source code doesn't need to be terse Very Happy But multiple instructions on a line seems useful to me unlike anonymous labeling. Especially if it's an instruction pair that logically would go together like
PUSH [mem1] POP [mem2]
, but then you run into the problem of some compilers would seperate them with a / (forward slash) and another might use just a space OR a comma OR // (2 forward slashes).

Thats kind of the point there are some usefull advances in syntax and some totally unneeded peices. Why can't we deprecate the useless peices and create an easier to learn standardized syntax?

*************

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

**************

@@:
Now all of you change your minds and stop being so horribly wrong.
jmp @B ;; UT OH !!!!!!!!!!!!!! Very Happy
Post 30 Jun 2007, 06:00
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

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.

In such case, which would be the benefits of having those four assembler syntax compatible over having just one? I think that asking assemblers to have all the same syntax is equivalent to asking Pascal to be syntax compatible with C and, why not, Haskell. The Assembly language by itself doesn't define much, is like to say I program in "High Level Language", you can't know the syntax because you don't know which exact language is used. Well, OK, HLL differences between each other is not so small as the differences between assemblers, lets call the assemblers Assembly language compilers of a particular dialect, the dialect the user wants to use and made the decision of using it.

Just in case I wasn't clear, I don't want this feature natively supported by fasm, only macrosed version.
Post 30 Jun 2007, 06:19
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
I think having just one syntax would be great.
I think if every compile just used the same set standard for macros like JavaScript that would go a long way.

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

It might not be a terse macro language but it would be understandable and easily usuable, and standardized.
Just for clarification I'm not saying every compiler would use the same macros (but being able to copy and paste a macro file that would work on every compile that would be amazing).

I think a standard macro language and directives would be great for ASM. It would make it more accessible to noobs, make it more convenient for programmers that aren't stuck in the past and willing to change a little to benefit the future of assembly programming, and it would obviously allow the whole asm community to work on bettering the syntax as a group rather than segregated chunks working on X_Compiler's specific stuff.
Post 30 Jun 2007, 07:15
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
r22 wrote:
Now Compiler3_User creates a great code snippet that Compiler1_User wants to use.


Either user of assembler 1 installs assembler 3 or converts the anonymous label syntax.
The only problem is if he is unable to identify the syntax.

Quote:
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.


This theory is beautiful, but now it's too late, and finding someone with such an authority over all assembler writers would be sooooo difficult...

And still you are forgetting GAS...

And where would be left space for the natural differences that all assemblers must have? Where would they be able to compete with each other?
Please consider that this doesn't apply to compilers. the process of translating HLL constructs to asm constructs is much more complex than the process of assembling some asm source. An assembler doesn't need optimization heuristics nor can they play with out-of-order-execution to raise code's performance...

Anyway, what really annoys me in your idea is the danger that your unified syntax proves to be a shit in the short/long term, like happens with many nowadays' syntaxes...
If we are going to unify the syntaxes, then I want an advanced way of doing anonymous labels. It could be also possible to create a guideline-like standard, that defines the logical structure of the code, where syntax for defining sections, macros, and things alike could vary between assemblers, but the features being present in every conforming assembler.
Perhaps it's also possible to define an unified language to configure the syntax... That would be great, together with the SSSO principle...
Another option would be an advanced text-manipulation syntax that would provide the need features to convert the source before feeding it to the preprocessor&assembler. This would be a generalization of the "offset equ " trick, but applicable to all types of assembly constructs... then, you could run the syntax with a gas2fasm script, to be run over the source between assembly, for example.

Neither way you would have everyone's acceptance. For example, MASM would never have the standard implemented! Wink

I have no idea of what happens in MIPS or PPC...

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


Because the mnemonics are already invented, and all you need to do is know them by heart (or have the most complicated of them written in a paper), but label names have to be invented by someone and need to be all different from each other...

JJ
Post 30 Jun 2007, 16:40
View user's profile Send private message MSN Messenger Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:

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.


NO thanks Sad I prefer FASM having its own well designed syntax (within INTEL's CPU design) and FASM providing compact and well working executables (80 KiB compiler only, 100...120 KiB with IDE Shocked ) from > 1 GiB mess packages Sad The idea "I'll add features of ALL competitors plus some more into my project" is indeed one of the most important reasons for excessive bloating and bugging Laughing

Check "modular" YASM for such "features" Wink

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


NO. They are very useful. Wink FASM supports one level only, the "most crappy" DJASM seems to support 3 (?), maybe having 2 levels in FASM would be good, but not more.
Post 30 Jun 2007, 21:28
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
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. I find annonymous lables incredibly difficult to read, and it annoys me when i try to read examples of this and that, but i find annonymous lables instead of well named lables. It's not like they need annonymous lables in these situations either... The way i see it, you're just setting yourself up for bugs when you use annonymous lables and plan on expanding your code. Who knows what all can happen from abuse of them.

Quote:
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.


Amen, and a big problem for fasm since it dosn't have nearly as many examples as MASM. Though, i will say, that a unified syntax would just end up with bloat. For example, look at MASM. I never used masm, but trusting it to assemble only what's used in those header files is like trusting a C++ compiler to compile perfectly efficient code every time. Though, some assemblers have syntax that's so low you are annoyed with it. Personally, i've looked at the syntax of a few assemblers, and i'm actually more comfortable with fasm, especially because it was the first assembler i found. I find that fasm has enough high-level-ish stuff that it isn't annoying to use, but not so high level that it's a compiler rather than an assembler. The headers are easy to read (though i havn't read the headers of other assemblers, but i've tried reading some of the ones that come with C and C++ compilers and they're an ugly mess) and if you think you can impliment something a better way, you can, but you probably don't need to cause the macros like invoke and such are straight forward enough.

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


I could elaborate on that to go further than just annonymous lables. Want to start mentioning many features in windows and other operating systems?
Post 01 Jul 2007, 11:48
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
kohlrak wrote:
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.


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

Quote:
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.


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?

For example, I don't like to put code in macros. I use macros for other purposes, but not for code.

JJ
Post 01 Jul 2007, 20:43
View user's profile Send private message MSN Messenger Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Yes, I think assemblers should follow some standard, even if only unofficially. For instance, ifdef should exist so you can at least test if the assembler supports such standard. 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. BTW, I guess AT&T-style is a minor standard, but I don't really use / like it.

However, Tomasz did write a few macros that helped emulate certain parts of other assemblers (NASM macros, MASM procs, "ax=4", etc). Others like Randy Hyde invented their own language (HLA, C--).

I did personally write some sed scripts to convert between ArrowASM (MASM subset) to various other assemblers (Octasm, NASM, NBASM32, LZASM, etc), but that only worked because I avoided macros and local labels and was only targeting 16-bit DOS. So, I ended up doing "my_proc:" and "my_proc_label:" instead of the customary ".label". Then, after-the-fact, I wrote LOC.BAT, which uses sed and temporary files to convert my labels into NASM / YASM short syntax. And since Octasm 0.15 (not the newest anymore!) maxed out at < 64k if EMS detected (otherwise used all mem), I wrote TINYLBL.BAT to shrink the memory-greedy labels to "az100:" etc. to save space and let it assemble (heck, it's only a silly 8k .COM, gosh).

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).
Post 01 Jul 2007, 22:57
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Macros are the only place in fasm where you don't need anonymous labels for anything, because you can declare the symbols local...


Then you don't need them at all. =)

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

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


But then we'd pretty much end up creating either meaingless terms or we'd reverse how fasm handles variables.

Quote:
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.


They're both useful if used right. They're there to represent code with one line. Chances are, if you're not willing to type it out for every operation, perhaps you're using the wrong macro and are lazy. Though, macro and struc abuse is a problem.

Quote:
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).


This is true. And even C/C++ and other HLLs also have cross compiler incapabilities. Everyone's a critic, but for me it's fasm.
Post 02 Jul 2007, 01:04
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
kohlrak wrote:
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.


Control+Fed? What's that?

Quote:
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.


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

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?
Also, HLL programmers don't use named labels when they program loops and still don't get confused!...

Although, I agree that, sometimes, finding a suitable name for a label is easier that at first it looks like.

JJ
Post 02 Jul 2007, 16:27
View user's profile Send private message MSN Messenger Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
kohlrak wrote:
@@ is just plain unreadable.


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

JJ
Post 02 Jul 2007, 16:33
View user's profile Send private message MSN Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Jeronimus, if you want to repeat labels remember you can always take advantage of namespaces. Example
Code:
procA:
  .label1:
  .label2:
  .label3:
procB:
  .label1:
  .label2:
    

That compiles perfectly and the code below "procA" will refer to its own .label1 and .label2 labels and the same with procB. If you want to access local scope labels globally you can refer to them with procA.label1, procB.label1, etc.
Post 02 Jul 2007, 17:29
View user's profile Send private message Reply with quote
Jeronimus Linuxius



Joined: 28 Jun 2007
Posts: 37
Jeronimus Linuxius
LocoDelAssembly wrote:
Jeronimus, if you want to repeat labels remember you can always take advantage of namespaces.


I also thought it could be useful to have multi-level namespaces...

For example, if you want to divide your program in subsystems you could have one namespace per subsystem, and then local labels inside functions... The syntax could even vary across different levels...

For Example:
Code:
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

}
    


Of course the syntax could be different...
And... this can be easily implemented as macros...
:-)

This would be adequate because of ASM usual programming style (indeed, the same that happens with anonymous labels... for some reason no one needs anonymous lbls in C), and in particular FASM's usual programming style... (because you have no way to isolate a symbol inside the file where it happens)...
However, I understand that this is not an usual problem...

JJ
Post 02 Jul 2007, 18:45
View user's profile Send private message MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.