"We Never Use Assembly Language"
in [ASM]
|
From: Herbert Kleebauer on 17 Mar 2006 16:43 Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:441B0C31.87095726 > 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: 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. > Are you talking of local Scope? If yes, this is what > RosAsm does, with the '@' thingie, by considering the > scope to be in between two Plain (normal) Labels.But No, your "'@' thingie" does not have a local scope. At least this is what you said in your last posting: ... "@1:" if you want... Which can even be called from any "external" point of the Routine by some: jmp MainLabel@1 ... and internaly by: jmp @1 It can be accessed from outside by using "MainLabel@1" and therefore it isn't local. If you change the name from @1 to @2 then you have to check the complete program whether it is used from outside by it's long name "MainLabel@1". If it would be a local label, this wouldn't be necessary because it couldn't be accessed from outside. > using these can have no effect but making the Macros > Declarations a bit more complicated to develop. I like No. With true local labels it would be much easier than with your L1> labels. You could nest macros to any level without having the user to take care about label conflicts. > > With your version of "True Local labels" > > you have the problem with: > > > > jmp L1> > > abc > > L1: > > > > if the macro abc also uses the label L1. > > The reason why it is recommanded to reserve "L" for > "everydays programming", and the other chars for Macros: > "W" for "While", "I" for "If", "D" for "Do", and so on. Why should the user take care of this, when it easily can be done by the assembler by adding a unique number for each macro expansion as explained here: > > If you would use normal local labels then there wouldn't be any problem. > > Use a counter and with each expansion of a macro increment this counter > > and push it's value onto a label stack. Then append the value at the > > top of stack to any local label within the macro (separated by an > > invalid character for label names). This makes any local label > > within the macro unique. At the end of the macro pop the value from > > the label stack. This way you can nest macros to any number > > without any label problem. > > Oh, yes, this is very possible to do. We would just have > to write the User Macro managing a Macro variable this > way, but it is way simpler with True Local Labels. The user has nothing to do. He simple uses local labels in his macros and the assembler takes care that there is no conflict. > > As I already said, this has nothing to do with local labels > > but is only a way to save typing. > > Agrea. This is what i call "_Pseudo_ Local Labels". That is, > in fact, internally, they are not any Local, at all. Yes it > is just for saving typings, but it also saves the programmer > from having to invent complete new Names every now and then, > for "one shot Locations". No, it is only to reduce typing. There is no difference (concerning "invent complete new Names") whether you write: abc: ... ... @1: ... ... or: abc: ... ... abc@1:... ...
From: randyhyde@earthlink.net on 17 Mar 2006 17:14 Dragontamer wrote: > > > > You can call your relative local symbol scheme whatever you like, but > > it doesn't make up for the fact that you don't have local symbols in > > macros. > > Do you mean Hygenic macros Randal? "Hygenic" means something else entirely. And no, L0 is not a symbol that is local to the macro. From the macro's perspective, it is a global symbol. > I mean; L0: does count as a "local > label", whereas Hygenic macros guarentee that variable names (and i > guess > in this case; label names) won't conflict with the rest of the code. Again, RosAsm has no concept of *anything* being local to the macro in the sense of scoped items. Again, "hygenic" denotes something else entirely. > > Or maybe it is only a lisp/scheme term. Or Dylan. Or any of a bunch of other languages that support Hygenic macros. Then again, hygenic systems do have their drawbacks too. Sometimes macros are useful because of the side effects they cause within the context in which they appear. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 17 Mar 2006 17:42 It is amusing to read this discussion of local symbols. "I have the only true local symbols!" "No! I have the only true form." Obviously, there are some people who don't have a clue what "local" means (though Herbert is much closer on the mark). Dudes, "local" means "limited to some predefined scope." For example, one definition might be "limited to the scope between two regular labels." Another form might be "limited to the scope of statements between two labels of the form Ln (where n=0..9)." These are all instances of "local symbol types" but by no means are the the "one true path." Rene's insistence that "true" local symbols not appear in the symbol table is ludicrous. He is insisting that a language facility have a specific implementation. Nowhere in any language design textbook would you find such a ridiculous statement. Whether local symbols are maintained in the regular symbol table, a special symbol table for locals, or whether the assembler actually scans the source file for the target location is irrelevant. I.e., if someone wrote the RosAsm assembler and stored all those Xn symbols in the symbol table, it wouldn't change the behavior or the semantics of the RosAsm definition at all. Attempting to peg the definition of "true" local symbols to some implementation is a classic example of Rene figuring out how to do something one specific say and then announcing to the world that this is the *only* true way to do it. Such proclamations simply demonstrate his ignorance of algorithm and language design. Now let's consider the *real* argument at hand -- local symbols in macros. The *scope* of the macro is defined as the context of a given macro expansion. It has nothing to do with the syntax for the label itself (there is no requirement that it take a specific form, such as one involving a numeric digit); it has nothing to do with other symbols. It has nothing to do with forwards or backwards from a given reference to the label. It has nothing to do with where that symbol appears internal to the assembler during compilation. I has nothing to do with how the macro processor represents that symbol internally during compilation (i.e., it could very well translate the symbol to some globally unique symbol, unique for each macro invocation, and that would be fine too). All that a "local macro symbol" implies is that on any given macro expansion, that symbol is unique to that expansion and not available to code outside the expansion. In general, a "true local symbol" is one whose usage is bound to a particular scope in the program, and outside that scope the attributes bound to that symbol are undefined. Trying to claim that a "true local symbol" only applies to a specific implementation or form of local symbols is about as absurd as saying "the only true eggs come from chickens". Another absurdity on Rene's part is his claim that local symbols must be named Xn (X=A..Z, n=0..9) because people shouldn't have to dream up "imaginative names". This argument is about as successful as his claim that assemblers that force the user to write a single source file are better then those that allow separate compilation. After all, if someone has a local symbol definition that allows arbitrary names, then they can use the (rather poor) names Xn and ignore all the other possibilities; and by doing so achieve everything that is possible with Rene's scheme. OTOH, if a RosAsm user decides they want to use more meaningful names for local symbols when they want to limit the scope of a name, but there exists good reason for using a meaningful name, they're stuck. Cheers, Randy Hyde
From: Dragontamer on 17 Mar 2006 20:23 randyhyde(a)earthlink.net wrote: > Or Dylan. Or any of a bunch of other languages that support Hygenic > macros. Then again, hygenic systems do have their drawbacks too. > Sometimes macros are useful because of the side effects they cause > within the context in which they appear. Of course; thats why people want both hygenic and non-hygenic macros :) There is never a "catch all" solution. --Dragontamer
From: Herbert Kleebauer on 17 Mar 2006 21:36
"randyhyde(a)earthlink.net" wrote: > Dudes, "local" means "limited to some predefined scope." > In general, a "true local symbol" is one whose usage is bound to a > particular scope in the program, and outside that scope the attributes > bound to that symbol are undefined. 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. |