Re: My view on this "Is blah an assembler"

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 08/15/04 

Date: Sun, 15 Aug 2004 21:44:22 GMT

The_Sage wrote:
> HLA is Randall's attempt to redefine source language and assembly
language to
> his personal liking (read: ego), in an attempt to make assembly language
> programming easier. I consider HLA a failure in this regards as it makes
> assembly even more cryptic and un-necessarily verboose. If I were going
to
> redefine assembly language, I would use a format like "add eax to ebx" or
"the
> contents of ebx is an address; goto that address and move one word of it
to eax"
> instead of "mov((type str.strRec[ebx]).length, eax);". One is plainly
readable,
> the other is not (at least not without significant training).

So, basically, you're saying your version of HLA would be to turn assembly
language into COBOL? Well, thank goodness Randy did it rather than you,
then...one COBOL in this world is more than enough ;)...

Amusing, really...does anyone here except for Randy and a few others
actually comprehend the _difference_ between "syntax" and "semantics" at
all? Somehow, if Randy had modelled it after a COBOL-like syntax then it
would be "okay" but modelling it after a Pascal-like syntax is "nothing but
ego!"...in neither instance, though, is the _semantics_ any different, mind
you...but as it seems most people can't tell the difference between the
two, then the irrelevency is completely lost...

But, for the record, all the mnemonics are the _same_...except for a minor
exception in "intmul", which Randy explained to _hex coder_ wolfgang (if
anyone's going to be picky, it's him :) and he accepted made perfect sense
to _avoid_ confusions (not create any)...in the vast majority of cases, the
following _WILL_ work (as I often do it and it rarely fails): stick the
operands inside brackets, reverse the order to "source, dest" rather than
"dest, source" and then stick a semi-colon after it...there, hardly brain
surgery or rocket science...as for the type casting then, yes, that _is_
the biggest, ugliest part of HLA syntax...but then it's easy to pick on
this as the only example to imply that all of HLA is like that, when it's
the _exception_, not the rule...and, also, it's the "ugly" bit of _all_
syntaxes to have to put "dword ptr" or whatever...type casting itself is
the ugly thing and HLA is merely picking up the ugliness of type casting
and it's not particular or unique to HLA...

C / C++ uses the data type, typically in brackets to make it clear and get
the precedence right, for its type casting ("(char *)" ;)...MASM and TASM
use the ugly "dword ptr"...even the "cleaner syntax" of NASM or RosAsm
actually is the nastiest part of an otherwise - to be fair - quite nice and
clear and consistent syntax: "dword" or "D$"...indeed, you quote this part
as an example failing of HLA but, if we actually consider things, then NASM
and RosAsm require _explicit_ type declaration each and every single
type...you _must_ "type cast" in all relevent instances (where it cannot be
deduced from the rest of the instruction) because it retains no data type
information...hence, we have a "trade off" in that NASM or RosAsm have a
shorter, cleaner version BUT that you've got to use it more often ("D$" is
typically littered all over RosAsm code...a "(type dword)" in HLA is
actually rarer because it's only needed when you're changing data types or
it really cannot be deduced by any other means)...

You're actually criticising "type casting"...legitimately because it _is_
an often horrid thing to have to include in a syntax...HLA merely, like
every other assembly language, picks up the nastiness of this...it's not at
all unique to HLA...other assemblers start to look horrid when you start to
get into "mov [ stringstr ptr ebx ].memberA, byte ptr 34" style of syntax
too...

But, to be fair to Randy, HLA includes mnemonic variants like "pushd" which
naturally include the "(type dword)" automatically by specifying the
doubleword nature in the mnemonic rather than the operands...though, on
this score, Randy, could "NULL" evaluate to just zero and not "offset32
0"...that is, "pushd (0);" usefully stores the zero as only a _byte_ in the
instruction stream...but "pushd (NULL);" unhelpfully stores a complete
doubleword for the zero (at least via MASM it does) because that "offset32"
forces it to be a dword in size...for readability, I like to use "NULL" in
instances other than just addresses to generally mean "none / not
applicable / void / empty" and so forth...you know, an argument where
there's a number of "flags" but I don't want any of them becomes a "NULL"
situation, not just a zero situation...it's only three bytes, of
course...but it would be nice to get them back as it's only a case of how
"NULL" is defined that's causing it...leave out its "size" completely that
it defaults to the smallest that makes sense rather than always being a
doubleword...the concept of "NULL" is abstract, anyway...it really
shouldn't have a "size"...the "offset32" is conceptually not quite right,
as it's not only addresses to which "NULL" applies, as much Win32 and C
code out there shows where "NULL" is often used to represent "not
applicable" to _non-address_ integer arguments too...

