From: Betov on
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
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
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
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

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