Re: Betov's notation

From: Frank Kotler (fbkotler_at_comcast.net)
Date: 02/13/05 

Date: Sat, 12 Feb 2005 18:32:55 -0500
To: "luxasm-devel@lists.sourceforge.net"  <luxasm-devel@lists.sourceforge.net>

Betov wrote:

> The way you paste the post, with a new Thread Title,
> could make readers think, that i called _you_ an ass-
> hole. :)) :)) :))

Sorry for the confusion. No, you still seem to hold *some*
hope for me... I fear that it's fading... oh, well...

> In case some guys would be horrified... No, of course,
> my post was addressing a real ass-hole, in its first
> part... :)) :)) :))

As you like :)

> I will not much argue on this point. Simply, to me, a Case
> Sensitive Tool is utterly unusable, and to me, "Case Sensitive",
> exactely means "impossible to use cases >>> Set all lower Case,
> and forget one half of the Char Set definitively",

That isn't what I intended by "case sensitive". If we were
going to do that, why not all upper case, like old BASIC :)

> what i
> don't want to do, because i need to build...
>
> ... "TalkingNamesThatAreReadable".

Agreed.

But... is "tAlkingnAmestHataRerEadable" the same thing, or a
different symbol? That's what I mean by "case sensitive". I
feel that it looks different, so it should be treated as
different. Perhaps to someone else, it looks "the same
except for case", and should be treated as the same symbol.
I stick by my preferences...

I actually prefer "talking_names_that_are_readable"... Many
people feel that underscores are worse than CamelCaps, but
to me, it's "more readable". As I understand the way that
RosAsm treats underscores, this would be the same symbol as
your original, right? This could be seen as an advantage,
I'll admit, but I still think if it "looks different", it
should be treated as a different symbol.

I like the idea of ignoring underscores in numbers, BTW, but
I don't think they should be ignored everywhere - "foo_bar"
and "foobar" should be different.

> The fact is that, in RosAsm Syntax, we do not need to make
> any difference, because there is a clear difference between
> what is Code and what is Data, and do not even need any
> '.Code' / '.Data'. So, at the time we are writing Code or
> Data, the D§, W§, B§,... T§ thingies are really in all
> cases, nothing but Sizes Markers.

That might apply to RosAsm... if in fact you can't put data
in a code section. I think I recall you (or Wannabee)
explaining that you *can* if you want to. "db 42" emits data
- whether it occurs in a data section or a code section,
"inc byte [eax]" doesn't - the "byte" modifies data (the
opcode), but doesn't emit anything on its own.

> Therefore the unification, simplification, and encrease
> of consistency.

I'll give you those. It's the "but no simpler" part that
worries me. As far as I can see, the meaning is "always"
clear from the context, so it doesn't do any harm to call
'em the same name. It's just that I'm not absolutely certain
about "always"...

...
> > lodbs
> > stobs
...
> :)) You just give the reason why an Assembler should NEVER
> allow Labels without Colon... and you conclude that you do
> not see why you should do it.
>
> As you like... :(

Actually, I think I'm going to have an uphill battle with
this one... :(

[out of order] you say about requiring commas to separate
operands...

> >> There is no reason to force the user to write commas
> >> everywhere for this unique case of negative Number.

That's much the same reasoning I'd apply to colons on labels
- why require 'em everywhere, just to cover the few cases
where it's a problem?

...
> So, you will understand that i am not going to fight
> to death ;) ... for convincing you... ;)

I don't have much hope for either of us convincing the other
of much. If we can understand each other's position a little
better... make sure we're talking about the same thing...
that's enough.

...
> >> Comma is used as a line-continuation
> >> Marker,

This is an interesting idea!

> >> and can also be used as an Instructions Members
> >> Separator.

I wouldn't want to use an assembler that wouldn't tolerate
commas between operands - I personally find code much "more
readable" with 'em than without - but I don't see any harm
in making them optional.

...
> Yes. The Colon should evidently be REQUIRED. In a Tool
> Syntax Design, you must have some coherency for each
> detail. In RosAsm Syntax, ":" means "This is a Label".

