"We Never Use Assembly Language"
in [ASM]
|
From: Betov on 17 Mar 2006 04:49 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:441A7877.7D3CF3E4 @unibwm.de: > Because you repeat it again and again I'm now curiously. > What exact is a "true" local label an why are other > local labels not "true"? What is the advantage of > "true" local labels compared to "normal" local labels? > And what are "pseudo local labels", are they even better > than "true local labels". A True Local Label is a Label that can be re-use any number of time at any place. Internaly speacking this is a symbol that does not belong to the Symbols Table and which distance is computed relatively to its evocation, a direct way, up or down. Take the example of FASM, and see: < http://board.flatassembler.net/topic.php?t=4716 > .... which show clearly at what extend the other implementations may suck, and be subject to painful debates, and irritating limitations. There are two major advantages with True Local Symbols. 1) They offer no practical limit to the "meaningless Labels Symbols". 2) They work as well in wild code as in Macros HLLisms, without any practical limitations in the nestings. At a formal point view, i took my model from A86, which has, in my humble opinion, the best implementation, in that matter, and i improved it a little bit, by implementing the four directions markers, short and long: JC L0< // L0> // L0<< // L0>>... "L0" being "L0<" by default). Betov. < http://rosasm.org >
From: Frank Kotler on 17 Mar 2006 09:14 Betov wrote: .... > You recall me of this old story, at the time the Jumps Predictions > had been implemented. As you may know, Intell proposed _NO_ Mnemonic > for these two things. Actually, they've already *got* mnemonics - "cs" and "ds", or however you represent segment override prefixes. Define 'em as something else, if that's too straightforward... :) > So we had a discussion in between four Assemblers > Authors. There was Jeremy, me, somebody for NASM (Frank, i suppose), The entire Nasm development team, as I recall... > and the Author of A86. We discussed about this unsignificant detail > for _WEEKS_. Result... each one his own, dispiting my efforts! I even > remove _MY_ proposition, and voted for one, coming from one of the NASM > participants... and i am the only one using it: LTJ // UTJ. I'm really sorry about that. I was getting private mail from - well, "nasm64developer", I suppose - urging me to vote for something with an underscore in it, as I recall, that RosAsm didn't like, because he'd already implemented it that way. My apologies. > Well, after this, go and dream about whatever you like... I'm afraid you're right. Best, Frank
From: Herbert Kleebauer on 17 Mar 2006 14:21 Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> ?crivait > > What's so difficult to use local labels like > > _1: > > _2: > I suppose you mean "Pseudo Local Labels"... > > I am not absolutely sure, but i think that this kind ot Label, > in FASM, for example, are in the internal form of: > > "PreviousNormalLabel_1". This is only a way to save typing but has nothing to do with local labels. If it is a local label, then it is only valid between the enclosing normal labels and you never can access it from outside of this enclosing normal labels. The main propose of local labels is, to ensure that a procedure can only be entered at given entry points (and not at a label inside the procedure) and not to save typing. This way you can change the local label names at any time without having an effect to the outside. This also has the advantage, that you only have to search the label table for current local labels and normal labels but not for local labels outside current local scope. > Something like these are very likely stored in the normal Symbols > Table of FASM. I am close to 100% sure of this. Because they are not local labels. > 1) This method does _not_ guaranty unique labels at 100%. If the "." is not a valid character for labels, then "last_normal_label.local_label" is unique. But still this has nothing to do with local labels. > 2) It reduces the possibilities from 260 to 10. (What for?). ????? > 3) The very true reason why i strongly recommand to the RosAsm > users to always set their Labels _short_, when developping, > and to wait for the Assembler to show them an error if made > too long, while writting, in between, is exactly, the problem > of security you point to. This kind of bug, is effectively, > both very easy to do, and very difficult to point out, once > done. If you would use "true local labels" (and with true I mean really true and not what you call true), then this problem wouldn't exist at all. > Then, a point that you seem to not see, is that RosAsm True Local > labels, are first dedicated to _Macros_ HLLisms. When used that > way, no error is possible, in practice, once the Macros Set is > considered perfect. At a readability point of view, Macros HLLisms > are way better than Local Labels. The very best solution is to NOT > see these labels at all, in a source, if possible. Don't understand this. 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. 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. > Now, everything you propose above, is already existing in RosAsm > Syntax. Not in the formal form of "_1:" but in the form of: > > "@WhatezverYouWant:" > > ... "@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 As I already said, this has nothing to do with local labels but is only a way to save typing. > Though this is a method that i do not recommand because True > Local Labels are _WAY_ better. True. But only if you use true local labels (only accessible within the scope of the local labels) and not labels which you call "true".
From: Betov on 17 Mar 2006 14:41 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:441B0C31.87095726 @unibwm.de: > If you would use "true local labels" (and with true I mean really > true and not what you call true), then this problem wouldn't > exist at all. Then, explain what _you_ call "True Local Labels". 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 using these can have no effect but making the Macros Declarations a bit more complicated to develop. I like simplicity and ease of use, and i think i can say that i am right on this point, because... the RosAsm users _do_ use them (as opposed tho what can be seen in most other Assemblers Sources). > 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. > 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. >> Now, everything you propose above, is already existing in RosAsm >> Syntax. Not in the formal form of "_1:" but in the form of: >> >> "@WhatezverYouWant:" >> >> ... "@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 > > 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". Betov. < http://rosasm.org >
From: Dragontamer on 17 Mar 2006 15:11
Herbert Kleebauer wrote: > Betov wrote: > > 2) It reduces the possibilities from 260 to 10. (What for?). > > ????? Herbert, I think Betov thinks when you say _1 and _2, to limit it at _9 and that is it. But you probably aren't used to that kind of thinking :-) Betov; what Herbert probably wanted to point out is that _10 would be a local label as well. As is _100 and _1000 and _1000000 giving you as many local labels as you need. And I've had a Eurika moment as well. The reason > and >> are into the assembler is a round-about way of preventing the super-long jump to the wrong local label in RosAsm. (As if jmp L0 > is too far away because you've defined it 5000 lines away, it won't jump as it is too far) Frankly speaking; I think it is a bad idea to use anonymous labels period, so you shouldn't have the > or >> built into an assembler to prevent that kind of error. But I guess it is reasonable for someone to use such a crippled tool like that to defend > or >>. Operant conditioning at work; ya? Add in classical conditioning (pair up the reward of the lack of debugging with > and >> because your local labels suck) and volia; now we know why Betov and Wannabie like doing things like that. > > 3) The very true reason why i strongly recommand to the RosAsm > > users to always set their Labels _short_, when developping, > > and to wait for the Assembler to show them an error if made > > too long, while writting, in between, is exactly, the problem > > of security you point to. This kind of bug, is effectively, > > both very easy to do, and very difficult to point out, once > > done. > > If you would use "true local labels" (and with true I mean really > true and not what you call true), then this problem wouldn't > exist at all. I'd have to agree. Local Labels (the way Nasm, Fasm does it anyway) prevents namespace conflicts... so you can easily name local-labels as "a" or "b" and still not have the problems of jumping to the wrong section if you forgot to define a label (as all local labels are unique in Nasm and Fasm) Ex: global: ..loop: jz .loop global2: ..loop: jnz .loop Heck, you can even do: jmp global.loop if ya wanted to. Now something they should do is have local-local labels :) global.local..locallocal :) J/k, can't really find a use for it, but someone probably will find a way to make their code look neater. Maybe for organizing data inside structures? Like for mov or add if you are making an assembler... datatable: ..instructions: ...mov: dd (whatever the opcode is that I'm too lazy to look up) ...add: dd (etc. etc) Well, it wouldn't be like that... it probably be more like... instructions: ..mov: ...rr: dd (insert opcode here for register to register mov) ...mr: dd (register to memory) ...dmr: dd (displacement memory + register) ...drmr: dd (displacement register memory (aka mov data[eax], ebx)) ...dxrrmr: dd (opcode for displacement multiplier register plus register memory to register, aka mov data[4 * eax + ecx], ebx) etc. etc. Meh; probably an easier way :) Just a thought. --Dragontamer |