This problem is inherent in _Intel syntax_ itself...that is, indeed, why
Herbert's Motorola-inspired syntax - as "unconventional" as it is - handles
this situation well...similar to AT&T syntax, the "size" is part of the
opcode and eradicates many of the situations where "Intel syntax" insists
on applying a "type cast"...interestingly, also, Herbert's syntax always
the ".b" / ".w" / ".l" suffixes on constants too...

I'm not sure that C (the person, not the language) picked up my suggestion
of this for LuxAsm syntax or not...but I was thinking that we see lots of
assemblers use things like the following: "stos operand" versus "stosb",
"stosw", "stosd"...or "push dword" versus "pushd"...or, of course, somewhat
univeral is "jmp" (tool to decide size with "jump optimisation"), "jmp
near", "jmp far" (explicit sizes, used regardless of "jump optimisation"),
etc...

So, one simple possibility is that of extending this scheme to _all_
mnemonics to help with this inherent problem in the "Intel syntax"
itself...hence, "mov" gets its size from the operands as normal...but
there's "movb", "movw", "movd"..."addb", "addw", "addd"..."cmpb", "cmpw",
"cmpd"..."pushb", "pushw", "pushd"...and so on and so forth, where
applicable...where you can explicitly state the operand sizes in the
mnemonic itself...these forms, though, are _in addition_ to the normal
suffix-less versions, of course...and, on some instructions, this serves a
dual purpose...because with "jmp", for example, if you explicitly state the
size then it's used as stated...but if you just use "jmp" then you're
leaving off the jump size and this says to the assembler "please choose the
most appropriate size" (i.e. "please use jump optimisation on this jump"
:)...hence, also, "push 0" would, again, mean "please use the most
appropriate size" (that is, a byte for anything that fits into a byte
:)...but "pushd 0" says "always use a doubleword regardless of whether it
could be smaller"...

If you like, AT&T / Motorola style suffixes but in the already accepted
("lods", "lodsb", "lodsd", etc. ;) Intel syntax style...added to any and
all instructions where such forms make sense...well, as always, this is a
"cosmetic" issue so opinions will undoubtedly vary...but I think that
simply having mnemonical forms with "b", "w" and "d" suffixes (already in
use elsewhere on the string instructions, for example...and "pushd" isn't
an uncommon addition on many assemblers :) begins to cure the problem using
only one extra character that's less ugly than "dword ptr" or "dword" or
"D$" or "(type dword)" or whatever...but it is an already accepted
convention on some of the other instructions that it's only extending that
idea over the whole instruction set, where applicable...and the older forms
with a "dword" type cast or something can be kept, anyway...

There is the problem of a doubleword instruction carrying a byte-sized
immediate constant...this is where Herbert's syntax wins out (note that
Herbert's syntax really is only an extra "." character more than what I'm
saying...but it's that "." which allows it to be useful with constants as
well as operands because it delimits the constant from the size
specifier)...sticking "b" and "d" after constants, of course, has a
confusion with a convention for doing this to mean "binary" and "decimal"
number bases...and, of course, "b" and "d" are also valid hex
constants...this has to be discussed further for a simple, obvious yet
_unambiguous_ way to tackle it...