Okay. That's not Nasm syntax, maybe it's LuxAsm syntax...
I'm hoping not...

> No matter if Code or Data. A Label is a Label.

No argument on this point. But is it the ":" that makes it a
label?

> Having such a clear and simple definition allows, for
> example things like:
>
> [Data1: 'abcd', 0, PointerToData1: Data1]

Okay, if you wanna... That seems fairly "unreadable" to
me... I prefer:

Data1 db 'abcd'
PointerToData dd Data1

> A Label is a Label. A Size Marker is a Size Marker.

Except when a "size marker" is a "data emitter"...

> Be it in Code or in Data, be it a Declaration or an
> evocation, does not make them different on the points
> the syntaxic components are supposed to mean.
>
> They are not the same thing to you, because you make
> a wrong representation of them in your mind. The fact
> that the _ARE_ the exact same thing in RosAsm Syntax,
> and that RosAsm perfectly works, at this point of view
> should be enough to convince you that you have a wrong
> representation.

That's not the way I see it. The reason RosAsm works isn't
that they're the same thing, but that the context makes it
clear which of the two different things you mean.

> You seem to be in the opinion that the words i use are
> just because i do not know of the proper words. Well,
> when i say "Size Marker", i mean "Size Marker". In no
> case "Let us Declare a Data Byte".

Unless the "Size Marker" occurs in a data section...

> >> In a similar view, not using, in LuxAsm,
> >> the '&' leading Char for the OS Equates, would be, as well, a
> >> decision error.
> >
> > I see no reason to insist on some obscure punctuation for an
> > OS equate (or any other kind of equate)!
>
> As you like. But, if i was writing LuxAsm, i would do
> the exact same thing, for the Linux Equates, as i have
> done for the Win32 Equates, for several valid reasons,
> of speed, of making the maintainance easy, of encreasing
> the readability, ...

You may have something with "speed". I don't think I agree
with "maintainance", and I *know* I don't agree on
"readability"! ("Why is he taking the address of
"WXYZ_SOMELONGNAMEFORASMALLINTEGER?")

...
> > es mov ax, [di]
>
> ... Where "es" would be a... Label? :)) :)) :))

No, where es is a prefix. Placed in the source code where it
will appear in the machine code.

> > "[es:di}" is fine with me - but it's something to think
> > about.
>
> Modifying this would be a major error decision. NASM Syntax
> is PERFECT, here, and is really see no reason why you should
> change this...

Well, I'm not really arguing to change it, but the "es" (or
other prefix), *does* come first in the machine code, even
if we consider it "part of the effective address" (which it
is).

Okay, you convinced me. We'll leave that part alone. :)

Best,
Frank

Relevant Pages

  • Re: why this assembly language is not good?
    ... When did this thread become a debate about RosAsm's readability? ... So you would force someone to have a shining example of perfect syntax, ... RosAsm, of course. ... RosAsm is no more readable that this new language. ...
    (alt.lang.asm)
  • Re: why this assembly language is not good?
    ... When did this thread become a debate about RosAsm's readability? ... When Rene started making ridiculous comments that apply equally well to ... trying to shift the focus from the OP's language to RosAsm. ... syntactical hint that differentiates them from normal label syntax. ...
    (alt.lang.asm)
  • Re: The Advantage of Macros
    ... pseudo-HLL constructs by the majority of RosAsm programmers? ... but this has no relationship with the language syntax. ... to objectively measure readability of various syntaxes, ...
    (alt.lang.asm)
  • Re: RosAsm is easier to read than HLL code
    ... > will happen with RosAsm because HLL programmers will ... Is the resulting syntax more readable ... > HLL code? ... complicated subject of 'readability', i will ...
    (alt.lang.asm)
  • Re: delegate confusion
    ... Any particular reason you prefer the "CallMeBack.Invoke" syntax ... It's perhaps preferable from a readability point of view, ... compiled code is the same. ...
    (microsoft.public.dotnet.languages.csharp)