Re: Betov's crappy notation

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 02/12/05 

Date: Sat, 12 Feb 2005 18:24:13 GMT

hutch wrote:
> > 1) RosAsm Syntax is, like all Actual Assemblers Syntax,
> > base on the NASM GREAT inovations, that had made us
> > free from MASM Syntax MAJOR errors.
>
> NASM syntax is a standard of its own that you don't even come close to
> providing. The value judgement "Actual Assemblers" is just another
> warmed over Betov definition of an assembler that your own disaster
> does not comply with. The only people who complain about industry
> standard MASM preservation of the historical Intel notation are those
> who cannot provide a parser powerful enough to do the same thing.

No, sorry...this might be the case in Rene's case...and perhaps a few
others...but I and the LuxAsm team are going with "NASM-like" syntax
because it is the _BETTER_ syntax style on a lot of criteria...

Oh, indeed...MASM does have "power" inside it...and the greatest _WEAKNESS_
in MASM is that its syntax is so screwed up...and being "historically
accurate" to Intel's syntax? Crap, that's the _WHOLE PROBLEM_...Intel
invented a _CRAP_ syntax that's inherently ambiguous in many cases...that's
NOT a good syntax...

Not that NASM does anything to "cure" these "ambiguous" syntax issues -
"dword" is more concise than "dword ptr" but it's the same construct (a
"change of name" is only syntactical and not semantically different...that
"ptr" doesn't particularly bother me to care whether it is there or not...I
don't really see "dword" or "dword ptr" as that vastly different that it
should really matter..."dword", though, could be argued as preferrable just
because the "ptr" appears a _redundent_ construct here...and though there
is a correlation that verbosity can help with "readability", I don't think
MASM is really doing anything of any significance to "readability" in
insisting on "ptr"...this, to be honest, is a complete "non-issue" for
me...it "saves typing"...but, indeed, "saving typing" on all of, ooh, four
characters is a highly trivial and petty concern...if it does, then why
not? But I don't consider that in any way "life or death" to really care) -
but it does sort out the bizarre "half-HLL half-assembler" confusions...and
that is a _SERIOUS_ problem, I feel...

