Re: What do I do with Art Of Assembly?

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 01/18/04 

Date: Sun, 18 Jan 2004 07:09:11 -0000

Betov wrote:
> Beth wrote:
> > [...]
>
> Here we go again with tons of bull*** about HLA
> being an Assembler. Well,... just one thing:
>
> > So, are my two word-sized data declarations aligned to the byte,
word,
> > dword, paragraph or page? Don't know...because they are less than
> > 32-bits, does RosAsm "pad" these out to dword-sizes for
"alignment"
> > reasons? Don't know...
>
> RosAsm syntax is perfectely clear about this:
>
> For Data Declarations, "[" actually means:
>
> 1) Start a new set of Data.
> 2) Aling32.
>
> If "Align32" _not_ wanted, the syntax is: "[<".
>
> Notice that, in some future (when i will have
> time to review this...), the convention will be
> slightly modified to the more accurate:
>
> 1) Start a new set of Data.
> 2) Align on the boudary required by the next
> coming Size Marker. Example:
>
> "[MyqWord: Q$ 0FFFF564]"
>
> >>> Align64 assumed. Instead of the actually hand made:
>
> "[<64 MyqWord: Q$ 0FFFF564]"

Ah, now, see, _THAT_ is a useful answer...you should make more useful
posts like this...with more of this thing _clarified_ ("clearly
defined" ;) then it's more tempting to at least give RosAsm more of a
"look-see" and "play around" to find its good points...

Anyway, the answer isn't totally complete yet, though...my example was
specifically about having these two 16-bit pieces of data straddle
between "titles"...is it _guaranteed_ - not subject to change or
revision - that the order of the tabs for each "title" is the actual
order of processing the source code?

That is, if one "title" ends in "[<16 VarA: W$ 034 ]" and the next
"title" ("next" according to the tab order in the editor :) has "[<16
VarB: W$ 012 ]" then would a "mov eax D$ VarA" instruction (Hope I've
got your syntax correct here...I'm trying but confess I'm not totally
comfortable using it :) be always _guaranteed_ to produce "1234h" in
EAX?

Or, more generally, as that example is slightly "contrived", what are
the rules about the _order_ of "titles" with respect to the source
code and what are the "scope" (if any) and "forward declaration"
rules? My point being, basically, "titles" are all shown _equally_, so
to speak, in the editor...but as it's merely a "visual" thing and the
source code is actually one monolithic file (just _shown_ by the
editor as separate "modules"...or "titles" in RosAsm terms :)...

For example, QuickBASIC also uses a very similar strategy in that the
editor _shows_ each "SUB" and "FUNCTION" in its own separate editor
window...but, in fact, this is merely a "visual aid" and the file is
still one long monolithic file (as can be proved to one's self by
simply loading up the file in another text editor to see that the
"SUBs" are merely listed one after another and it's simply a "visual
aid" from the editor that it reads "SUB" and then splits them all off
into their own editor windows so that you can do things in a more
"modular" way without actually needing more than one file :)...

But, well, ignoring the point that QuickBASIC does _also_ support
multiple file projects too (has a very simple "makefile" that just
lists out all the filenames so that when you load one, all the others
are loaded together with it :)...QB _does_ use "scope" and "modular"
elements to do this...that is, variables outside a "SUB" are NOT
visible _unless_ you include a statement to make them so...hence, the
"rules" about how the different parts relate to each other is made
clear by the documentation...

With RosAsm, though, I'm wondering what the "rules" may be
there...that is, "titles" don't have "scope" applied at all, right?
It's merely an "aid" to editing things but doesn't alter the usual
"it's all just one big monolithic file" thing at all, right?
Therefore, there needs to be a little bit - just a sentence or two -
that explains how these relate to each other...