I think C worked out a ":2" / ":4" convention or something...nice - perfect
for the "constant" issue - but it's a bit "non-standard" and
"non-Intel-syntax"...putting "b", "w" and "d" as a suffix on the mnemonic
is a scheme already being used for other instructions in the "Intel" style
already...extending that to, basically, the rest of the instruction set
(except for those instructions where such a thing doesn't make
sense...wouldn't need it for "movq", for example ;)...

Indeed, this convention is used throughout the Intel instruction set
already ("cwd", "movq", "movsb", etc. ;) but, for some odd reason, is not
applied universally to all the instructions...but seems to me like the
logical thing to do, if we're already seeing "pushd" and stuff added for
convenience...well, be consistent and add it for all of the instructions
where it makes sense to be added (which is most of the "core"
instructions)...also, do we need "jmp short", "jmp near", "jmp far" when
it's kind of more "Intel-y" to have "jmps", "jmpn", "jmpf"? Plus, of
course, good old "jmp" without suffix is used when you want the assembler
to do "jump optimisation" and pick the best it can find...hence, if you're
the sort who likes to always specify the jump size and do it all "manually"
then, ummm, carry on and do that...the "jmps", "jmpn" and "jmpf" are fully
respected and left alone, just as you asked...as you'd want to be explicit
about the size on each jump, anyway, then putting it in each time is what
you'd be doing, anyway...so you get just what you want...but there's the
option not to be explicit about the jump size with "jmp" (or "jxx" or
whatever..."jc", "jcs", "jcn", "jcf", "jnc", "jncs", "jncn", etc. ;) and
then the assembler deals with it...best of both worlds...

All the normal mnemonics are as they were before but - in exactly the same
way that "movsb", "movsw", "movsd", etc. or even "cwd" or "movq", if you
think about it, already do - there are "b"(yte), "w"(ord) and "d"(word)
suffixes (and, for jumps and calls, "s"(hort) , "n"(ear) and
"f"(ar)...plus, "q"(uad) has already been defined in other Intel mnemonics
so that can be used if needed too ;) for all the mnemonics to allow the
size to be explicitly stated...so, stuff like "addb [eax], 35" or "imulb 5"
or "imulw 5" or "stosb" or "pushd 0" all can go ahead without any need for
"type casting"...the ":2" notation could be used to force sizes onto
operands, if needed (but using the suffix scheme, then the need for this is
reduced to a few rare cases, like "addd [eax], 35:2"...which still looks a
lot, lot cleaner - while not deviating from what is usual in "Intel syntax"
too much - than most equivalents :)...

Oh, note, C, Frank, that one thing to consider about LuxAsm and "data
typing" is that if we do have it (which C appears to want a loose scheme of
and I'd be completely behind that idea :)...then with the "fine-grained
syntax highlighting" that I was talking about before, it would be possible
to remedy one of the main complaints people have about "data typing" with
the editor rather than the language...it could show byte, word and dword
variables in different colours for syntax highlighting? Then you could tell
the "type" at a glance...plus, with a "hover" / "right-click" feature (I'd
prefer to keep to typical "user interface conventions" that have developed
over the years, that you hover the mouse for a "tooltip" window to appear
which tells you the definition - you don't have to "jump" in the text if
you only want to see that "NULL" is zero - and that "right-click" _opens a
menu_, where "jump to..." (as well as "back", "forward"...plus, "cut",
"copy", "paste" because there's not only jumping that you might want to do
to text...consider the typical browser right-click menu :)...yes, this
won't be as fast as RosAsm...but I think an extra click in order to grant a
lot more options available via "right-click" and the very important point
that it is "familiar" to how browser right-click menus already are seems
more useful to the user than obsessing over, ooh, one extra click...OR, of
course, you can go with the older style of "context menu" in that you press
the right button and the menu appears and then move to the option and leave
go...that's only one click, just a "long click" with a bit of moving in
it...the thing to remember there is that of accidentally leaving go of the
button unintentionally...but one "trick" here I was thinking about is that
every "context menu" could carry a "title" (so, indeed, if clicking on
"NULL" then this appears as the "title" with, perhaps: "NULL: 0" to handle
what would appear with the "hover", anyway :)...and this "title" isn't a
selectable option on the menu, it's just the "title" like "File" is for
drop-down menus on a menubar...so this "identifies" the menu but is also
what's automatically under the mouse when you right-click...then the "hold
down and move to the option" long right click could be used and the "title"
prevents unintentional "oops, slipped with the mouse" stuff from
happening...Microsoft - over on Windows - chose a different method in that
a menu doesn't even appear until you _let go_ of the right button and,
thus, must require at least two clicks...we're not Windows so we don't have
to follow that at all...just - a bit like KDE does - "steal" the best ideas
and leave behind what we don't like in "user interface" terms :)...

Then, with that kind of thing as part of the editor (and, even, say, a
"navigation" panel with the names of procedures and variables in a
hierarchy at the side of the window...something seen in some dedicated
editors for BASIC, I've noticed...that can be used for "quick jump" and
could detail the "basics" of the various things: what "equates" equate to,
the sizes of variables, etc. :), then the editor would provide high levels
of user support, which is what I'm aiming for...

Anyway, enough of that LuxAsm stuff - just a passing thought I'd mention
while I was thinking about it - the basic point here is that with "(type
dword)" in HLA, you're picking on _type casting_ - a problem in _ALL_
assemblers that follow "Intel syntax"...because despite the "holy" sacred
view taken of "Intel syntax", it's inadequately designed, in fact...that's
why pretty much every assembler has its own "variants" added to try to _get
around_ the inherent flaws in the syntax...Herbert's on the money with
"Motorola style" from the perspective that Motorola clearly thought about
these issues in their syntax and that's why they had the ".b", ".w", ".l"
suffixes already (and AT&T must have also thought it was a good idea
because their syntax uses the exact same convention ;) - and then trying to
attribute this as a "HLA problem", when, no, sorry, it's a "Intel chose
crap mnemonics" problem...indeed, Intel's mnemonics themselves make any
notion of a "1:1" assembler dead because the mnemonics have not been
defined "1:1"...so no "Intel syntax" assembler (and HLA counts into this in
this instance because it still is using Intel _MNEMONICS_, even if
everything else has been changed away from "Intel syntax" elsewhere ;) can
ever avoid "type casting" nor declare itself "1:1"...

Because the problem with "manufacturer worship" - "it's Intel's, so what
they say goes!" - is the presumption that Intel themselves actually chose a
good, clever scheme to begin with...newsflash: they _didn't_...worse, what
is even meant by "Intel syntax" is entirely open to question - how many
claim "Intel syntax" but only the mnemonical style is "Intel", everything
else is arbitrarily made up for each and every assembler? - because,
simply, they don't really define anything beyond the standard mnemonics
(which are inherently flawed, lacking sizes), the use of square brackets
for memory references (well, I assume they did this at some point...fail to
actually see it in the Intel manuals, mind you...but everyone does it -
except for Rene in RosAsm - that it's kind of become part of what's
normally meant by "Intel syntax" ;) and the operand order...

HLA adds in those brackets - which really seem to enflame a lot of people -
and the semi-colon to end statements (the useful point of which many seem
to miss: white space is unimportant, punctuation delimits the whole
thing...hence, you can write your code and never once hit the space bar
;)...this also permits the "instruction composition" stuff in HLA to put
instructions inside instructions (e.g. "mov (eax, mov(ebx, ecx));"
:)...this idea I personally think's a bit crap...a nice idea but never
actually used in practice...and if it was used often, it would lead to
quite unreadable code...

If I was developing HLA then I'd have already declared that part of the
"prototype" to be "not quite as good an idea as I'd originally envisaged"
and probably would, indeed, have dumped it straight back out (this would
cause a "major incompatibility" with old source code, by the way...but it's
a "prototype" so I'd do it and just take the flak...once "concrete",
though, it wouldn't change...but the point of the "prototype" method is to
_experiment_ a little and constraining every "experiment" to be stuck as
part of the syntax whether it works or not renders the notion of
"prototyping" redundent, anyway...there's a big "DISCLAIMER" on the manual:
read it and weep ;)...and, indeed, the machine instructions could have the
brackets removed which would make them clearly separate from the standard
library functions visually...not that most people would care, as they'd
burn it to the ground whatever it looked like because it's not their
favourite assembler or syntax...

But, one thing, Sage, that I'm going to praise rather than
criticise...though you were using it dubiously (taking the "worst case" and
then pretending this is "normal" for HLA ;), to have produced that
"mov((type str.strRec[ebx]).length, eax);" example, it appears you've
actually bothered to _look_ at HLA before making your comments...this is so
rare from most HLA critics that I'm actually going to note this difference
and pour praise upon it...you actually bothered to _read_ before
criticising...hence, I will take your opinion _seriously_ because though I
disagree with it, you've demonstrated you've come to that opinion
_honestly_ and _intelligently_ (the part about "COBOL" at the start is
merely humour...I can't let a joke about COBOL pass without comment, I'm
sure you understand...hehehe ;)...

And, yes, the "clumsiness" of "mov((type str.strRec[ebx]).length, eax);" is
not something I'd necessarily disagree with at all, in fact...that _is_
"ugly"...BUT, I'd only point out that this is hardly unique to HLA...the
actual problem here is "type casting" and HLA just has an overly verbose
syntax for that (no disagreement on that point)...but if you consider the
equivalents under other assemblers, this is also the part where they get
"ugly" too...indeed, drop the brackets, change "type" to "ptr" and then
swap all the operands around and you do end up with MASM / TASM's version
of the same thing...and one point to note is that only HLA / MASM / TASM
actually permit such a statement, anyway...it's using "structure support"
and many assemblers do not have such support...hence, a triply unfair
comparison: Blaming "type casting" on HLA as if it's the only assembler
with this actually _inherent_ problem from inadequate "Intel syntax" in the
first place, choosing a piece of functionality that most other assemblers
don't even support (and those that do - MASM and TASM - are only marginally
shorter and still just as "ugly" as HLA's version ;) and trying to
"misrepresent" such a statement as if it's the "norm" for HLA when it's
actually a "rarity"...the use of "data typing" - often criticised -
actually helps reduce the need for such things in most cases...and you
could always take the "offset constants" approach to structures and ignore
the HLA built-in support for this stuff, if you insisted...because the
"winner" always for HLA is that it usually _offers_ the "HLLisms" but does
not enforce that they are always used...

But, fair dues, Sage...at least you _looked_ before complaining and that
your comment _IS_ a _valid_ complaint, for once, where most cited against
HLA are often imaginary or fictious complaints about something they think
HLA should be but not what it actually is...I disagree with you but you get
the gold star badge - ten out of ten - for actually having a _valid_
complaint against HLA...this is typically so rare as to qualify for praise
and recognition of that achievement...

Beth :)