Indeed, I find it almost ludicrously bizarre that people worry about "ptr"
characters but then completely overlook that there is an inherently
_INCONSISTENT_ syntactical scheme present in MASM...it really is trying to
do _TWO INCOMPATIBLE THINGS AT THE SAME TIME_...that is a _SERIOUS_
syntactical flaw of the first order (a _major_ breach of the syntax "deadly
sins")...

Specifically:

[ If ESI is assumed to contain the address of "MyVar", for the purposes of
example, that the use of variable and register below actually are
equivalent... ]

mov eax, MyVar ; undecorated
mov eax, [ esi ] ; decorated

mov eax, offset MyVar ; decorated
mov eax, esi ; undecorated

The syntax on the register use is _opposite_ to the syntax on the ("HLL
inspired") variable syntax...

Compare to NASM:

mov eax, [ MyVar ] ; decorated
mov eax, [ esi ] ; decorated

mov eax, MyVar ; undecorated
mov eax, esi ; undecorated

It's _CONSISTENT_...also, there is no need to invent "offset" prefixes and
other "keywords" and behaviours to get around the "clashes" that happen in
MASM...specifically:

MASM NASM
mov cl, 0080h -> mov cl, 0080h
mov cl, [ 0080h ] -> mov cl, 0080h
mov cl, ds:[0080h] -> mov cl, [ 0080h ]
ds: mov cl, ds:[0080h] -> mov cl, [ ds:0080h ]

[ Indeed, to make this point, NASM syntax has to be used to avoid ambiguity
because it _DOES_ represent what is actually produced, while you can't use
MASM syntax because what you write is "changed" to "account for the
clashes"... ]

And, regards "readability", Randy's quite right that shorter isn't
necessarily simpler (indeed, it often proves to be the _opposite_ in
practice and verbose syntaxes are found easier to read because the
information is not so "tightly packed" that it is easier to visually
distinguish what's happening...you know, "offset" is such a big keyword
sitting in the middle of everything there, it's hard to miss ;)...the "win"
is still to NASM on this score but it is not, like Rene, being "arbitrarily
concise" but it remaining _CONSISTENT_...which means that interpretation is
"standard" and, thus, this _AIDS_ "readability"...

Note, I agree that Rene's syntax is highly dubious in claiming "Intel
syntax" or "NASM syntax"...I too fail to see the syntactical or semantical
similiarities at all there...

But just because Rene is now praising "NASM syntax" is not excuse enough to
_deny reality_ that NASM's syntax here is clearly better, is consistent and
isn't trying to mix two inherently _incompatible_ syntax styles into one
(and producing very weird behaviour and requiring odd "disambiguation
operators" at the "clash" situations)...

This would be a case of unacceptable "colateral damage"...Rene and RosAsm
are your "enemy"...target _THEM_...and if NASM is "claimed" (falsely) by
Rene, then please just point out the fact that his syntax is NOTHING LIKE
NASM at all...

NASM-ites would point out that NASM's very central and delibrate syntax
criteria was, amongst other things: "All memory references happen inside
square brackets"..._ALL_ references, everywhere, at all times (a
"consistency" measure so the whole point is the _universal applicability_
of that in _all_ situations at _all_ times with no "exceptions" to it
present at all :)...Rene does NOT even use square brackets for memory
references at all (they are used for something else: directives)...hence,
whatever Rene's "justification" for this scheme (it may or may not be
considered valid), it is simply _FALSE_ to claim "NASM syntax" on
RosAsm...that was an _EXPLICITLY STATED_ part of NASM syntax that "all
memory references happen inside square brackets"...if you're not keeping to
that, then you cannot possibly be "NASM syntax" because that's a _CENTRAL_
and _EXPLICITLY DECLARED_ part of the syntax criteria...

MASM's greatest _WEAKNESS_ is its dreadful syntax...however "historically
accurate", it's screwed up...it's "historically accurate" to a time when
people believed the Earth was flat, so to speak...that's the kind of
"historically accurate" we _DON'T_ need anymore...indeed, I find it amazing
in all these syntax discussions that no-one's pointing out the _TRUE
SOURCE_ of all this nonsense...Intel themselves _SCREWED UP_ in defining
the "standard syntax" initially...it has inherent ambiguities to it...as
time has progressed, they've messed around with it in incompatible
ways...added to it "ad-hoc" with no consideration to how things "used to
be"...it has resulted in "Intel syntax" meaning: "Total mess"...

"Intel syntax" is what everyone clings to...but this is the _PROBLEM
ITSELF_..."Intel syntax" doesn't really exist because Intel did NOT do
their job properly in defining a complete syntax, anyway...and what we can
consider "Intel syntax", anyway, is plagued with "disambiguation operators"
in order to "fix" the inherent _CRAP_ that Intel defined as its "syntax" in
the first place...

Amazingly, I've only seen Herbert alone point this out before I
did..."Intel syntax" is the _PROBLEM_, not the "solution"...unfortunately,
though a total "mess" of a syntax - and it really _IS_ in serious ways -
it's also the syntax everyone is "used to" and the syntax that everyone
wants to use...a "familiarity" thing...so, this leaves us with the
impossible situation - thank you very much Intel - that we've got a screwed
up syntax...or, if one made a serious attempt to "fix" it (see Herbert's
assembler or, in a way, GAS syntax), then no-one wants to use it because
it's too radically different (but to _properly_ fix Intel's "mess", then
you've got to make such "radical" changes...go figure ;)...

MASM adheres to the "total mess" standard and, hey, decides to make it
worse ("db" or "byte"? Yeah, so much for having a "normalised form" syntax,
eh? ;)...excellent...that really recommends it...indeed, MASM does have
"power" underneath the hood and can do lots of "tricks" with macros and
such...so, to be honest, in promoting MASM, you'd be wisest to _SHUT UP_
about "syntax" and concentrate on "power" and "features"...syntax is where
MASM seriously falls over more than any other point...concentrate on the
other stuff and "keep quiet" about the dreadful syntax issues it has...they
only dis-recommend the use of MASM...

And don't go taking in NASM as "colateral damage" for your attacks on
Rene...not least because NASM _IS_ seriously better on the syntactical
front than MASM here...you'd be fighting a losing battle to (unnecessarily)
take on NASM on this score...and, not least, it's _NOT NEEDED_, anyway:
Simply, whatever Rene says, his RosAsm syntax is NEITHER "Intel syntax" (in
as far as this phrase means anything...indeed, it should be banned as a
phrase because it offers no useful information at all...there is no such
thing as any "Intel standard" on this - _IF ONLY_ Intel had had the wisdom
to do such a thing! - and this false "appeal to authority" when the
"authority", in fact, is deadly silent and has never given a satisfactory
"syntax standard" by which we could validly claim to be clinging to)...nor
is it "NASM syntax"...

There's no point attacking NASM here...first, NASM - on this point - kicks
MASM's arse...sorry, it does...now, _EVERYTHING ELSE_ MASM can put up a
good fight and with things like "features", MASM can even win...but with
"syntax"? No, you're fighting NASM on its "home ground"...it will kick
MASM's arse on that...you'd be wise not to go anywhere near this in your
"MASM advocacy"...because if the _FACTS_ are produced about MASM syntax and
established "language theory" about "deadly sins" of syntax and so forth,
NASM _WINS_ and MASM fails miserably, as an _AWFUL_ violation of good
syntax...so, really, don't go there...you can only _LOSE_...

But the even greater point is that it would be _POINTLESS_ to attack NASM
because Rene's claim of "RosAsm syntax is NASM syntax" is an utter lie...it
uses the standard Intel mnemonics...but then only GAS doesn't (and even
then, if you consider the ".l" suffix as "not part of the mnemonic" but an
"addition" to it, _EVEN GAS_ doesn't vastly differ either!)...even HLA uses
the "standard" Intel mnemonics...they _ALL_ do (with a few exceptions here
and there...all minor and trivial)...everything else Rene appears to have
invented himself...and, indeed, though I don't agree there's much point
behind his "no redundency" syntax style, he has at least implemented that
idea rather well...you know, it really is "no redundency" as he
intended...as to _WHY_ this is any kind of "good idea", I can't answer you
that...but, fair play, Rene has managed to do what he intended to do...it's
that initial "intention" that is questionable...does saving hitting a keys
here and there really make a good syntax? Personally, I'd unequivocally
contend: NO! Indeed, the opposite is often demonstrated to be the
case...and if he _really_ wants to do that, he should have a go at coding
up my "ideographic assembler" idea...now, _THAT_ would even kick the arse
out of "hex coding"...or, indeed, create yourself a 256 key keyboard (or,
if you have the room, a 65,5536 key keyboards ;) and then you can relate
_every single_ byte (or word) value to a single key...it'll take you
forever to learn how to use this "programming Japanese" effectively, true
enough...but, hey, once you mastered that, learnt all the "encoding tables"
off by heat and such, your "data entry" rates would be absurdly
fast...excellent: You can code your bugs faster than ever! Oh,
oops...you've only just realised that this is chasing "fool's gold"? What's
the point of owning a formula one car when the only place you can drive it
is riddled with "speed bumps" every 5 yards? The true "speed" problem lies
in the human mind and design and such, not in how fast you can tap those
keys...only a _very seriously good_ programmer - perhaps wolfgang qualifies
that this is an important criteria for him - has the _true_ inherent
problem that they can't type fast enough that their brains are racing away
ahead of their fingers...for most programmers, the complete reverse is
true...the thing that slows down programming is not the keyboard but their
own minds...stopping to work out what to do next...re-coding vast sections
(making all that "saves typing" quite a redundent action because it's _ALL_
wasted) because they screwed up their thinking or design initially...

Anyway, RosAsm is NOT "NASM syntax", so there's no need to criticise NASM
syntax...and you'd be rather stupid to do so when NASM can kick MASM's arse
quite clearly and _proveably so_ on this particular score (oh, MASM might
"win" on other scores but don't go near syntax...NASM intended to "fix" the
dreadful MASM syntax issues and it _SUCEEDED_ in doing so)...if you really
want, there are formal, official criteria by which to measure syntaxii
by...a whole "theory" set in this direction...you don't want to put MASM
and NASM in a "head to head" on that point because MASM _WILL_ lose it
badly...concentrate on _other things_, where MASM can "push" itself...macro
capabilities, for example...it's good at that...though, the other big
problem MASM has is that other assemblers were created to "fix" problems in
MASM...hence, they tend to "win" on those issues...for example, HLA was
created to "fix" problems in MASM's macro and "compile time" stuff...and,
on that score, nothing comes close to HLA...NASM intended to "fix" MASM's
dreadful syntax, and, again, on that score, nothing comes close to NASM
(indeed, once NASM did it...all assemblers thereafter are almost
universally copying _NASM_ and shunning MASM because NASM has "revealed the
light at the end of the tunnel" for getting away from such crap)...the real
question I'd have for MASM advocation is: Does it really stand up anymore?
What I mean is, has it now been surpassed? Perhaps not...because all these
"other assemblers" have concentrated on just one or another "issue" with
MASM but not all of them...for example, HLA has the infinitely better
"compile-time language" to any other assembler BUT it still has the
mistaken MASM syntax flaws...NASM "cures" that but it has very little in
the "compile time language" department (the NASM macros are "workable" but
not anywhere on a "par" to, say, HLA which is almost "obsessively absurd"
in that department in comparison)...

MASM _might_ be able to push "jack of all trades, master of none" and that
it has all that "history" stuff in its favour (but, as time passes,
"history" becomes increasingly less important and "other assemblers" build
up their "followings" to challenge "source code examples" and such, as they
go forward)...that might be the best direction to push...you know, the
"it's the original" sell, like Coca-cola...leaving the others to do the
"choice of the new generation" Pepsi sell against it...it's probably
fruitless, though, Coke and Pepsi _STILL_ fight it out after decades of
this crap...

Now, a "NASM syntax" assembler _WITH_ all those "features"? _THAT_ would be
interesting...but, of course, you still don't need to worry because LuxAsm
is going to be for Linux and doesn't "overlap" the MASM Microsoft platforms
at all...so, still "safe"...but surely, if you'll drop the flippancy and be
honest, then you _do_ realise your MASM days are numbered and it's merely a
"matter of time"...but, sure, if this is what you want to use in the
meantime, then it's, of course, none of my business...it's none of anyone's
business, in fact...why do we debate this nonsense, anyway? Oh,
well...protects our "phoney-baloney jobs" ranting on the newsgroup about
things of no significance all day long, I suppose ;)...

Beth :)

Quantcast