For example, one "title" - called "One" for example - defines some
data...can another title - called "Two", for example - simply "reach
in" to title "one" and use that data? Also, as I was saying about the
"order" of these "titles" _in the actual file_, does the fact that
"one" comes before "two" in the tab controls along the top of the
editor _literally mean_ that "one" comes before "two" _in the actual
source file_? I'm thinking about things like "forward references" (or
does your assembler make multiple passes or use some other means to
avoid any problems with "forward reference"?) and about possible
requirements for ordering data (as an example, when I was talking
about "type-time" assembly to another post around here, I mentioned a
"hack" in which you could save memory by only using a _single_ address
pointer in some tables, which _could_ either be another table or an
actual _piece of code_...rather than create an extra field in the
table to define what "type" of pointer this is - is it a pointer to
another table so that we've got another "tree" of tables hanging off
this table...or is the pointer actually a "leaf node" in the tree and
there are no more tables and the address now points to an _actual
procedure_ to call - what could be done is to put all the tables
together in memory...and then we can tell if the address pointer in
the table points to another table by simply checking if it's within
the range of tables...that is, if "p" is our pointer then if "address
of start of first table <= p <= address of end of last table" then we
_know_ simply from the location of the pointer whether it's pointing
to another table (where, obviously, if it isn't then it's got to be an
address of _actual code_ to call instead)...hence, we only need one
field - the address pointer - and don't need to make all these tables
far larger and require an extra memory access to this "type" field to
find out whether the pointer points to another table or to an actual
procedure...this is a very simple "optimisation" that can greatly
improve size (saves one third of the size of the larger tables with
two fields, in fact ;) and even improves speed (because we can
determine everything from _one_ memory access rather than needing two
:)...

BUT for such a "trick" to work, we need to be _sure_ of the order of
our data...rather than an address which points to a subroutine at the
"leaf nodes", it could also - in some other application - also point
to more - but different - data elsewhere in the program...thus, the
_order_ and _range_ of how our data is actually placed in memory is
_crucial_ for this trick to work...if more than one title supplies or
accesses our tables in this way, we really _need_ to know whether the
tab order in the editor _truly_ reflects the order in the source file
itself (and, thus, by extension, the order that will be in memory once
loaded :)...

NOTE carefully that there's NO criticism of RosAsm itself in this...it
obviously works in one way or the other and _once you know_ what that
"order" actually is, then you can _safely_ go ahead and use "tricks"
like this one (which you'd probably approve of in the sense that it's
a "specific assembly" kind of "trick"...rather than make the tables
"generic" with "type" fields, we actually borrow _facts_ about how our
program is _specifically_ ordered in memory so as to save on memory
and speed...put it this way, Randy couldn't really advise such a thing
as "good programming structure" in AoA to beginners, anyway, as it's -
I admit - heading towards "dirty hack" and "unsafe" territory...but,
hey, done right, it saves you a bundle in RAM and even speeds things
up a touch ;)...

What the criticism was really about is that you don't really make
enough of these kinds of issues - which _can_ be very important for
"tricks" like the one above - totally _explicit_ in the documentation
and so forth...

Make these "order" (and "scope", even if that's to simply say "there
is NO scope in RosAsm at all" or "it's just local labels only and
nothing else" or whatever :) issues _clear_ and the "problem" here
vanishes...it's a "there's some things I'd really, really like to know
about RosAsm that's _missing_ from its documentation" criticism...put
some small entries about these technical matters - if you can make
room between all the "philosophy" in there - for such issues and the
"complaint" totally and immediately vanishes...you know, it's just the
thing about "if you're not told how it works then you can't _know_ how
it works" problem that applies to anything...

As you know seem intent to "sell" RosAsm (even if by "terrible
illusion", which has got me very annoyed, actually ;), _pay particular
attention_ to what Randy uses more than anything else to "sell" his
HLA: _the PDF files_...now, of course, you use your own help system
rather than the PDF format...that's not important...but what _is_
important and really helps to "sell" HLA is that Randy puts it all in
there...all the little details about how HLA does this and does
that...because, with this, you're "selling" _knowledge_ and _safety_
and _comfort_...that is, I've run into things I wasn't sure about with
HLA but I could feel confident that most of these _ARE_ 100% covered
in one of Randy's PDF files somewhere...that if I just looked around,
there'd be a paragraph saying "it works like this" and then I could
carry on...

When the documentation is more "minimalist" than that, this actually
means you need to pay _MORE_ attention - not less - to being
absolutely sure that you've covered all the technical issues that a
user could be confused about (yes, _even when they are
"unlikely"_...because even "unlikely" things _DO_ happen from time to
time and, when they happen, we _still_ want to be sure that the
documentation at least gives us _some_ sort of a clue how things works
and what to do to get RosAsm to work in the way we want :)...

Indeed, Randy uses _books_ an awful lot to "sell" his HLA...so, _pay
attention_ that just making your documentation "fuller" (not
necessarily "massive" in size but just that it _is_ "covering all
bases" that a user could ever want to know about, be that "likely" or
"unlikely" :) will be a _great_ "selling" point...more "features"
won't necessarily help at all...in fact, _more features_ means more
potential confusion and questions that users want to know about...it
could actually make this kind of problem _worse_, not
better...because, basically, what users _really like_ is knowing that
they are "safe"...that they can be "comfortable" with a tool...that
when they have a problem, they can look at the documentation or ask a
question and get a speedy, useful and honest reply to that almost
immediately..._THAT_ is what "sells" a whole lot better than "jump
optimisations" because, in fact, I'd bet that very few HLA users ever
cared or noticed (after all, this issue is an issue with _MASM_ or
_FASM_ or _GAS_ - which HLA uses - and not with HLA itself...not least
until v2.0 appears...so they can hardly be greatly worried about it or
the "ambiguity" about whether HLA does it or not - as it's NOT an HLA
"feature" at the moment but a feature of the assembler _underneath_
HLA, that it's not on HLA's "feature list" at all - would have put
them off...

I know, you don't feel confident as being a "literary genius" to write
tons and tons of documentation...it's boring, there's coding to be
done...BUT that, in the end, is what needs to be done...how Randy's
"ratings" are going up (he writes the books and happily answers the
newbie questions :) while your "ratings" are struggling...that's where
Randy's "professionalism" comes into the picture...it _can_ be really
boring and tedious (mind you, also sometimes fun and
enlightening...it's not automatically "torture" but, yes, you'd rather
coding instead ;)...but that's the thing you've _got to_ do, if you
want the most users to think "yeah, this is great...I can pick up this
book and can write specific assembly programs for ReactOS within
days!"...that's the "feeling" of "comfort" and "security" and "this
guy Rene's a good friend helping me" which is actually doing all the
"selling"...the "feature list" is actually next to _USELESS_ on
beginners for a _fact_...they don't know assembly yet, they can't even
read it...they don't understand the jargon...what's a "jump
optimisation"? They just don't know...Hopefully, they _WILL_ know all
about that _AFTER_ reading your documentation and tutorials and
stuff...but that is NOT what "sells" the assembler really, it's the
_CONFIDENCE_ that the users can put in it...that is, Randy is a
long-time teacher of this topic...that gives people _confidence_ that
he knows what he's talking about...Randy creates big books...that
gives people _CONFIDENCE_ that when they have a problem, the big books
will probably answer their questions...Randy comes on here and answers
newbies...that gives people _CONFIDENCE_ that even when the big books
fail, they still can get some kind of "support" for their problems...

Don't you get it? If you'll pardon the French, *** "features" for
now...get the _CONFIDENCE_ people can have in RosAsm to 100% or
more...because, in the end, the _ONLY_ real thing people want to know
about a tool before "buying" it is: "Will the tool actually be
_useful_ to me and can I _trust_ it?"...

And, I warn you now, very, very seriously...if you use "terrible
illusions" and add on twenty "features" that users aren't specifically
looking for, then this _WILL_ backfire on you...I'm not just saying
this saddened by you going back on your "principles" but also as a
simple statement of _fact_...if you try to win by "cheating" and
"deceiving" and people _find out_ that you're "cheating and
deceiving", then you will _LOSE_ all your "friends" in the blink of an
eye...the entire house of cards can potentially come crumbling down
all in one go..._DON'T_ overlook my warning here as "some more Beth
bullcrap" because I'd _hate_ to see you ignore this and then find
yourself standing in the _ruins_ of the house you'd tried to build...

In fact, there you have it, Rene...you _could_ build a house and, you
know, not properly build the walls...just put the roof on any old way
and who cares if it lasts more than a year? You _COULD_, indeed,
create a "terrible illusion" that this house is well-built, when, in
fact, it's a total deathtrap that will fall to the ground in a couple
of months or end up electrocuting someone because of bad wiring or the
pipes will all burst and the house is flooded because the plumbing
wasn't done correctly...

DON'T...I repeat, DON'T go and build RosAsm as some "house of cards"
that could blow over with the smallest breeze...so, DON'T try to
"cheat" with "terrible illusions" because I _GUARANTEE_ you 100% that
such illusions are only _TEMPORARY_...if one of these badly built
houses was to fall and kill the people living in it, then _NO-ONE_
would ever consider hiring "the Killer Builder" to build their houses
ever again...

I know you don't credit Randy with this...but the truth of the matter
is that he succeeds because you _CAN_ place a very high degree of
trust in him, his words and the tools he writes...it's actually
_because_, in truth, he doesn't "swindle" at all - even when it's
tempting to...even when, for example, he could have kept quiet about
bugs and problems with HLA and tried to create some "terrible
illusion" that it was working better than it was...even when I've
spotted things and mentioned them in private Email to him so that he
could perfectly well have NOT told anyone of the problems but still
announced it regardless...that's Randy's _real_ selling point - and
even mine to the degree that I'm trusted when I say things - that he
simply _doesn't_ try to "swindle" at all...even when he could easily
do so, even when it's tempting...

Indeed, when you decided to pick on Randy's "trustworthiness" with
"lies, swindles and propoganda", you _WERE_ attacking exactly the
right thing to do damage...although, of course, _you_ are the one
who's really lying, swindling and creating propoganda to do
that...but, nevertheless, that _is_ Randy's main "selling point" that
going after that was perhaps the smartest "anti-HLA" thing you ever
did...creating "terrible illusion" features has the potential to be
the _dumbest_ thing you could ever do...I'm not just warning against
this because I'd be highly disappointed to see _illusions_ (another
word for "lies, swindles and propoganda", after all) used to _deceive_
people...but also I have to say this because it's quite possible that
the same "terrible illusion" will backfire on you in a really serious
way...

Just hearing you say "terrible illusions" made me lose 99% of the
respect I'd built up for your "principled stand"...and I always try to
"give the benefit of the doubt" to people...most people out there
_DON'T_ and would immediately cease to have any and all respect for
you right then and there, refusing to ever listen to the "swindler"
ever again...

"There is nothing so powerful as truth, and often nothing so strange."
[ Daniel Webster (pardon the pun on the surname, Rene ;) ]

"Speaking the Truth in times of universal deceit is a _revolutionary_
act."
[ George Orwell (well, what else could I quote to the "revolutioneer"
Rene? ;) ]

Beth :)