Review of Art of Assembly Language
Randall Hyde
The Half A Wanna Bee
"Randall Hyde" <rand...@earthlink.net> wrote in message
news:1u1lb.4310$np1....@newsread3.news.pas.earthlink.net...
Cool (). Good () for () you() (.) But() comparing() to() Delphi() (?) I()
can() tell() you() right() now() that() its() not() even() in() the()
neighboorhood() (.) Someday() when() I() am() not() so() tired(), I()'ll()
show() you() Delphi() or() Basm() code() that() will() make() your() nose()
bleed() :-)
You() shitless() Jedi() you(!)
From one of those who didnt make it.
Soon Randall you're going to be an institution. Everyone will flock at you
feet, craving for a litle bit of PDF attention. They will write about you in
every newspaper in the country. There will be TV shows and some day you end
up on Larry King and Tonight show. They will write books about you and you
will finally end up in a history book as well. Along with a picture of you
sitting beside your PC, they will place a zoomed in picture of the code
you're writing on. At that time they will have given it a name, and the name
will be StandardPut(), or maybe StandOutPut(), or perhaps
OutstandingOutPut() :
for( mov( 0, ebx ); ebx < 2; inc( ebx )) do
mov( ebx, eax );
dec( al );
neg( al );
sbb( eax, eax );
inc( eax );
stdout.put( eax, nl );
endfor;
Everyone, even people who never could see a glimse of hope in a line of true
ASM will finally realize how simple and intuitive it really is, when
StandardPut like this. They will be instantly enlightened and within weeks
they'll be able to write OS extentions and even whole OS from just
implementing the examples of you book. No hard work anymore, HLA makes
assembler programming that easy !!! Its true :-)
Just messing a little. Have a nice day.
Beth
Okay, you know me...I just got to bitch about something (but, no, in
truth, I'm merely pointing out errors and interesting tid-bits, so
that they don't mislead or happen again or just for education and
entertainment...it's not really as "bitchy" as it may first appear
;)...
So here goes, first with a technical point:
"HLA provides another interesting aspect in that all code can readily
be compiled for both Windows and Linux with little or no porting
required. This provides a pleasant experience, especially since most
HLA tutorials are directed only towards 16-bit MS-DOS applications."
Oops, Randy, someone's gotten the wrong end of the stick from the
console output...though it's a common enough mistake to make because
visually there is practically nothing to distinguish an MS-DOS program
running in a DOS box from a _Win32 application_ (which is really what
HLA outputs) that just "borrows" the "console" style of output that
the DOS box uses too...they _look_ the same but the internals are
_completely different_, it must be stressed for anyone who's liable to
make the same basic mistake as this reviewer did...HLA is _strictly_ a
32-bit assembler with no specific support for 16-bit coding...it's
quite the opposite...as those who visit here regularly know, Randy's
firmly of the opinion that "DOS is dead!" (often, perhaps, too firmly
of that opinion at times that it annoys a lot of people ;)...
Also, being an "ASM geek", I do find lines like the following slightly
objectionable: "Just the thought of assembly language programming can
send even the most hardcore of programmers into convulsions"...it's
not the essence of what they mean - it's quite right, in a certain
sense - it's the whole attitude that really, really has soaked up into
people's brains over decades...
This "bad attitude" automatically displayed towards ASM that dogs it,
is the real "enemy" here and always has been...it's been an initiation
ritual for many over decades now...you know, the old "nudge, nudge,
wink, wink" as one programmer pours scorn and mockery over assembly
that the other programmer accepts with a "nudge, nudge, wink, wink" in
return ("you're not seriously going to use that voodoo black magic,
are you?" / *suddenly realising that they are committing "blasphemy"
in the eyes of their peers* "no...no, of course not...I
was...ummm...looking at it simply to have some fun laughing and, ummm,
mocking it...yeah...that's what I was doing...honest...ASM is, umm,
like, crap and all that...just like you said and I have no opinions
that differ from yours in any way whatsoever...right?"...that last
"right?" being said in a Hopeful "I've said the right thing now to be
part of the 'gang', haven't I?" kind of way ;)...and, nope, neither of
them actually know what it really is that they're insulting - just
everyone else was doing it, so they followed suit - but it's always
good to be "one of the gang", right?
For example, in this very same review, we find the first paragraph
_ONLY_ giving examples of how assembly looks complicated and then
follows with "However one looks at the situation"...Freud would likely
look at this as a Freudian slip, betraying the true thoughts of the
writer...if it were delibrately done - the rest of the review suggests
clearly otherwise, though - then this is the sort of mild
brain-washing tactics that P.T. Branum made famous (although, despite
not being intentional, it can still "pollute" people's thoughts with
misleading misunderstanding)...
For instance, "some see assembly as impossible, others see assembly as
impossible while others still see assembly as being impossible...but,
however you choose to see it, blah-blah-blah"...well, ummm, you're not
giving us any real options in the way you've written that, have you?
You _want_ us to also see assembly as being impossible...in fact,
you're almost _refusing_ to let someone see it as anything but
"impossible"...you dare not even mention a different possibility where
someone might not find it "impossible"...
In the case of this particular review, I think it's more a case of
_the reviewer_ being slightly brain-washed to this whole "nudge,
nudge, wink, wink" bad attitude to ASM...and what we're seeing there
is that attitude poking through in the text of the review...
Which is the essential essence of all kinds of "prejudice"...it breeds
like wildfire...no, faster than wildfire...one person says something
about a subject no-one much knows about and everyone else simply takes
what they say without thinking....but, in a sense, it's easily done,
even by sensible and "innocent" people because, well, if there's only
one real "source" of your information, that's all you've got to go
with...you either accept it or choose to have no information or
opinion at all (and social interaction implicitly "forbids" people to
be without opinions..."so what do you think?" / "I think nothing" /
"oh, come on, you've _got to_ have an opinion" / "No, I am reserving
my judgement until I have all the facts" / "oh, you're no bloody fun
to talk to...come on, give us the gossip!" / "To do so would be
factually inaccurate and potentially illogical" / "yeah, whatever,
Mr.No-fun-computer-brain...see you later, dweeb!" ;)...
When black skin wasn't a common sight, that's certainly very much how
much racism spread...one person says "jungle people" or something and
then everyone's copying it like a Xerox machine because their own
experiences aren't telling them that this is just vile
prejudice...they've never met anyone like that so they sort of "trust"
the person who claims that they have and calls them "jungle people",
doing the same thing...the second they properly meet their fellow
human beings, mind you - and I mean "meet" in a proper sense of living
and working and intergrating, not just shaking hands at a party -
practically no-one can continue these prejudiced thoughts - not even
the stubbornest person - because, truth be told, it was all bullcrap
from the beginning...you simply CAN'T dispute reality when it smacks
you in the face, it's just NOT possible, by definition...the loud
mouthed "peer" who invented this crap actually had no more experience
of different cultures or people or anything than anyone else but just
liked to "look hard" pretending so...
The parallel with the "let's all automatically laugh at ASM" prejudice
is, obviously, not in the same league because, heck, it's only a
programming language while the other kind is actually the treatment of
fellow human beings and even the unfortunate cause of many a war or
two...but the essential nature of "prejudice" is right there and
exactly the same...when someone doesn't "know" or "understand" then,
quite naturally, we have to trust the opinions of the supposed
"expert" who claims that they do (whether they actually do know
anything...or, perhaps, they have simply met _one_ horrible individual
and this bad experience is being presumed to be true about everyone of
that culture / people / nationality / etc.)...all prejudice is
actually absolutely identical in its methods and the nature of its
consequences (almost always bad in some way because it's basically
_operating without the true facts at your disposal_)...
Which, actually, is useful and handy in combatting it...Randy has
demonstrated how to an extent with HLA...it just _does_...it just
_shows_...it just _is_...and by its _example_ that, yup, ASM code can
be "portable" if it's just written the right way...by its _example_
that, yup, ASM syntax need not be complex or "alien" for any reason
but "tradition" enforced by "peers"...by its example that, yup, you
can be up and running productively by simply following the "re-use"
paradigm (at first, using Randy's routines but the _example_ of how
much power this method can get you, I'm sure plenty of HLA users will
go on to employ just the same "re-use" in their subsequent code, even
long after giving up on HLA :)...
"Prejudice" is "negative ignorance"...it is simply combatted by
_facts_ and by _good example_ that, yup, it's just total bollocks and
always has been...yes, I take this further than most but with good
reason...the "myths" about ASM are just _prejudice_ about it and about
the _ONLY_ thing that actually stands up to scrutiny is
"non-cross-portability" (only, though, because by implementing things
like "macros" to solve such a problem actually turns it into a HLL of
sorts...remember, this statement is always true: "what the CPU can do,
ASM permits"...there are NO limitations or restrictions but that which
you _choose_ to put upon yourself ;)...
Although, this, in a sense, is absolutely great in this review because
praise is poured over AoA and HLA thereafter, demonstrating that
Randy's cracked one more HLL nut by good example, to explain to them
that this whole "nudge, nudge, wink, wink...isn't ASM stupid?"
attitude actually has very little grounds in reality...for once,
rather than "joining the gang" to share this "joke that no-one
actually understands", they've taken a look and seen that - oh - there
never was any joke there in the first place...like the Emporer's new
clothes, it's a joke that everyone laughs at - simply because everyone
else is laughing at it so, like, it's just _got to_ be funny, right? -
but actually _no-one_ is ever comprehending...and, a bit like that
story, the actual joke is on them because though ASM may not be
practical for everything and won't go storming into "dominance" or
anything, it always was, is and will be the best all-round, fastest,
most code efficient, smallest output, etc. language...that, by the
way, is _by definition_ - these are the very _elements_ of the CPU
itself, there is NO going lower without cracking open your machine -
so it's quite indisputable...but, well, so was the fact that the
Emporer was naked and that didn't stop people arguing that he was
well-dressed regardless...
To demonstrate what I mean, let's just grab two particular sentences
from the review and then put them next to each other in juxtaposition,
which highlights the common mild confusion and contradictions that
_most_ HLL people carry about ASM: "As noted earlier, the low-level
aspects of assembly tend to scare away even seasoned programming
veterans"...and then: "Anyone truly interested in learning programming
should possess at least rudimentary knowledge of assembly language
coding"...
So, our "seasoned veterans" are anything but...because "For such
people, assembly often resembles some cryptic dialect of a long
forgotten code. For others, assembly appears as a mesh of strange
instructions and bizarre numerical strings"...and this is by the
subtext of the reviewer himself...
I also always have a problem with people misusing the word
"technology" like: "Luckily technology has brought forth a new concept
to address the intricacies of assembly code"...Star Trek-like "techno
babble"...platitudinous esoterica...the "technology" involved was
Randy thinking "let's use some HLL-like syntax for the bits that
aren't machine instructions because, well, that's all made up nonsense
that's different from assembler to assembler, anyway...so, it makes no
difference other than _COSMETIC_...and, in truth, assembly isn't bad
and never has been...but we need to alter the _COSMETICS_ involved so
that people will give low-level programming a chance...once they
attempt it, then it will do its own salesmanship...some will like,
some will loathe...but that's great...what is actually important here
is that people are operating on _FACTS_...they are forming _informed_
opinions...from their actual _experience_...if they then choose not to
like then at least there's going to be a _good reason_ why they don't
like from what they experienced...rather than for some 'Big Brother'
to choose their opinions for them and try to lock them into that with
peer pressure"...
Well, okay, Randy probably didn't think exactly this...some of _my_
thoughts have sneaked their way in at the end there...but, well, "I'll
use HLL syntax" is hardly "revolutionary technology"...hey, maybe I'm
too old-skool on this but I don't really like the word "technology"
used on anything non-hardware at all...the word can strictly extend
beyond the non-physical to ideas and such, of course, but,
increasingly, the word is being abused to make anything and its pet
dog sound impressive...Randy did have a good idea...but "good idea" -
though actually really "gold-dust" in comparison to this "technology"
word...anyone can use "technology" but "good ideas" are an unfortunate
rarity - just doesn't sound too "technical" or impressive...so it's
phrased as "great new technology!!"...for example, I've developed my
"ellipsis" style of writing to mimic spoken language and give dry
ASCII plain text a more personal edge in doing so...potentially a
"good idea" in some people's eyes (a dreadful, verbose "evil" in
others, mind you ;)...so does me typing three dots in a row count as
"bold new technology"? Of course it bloody doesn't...
Nope, I'm NOT taking away from what Randy has done at all...my
emphasis here is that the concept of "good ideas" - which Randy had -
should be given its due respect for the gold dust that it is...blindly
calling it "technology" because that, like, sounds impressive and
stuff is, to my mind, actually the greater insult to "good ideas" and
specifically Randy's good ideas...changing the cosmetics of the syntax
to make things readable and to, yes, simply give the cosmetic
impression that this is something "bold, new and different" - just to
get people to overcome their inaccurate prejudices about assembly
language - is a damn good idea...it has already proved its worth and
can only get better...some "revolutions" are often distinctly
unimpressive in their "technology" and implementation...but that does
NOT make them any less a revolution...after all, all the French really
did was realise that humans aren't actually pre-destined or appointed
by God or anything to be "aristocrats" and "common folk" and then say
"right, that's it...we're not maintaining this corrupt aristocratic
system any longer"...shame it had to be done in such a bloody way, as
that blood does forever pollute Western civilisation...the rich
aristocrats forever rightfully paranoid as hell that the "common folk"
will swamp them and send them to the guillotine once more...making
them defensive about protecting their higher status when, really, it
should stop being turned into a "fight" all the time...everyone is
equal...different, yes, but equal...that difference, by the way, is
_GOOD_...absolutely bloody excellent, in fact...and the point that
gets lost in all the fighting and stuff is the simple logic...if all
are "different but equal" then the aristocrats must, therefore, _ALSO_
be "common folk" too...just a different kind of "common"...but that's
good...they have skills and experiences others don't that must surely
have a good use...well, fair exchange is no robbery...
But there's no getting through to some people...let's just sit back
and watch "prolateriat leftist" Rene insist on sending all those he
thinks - with fair trial or jury or anything - as "aristocrats" to the
guillotine...I guess just like the aristocrats, red can be in the
blood as much as blue blood...well, okay, whatever...roll on the
"rebirth", where NOTHING has essentially changed at
all...whatever...truth can only be denied for so long...I have perfect
Faith...it's just a matter of "when", not "if"...
Only a matter of time, people...only a matter of time...let's just
Hope we give ourselves long enough in which to do the necessary...as
it's just as possible to stuff things up permanently, just when
everything was on the verge of being permanently fixed...
http://www.iop.org/EJ/S/UNREG/pvr8HZnX1IcWM2qkSpyFuQ/news/-topic=632/j
ournal/JMM
Yup, I'm a complete and utter total nutter...100% certifiable...but I
take complete pride in that..."common sense" often isn't very common
or sensible...if everyone is seeing the world in the wrong light then,
to see it correctly, you _must_ basically be insane...you _must_ be
seeing a "reality" that everyone else isn't appreciating...that's why
all those who changed the world - Corpernicus, Decartes, Newton,
Pasteur, etc. - were all clearly "insane" ;)
"Words ought to be a little wild for they are the assaults of thought
on the
unthinking."
[ John Maynard Keynes ]
"Slip inside the eye of your mind
Don't you know you might find
A better place to play
You said that you'd once never been...
All the things that you've seen
Will slowly fade away
So, I start the revolution from my bed
'Cos you said the brains I have went to my head
Step outside...the summertime's in bloom...
Stand up beside the fireplace
_Take that look from off your face_
Because YOU AIN'T EVER GONNA BURN MY HEART OUT...
So, Sally can wait, she knows it's too late
As we're walking on by...
Her soul slides away...
But 'don't look back in anger', I hear you say
Take me to the place where you go
Where nobody knows if it's night or day
Please DON'T put your life in the hands
Of a Rock n Roll band..
Who'll throw it all away...
So, I start the revolution from my bed
'Cos you said the brains I have went to my head
Step outside...the summertime's in bloom...
Stand up beside the fireplace
_Take that look from off your face_
Because YOU AIN'T EVER GONNA BURN MY HEART OUT...
So, Sally can wait, she knows it's too late
As we're walking on by...
Her soul slides away...
But 'don't look back in anger', I hear you say...
'Don't look back in anger'
'Don't look back in anger'
'Don't look back in anger', I heard you say...
...at least...not today"
[ "Don't look back in anger", Oasis :) ]
Beth :)
--
"Every gun that is made, every warship launched, every rocket fired
signifies in
the final sense, a theft from those who hunger and are not fed, those
who are
cold and are not clothed. This world in arms is not spending money
alone. It is
spending the sweat of its laborers, the genius of its scientists, the
hopes of
its children. This is not a way of life at all in any true sense.
Under the
clouds of war, it is humanity hanging on a cross of iron.”
[ Dwight Eisenhower ]
Betov
news:3f9561f3$1...@news.broadpark.no:
:)
Happy to see that everybody is not utterly blind.
Nevertheless, if HLA syntax was the only problem,
this would simply be funny, and if Master Pdf ego
terrific problems was the ony problem, this would
simply be so ridiculous that it would more likely
diserve a tear drop than laughs.
Unfortunately, beyond the syntax, there are the
Programming Methods... which are the true major
problem with that awfull shit, as all of the
advantages, power and originalities of true Asm
Programming are then utterly defeated.
Betov.
Betov
@newsread3.news.pas.earthlink.net:
So nice! The disaster is going on pretty well...
Of course, no need i sing my usual song:
"Where are the Assembly written Applications
the author of this 'Review' ever wrote?"...
Sad days for Assembly.
Betov.
sinewave
> So nice! The disaster is going on pretty well...
J-E-A-L-O-U-S
> "Where are the Assembly written Applications
> the author of this 'Review' ever wrote?"...
LOL. give it a rest. do automotive engineers ask car reviewers "hey, where
is the car you made?"
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message news:18elb.469$Sb2...@newsfep3-gui.server.ntli.net..
[A whole lot that I won't repeat here]
Yeah, I had to laugh at the 16-bit DOS reference myself.
Despite the inaccuracies, plus the fact that the guy wrote the review after
reading only three or so chapters, I was still pleased over all with the
review. As for sneaking in snide remarks that make assembly look
bad to the zealous- well, all I can say is that at least the guy didn't
start panning the whole subject along the lines of "why would anyone
want to learn this stuff today? It's all obsolete."
The good news is that it's articles like this that slowly begin
turning people's attitudes around (versus the articles quoting
Bill Gates when he said that "assembly language is the only
programming language that is going to die.")
I'm also a bit encouraged by the responses to the article.
Again, none of the "what publisher would be stupid enough
to come out with a book on such an outdated subject as this?"
kind of statements you'd have seen in the 1990s.
Cheers,
Randy Hyde
Randall Hyde
"Betov" <be...@free.fr> wrote in message news:Xns941BD074D6...@213.228.0.133...
Yep. Sure is.
As I warned you way back when -- once the book appeared
there would be a groundswell of support for HLA appearing.
I'm so happy you're pleased! The good news is, this pushes
the assembly rebirth back at least another year, so you've got
lots of time to work on BetovTool!
> Of course, no need i sing my usual song:
>
> "Where are the Assembly written Applications
> the author of this 'Review' ever wrote?"...
Well, you gotta give him a break. He's just getting
started with assembly. Sorta like the majority of people
learning assembly language with HLA and AoA.
But give them time. By the time BetovTool finally does
appear two years from now (by your estimates, anyway),
there will be lots of HLA programmers writing lots of
assembly applications.
> Sad days for Assembly.
Really. It's too bad it's taken so long for this to happen.
But happy days are just around the corner. Soon you
*will* start to see lots of assembly applications written
in HLA and the "assembly rebirth" will be well underway!
Cheers, And God Bless,
Randy Hyde
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message news:18elb.469$Sb2...@newsfep3-gui.server.ntli.net...
> Randy wrote:
> > Check it out:
> > http://www.techimo.com/articles/i115.html
>
> Okay, you know me...I just got to bitch about something (but, no, in
> truth, I'm merely pointing out errors and interesting tid-bits, so
> that they don't mislead or happen again or just for education and
> entertainment...it's not really as "bitchy" as it may first appear
> ;)...
You know I only posted this message to piss off Rene :-)
The good news is that every one of these reviews that appears
to be half-way positive winds up convincing a few more people
to take a look at assembly language. That's the important thing.
cheers, and God Bless,
Randy Hyde
hutch--
Come on Betov, your sour grapes are showing again because BetovAsm is
such a flop that almost no-one will use it. It must be terrible to be
an aspiring highly self acclaimed leading guru in the assembler world
when everyone knows that BetovAsm is a pile of crap that does not
perform.
As "Art of Assembler" is a classic work and HLA goes from strength to
strength, the sheer envy you have for Randy Hyde's success must be
burning a hole through the remains of your credibility at the moment.
Is this smouldering discontent the byproduct of your failure to become
the highly self acclaimed leader of the rebirth of assembler when it
never died in the first place ?
When Microsoft released MASM 611 in 1993 complete with 32 bit code,
where and who was Betov ? While AOA was on the internet from as early
as 1996, where and who was Betov ? When MASM32 was released in late
1997 where and who was Betov ?
Here is the progression, sour grapes wrung out to become the grapes of
wroth generously poured into Betov as orally induced euphoria while
recriminating about being years too late to effect anything and out of
date with the events that just went past you.
Muhahahaha.
hutch at movsd dot com
Beth
> Beth wrote:
> [A whole lot that I won't repeat here]
[ Understandable; I actually would always advise anyone answering me
to not hesitate to "snip, snip, snip" practically everything but what
you want to respond to...I write presuming that it won't be repeated
in full in quotation...it's actually annoying to even me to have the
full text repeated, just for "yes" or something...by all means, get
all "snip happy" (a bit like "trigger happy" but less violent ;) with
my posts...I am basically _expecting_ that to happen :) ]
> Yeah, I had to laugh at the 16-bit DOS reference myself.
>
> Despite the inaccuracies, plus the fact that the guy wrote the
review after
> reading only three or so chapters, I was still pleased over all with
the
> review.
Yes; Because the overall tone is a very marked and welcome change to
what assembly language usually gets...
> As for sneaking in snide remarks that make assembly look
> bad to the zealous- well, all I can say is that at least the guy
didn't
> start panning the whole subject along the lines of "why would anyone
> want to learn this stuff today? It's all obsolete."
Ah, yes...I wasn't actually saying that snide remarks were delibrately
snuck in by this reviewer...but more that the subtext...the way he
phrased things...suggests that this reviewer has been previously
"kee-boshed" by the ASM "myths" and negative propoganda and so
forth...as I said, it's more a "Freudian slip" revealing the
psychology from which the reviewer is coming from, than anything
delibrately nasty (it's, in fact, refreshingly NOT nasty at all :)...
So, in fact, it's NOT any insult on the reviewer because I'm
completely sure it was in no way delibrate...in fact, that's where the
review really has its true "success"...what actually makes the overall
tone of the review absolutely excellent for assembly language...
This person was once amongst the ranks of the "assembly language is
dead! Assembly language is evil! et cetera" brigade...but you've
mananged to side-step that prejudice and made he review what was
actually in front of him, rather than a "phantom book review" of ASM
in general...
And that _does_ happen, as I'm sure you know...like that "article" the
Sage quoted where they were weirdly comparing a particular
implementation of Ada, not to a particular ASM implementation...but
were comparing Ada to some nebulous characture of ASM...you know,
comparing to the "stereotype"...to the characture of the
"myths"...creating a very weird sort of comparison...certainly
untrustworthy because, well, how do you make a valid comparison
between, for example, "a particular brand of cigarettes" and "the
general concept of all addictive behaviours (including smoking,
alcoholism, shop-a-holics, the adrenaline rush of sports activity, the
addiction of money makers on the stock exchange floor driving
themselves to ill health, workaholics, etc., etc....a _very, very
wide_ subject indeed ;)"? The comparison is as far from "like for
like" as you could imagine up in your wildest dreams...
As always, the best and cleverest things are actually very
simple...you are succeeding here where assembly language so often
fails - even, let's remember, having only a "prototype" here that it's
not currently totally at "professional levels" (well, the language
design is but the implementation isn't, depending on other tools and
so forth...of course, it works so that's basically all that
counts...but I'm sure you'd agree that HLA in _implementation terms_
is not really "professional", as it _is_ just a "prototype"...the
rest, though, especially the documentation is already at the required
level, for sure :) - is actually something amazingly
simple...ironically, the main thing that so many in the ASM world
criticise immediately about HLA...
HLA simply doesn't _look_ like assembly language...and that's caused a
very interesting psychological phenomenon with at least this reviewer
but I would guess with many others too, that they aren't seeing the
"characture" of this "evil" assembly language...with all those
attached "myths"...despite not personally liking the phrase
"technology" being used in this context...the point is that the
reviewer actually _believes_ there's been some fantastic advancement
in assembly language "technology" (the reviewer - coming from the HLL
world - doesn't appreciate that ASM actually, in a sense, NEVER
changes...it's not like HLL "standards", where they keep changing
it...ASM is based on the CPU and, thus, is always anchored to the
CPU's capabilities...and, in the case of the x86, only minor
"extensions" appear with new chips, not radical re-designs or
anything...now, you can change "mov" to be "copy" syntactically but,
physically, it still assembles down to the same binary opcodes...the
"technology" NEVER changes in ASM, in a manner of speaking...ASM
always stays the same...what changes is the tool support, the syntax,
the way to approach it, etc. :)...and because they firmly believe that
this is "new" and, therefore, NOT the "assembly language" they once
knew then the "myths" and "stereotypes" and "prejudice" against
assembly language that they'd accumulated over the decades was
side-stepped...
This reminds me of something a British comedian did...he's a black
man - Lenny Henry - but he walked into the make-up department and they
went as far as their "make-up technology" would allow to make him up
to look like a white person...not just colouring the skin colour but
changing the shape of the nose and other things...and the result was
not completely perfect when you knew it was all make-up but it was
convincing enough to make the point...especially when he simply put it
to the test and saw how people reacted...how they reacted
_differently_...exactly the same person, just - using make-up - made
to look different...and even people who aren't really "racist" or
anything still do actually react differently - not malicious or
prejudiced, just those subtle little things that work their way into
all social consciousnesses (that was perhaps the most interesting
thing about the "experiment" that, in fact, the comedian wanted to
learn about and saw to people...that not all "racism" is overt
name-calling or violence or anything...just simple things like
hesitating to talk to someone of a different skin colour...talking in
a different way) - but didn't when they believed he was a white
man...mind you, it also proved to an extent that not all negative
reaction is racism but can simply be a clash of personalities...but
when the skin colour is there, it tends to get in the way and everyone
presumes it's a "race thing"...
Anyway, I'm thinking that HLA's unique approach to syntax - making it
look like a HLL without, in fact, being any more "high-level" than
MASM (other than the "compile-time language", which is actually a
_preprocessor_ thing and actually not really part of the language) -
meant that the reviewer (and, no doubt, others) are prepared to give
HLA a fair review...because the ASM stereotype - the black man
stereotype - has been cosmetically removed...instead of looking
through those stereotypes, they are looking at the real thing and
reviewing what they find...and, yup, with fair and objective review,
assembly language might not be winning the top prize on all scores or
anything but it's NOT bottom of the heap by any means...but, of
course, in the HLL world, by the prejudices, according to Bill Gates,
ASM most certainly is bottom of the heap that it's not just "dead" but
they'll make sure to kill it off, if it puts up any resistance to
laying down and dying...
It's just a slight cosmetic change...a purely psychological thing...I
know ASM and always try - because of my personality - to actually
_look_ properly at a thing before coming to a judgement...and I've
toyed with HLA and, sorry, it's an assembly language...that may really
piss off Rene...but don't blame me for that...blame the _fact_ that it
is and the _fact_ that you don't want it to be...I'm reporting the
facts as I find them...
And, by this, HLA has pulled off an amazing little trick...it's made
ASM _look_ different...it's actually not really any different in
nature or method and it all, of course, reduces to all the same binary
output...but it seems different...so people aren't looking it as
ASM...they are looking at it directly...as what it is...and these
persistent "myths" about the "evil" of ASM, they just don't see
anymore...much like when the very same black man appeared to be white
(note he didn't bother changing his voice or behaviour or movements or
anything), they just didn't see the "problem" anymore...because, in
both cases, the problem was always _perception_ and _prejudice_, not
any actual significant differences...
Actually, it also reminds me of another gem of TV I once saw...Ruby
Wax is a comedian, who's actually an American but works over here in
Britain (and cleverly exploits her "dual culture" to sometimes be
American when that works or be British-like when that works :)...and
she's also Jewish, as well as being incredibly funny when she's on
form...and she had a series of programmes where she would interview
various people and one of her interviewees was some members of a Klu
Klux Klan group...and, boy, did she totally rip them apart...but she
did so by simply talking over their heads...they had no idea what
complete morons and fools they were looking like - thinking she was
just great - but the viewers were all laughing their heads off at some
brilliant comedy...she didn't insult them in any way, she didn't need
to...they did all that for her...she just set them up - talking over
their heads completely - for them to hang themselves by their own
rope...and, overall, there was the immense, immense comedy that this
group was firmly anti-semitic...they would call for "kill all Jews"
and that sort of thing...so, hats off to Ruby Wax for not doing this
so brilliantly but doing where she's not actually necessary safe to be
pulling such a stunt...if they'd realised what was going on...but, I
suppose, that was Ruby's point that they were so ignorant that there
was actually very little chance of them thinking that far and working
it out...anyway, the hilarious joke running through the entire
programme was that they were rabidly anti-Jewish but they didn't
realise - because you can't see visibly see it like skin colour - that
their interviewer was Jewish...I presume she simply "neglected to
mention it" and, thus, wasn't lying to them...they simply never
asked...and the show ended on a masterpiece of comedy where they'd
liked the way Ruby had been "friendly" throughout (superficially, if
only they could have realised what she was saying over their heads ;)
and actually tried to "recruit" her into their anti-Jewish group...she
politely declined...it's hard perhaps to get an appreciation but this
was an amazing piece of TV and Ruby Wax - though sometimes her comedy
is very "hit and miss" - is such an intelligent comedian who's
hilariously funny when she's on form...and was she on form here...
Clearly, though never mentioned nor did she ram home any moral points
or anything, her choice of these people for interview was very
delibrate...her tactic was simple...she was not going to confront them
or anything...totally friendly and polite throughout (but at no point
did she ever lie specifically or pretend she agreed with them or
anything...like a politician, she just avoided the issue by moving
onto a different question :)...and the idea was to simply film them
being them and they would make the "moral message" for her completely
by their own words and actions...as you realised what complete morons
full of contradictory and nonsensical "opinions" they were...
The reaction to assembly language and the fact that, despite not
actually being anything vastly different but cosmetic, HLA is just an
assembly language but somehow breaks straight through all the
prejudices...
Well, in a sense, that was the actual point I was trying to
make...this person was speaking in the "prejudiced" tone about
assembly language in the review but NONE OF THIS effected the good
review of HLA...
So, in fact, no, he was not sneaking any _delibrate_ snide remarks
about ASM...but his tone suggests that he's heard all the "myths" and
prejudices and was taken in by them...so the fact that HLA walked
straight through this totally unscathed is a very significant thing
for two reasons...
First, HLA's found the way to "side-step" assembly language
criticism...just don't _look_ like an assembly language, make yourself
look like something familiar...
Second - and I find this point highly crucial here - that the "myths"
and "prejudice" must actually be total nonsense...if ASM was the
things that they claimed...if it was inherently in assembly language
itself then how could they not see it when they are looking at HLA?
Which, technically, is at MASM / TASM's level...just with a much
better preprocessor included and just a few simple library routines
supplied to help people get up and running at first...I mean, none of
the complaints in the "ASM myths" ever related to assembly language
being "evil", due to the lack of a good preprocessor (an accusation
that could NEVER be made, anyway...as ASM's macro facilities have
always generally been of standards that HLLs should be envious of,
even before HLA took this to new levels...because, well, MASM's macros
versus the pathetic C preprocessor? ;)...
That's the general point that I thought was so important to be made
that I had to somehow get the message across...logically, how could
assembly language actually be fulfilling these "myths" - that this
stuff is "inherent" in assembly language - when an assembly language
that does nothing significant about this in particular, but to choose
a syntax so that people looking at it won't really realise what it is
they have in their hands, is able to pass by many people and not pick
up a single one of these supposedly "inherent" problems with assembly
language?
Though, this was only one basic review...so it's not conclusive
yet...but if this trend keeps up with many people looking at HLA then
more and more only one particular conclusion can be drawn...the
"myths" always were nothign but lies and exaggerations...attempts to
do ASM down for no particular reason but prejudice (probably caused,
ironically, by _KNOWING_ that ASM is "advanced" and amazingly capable
that when they couldn't pick it up immediately and found it all too
"awkward", they simply wanted to destroy it...because then - knowing
that the ASM "gurus" therefore _do_ know more than them, especially
when these gurus are also just as good with HLLs too - they didn't
want anyone to be doing "better" than them...you know, the old ego
"zero sum" thing in reverse...they're "winning" so I must be
"losing"...I don't want to "lose" so I'll destroy that thing that they
are using to "win" and then we're all "even" again...a false premise,
really, though...because, in truth, none of this is "winning / losing"
territory at all...and ASM people are quite, quite happy to have more
"recruits" - well, we have our psychological "issues" too...namely,
"individual" is good but, well, it would be cool if this was a "crowd"
as well...safety in numbers and all that...you don't seem as much of a
"freak" when everyone has the same "issues" you do ;)...
> The good news is that it's articles like this that slowly begin
> turning people's attitudes around (versus the articles quoting
> Bill Gates when he said that "assembly language is the only
> programming language that is going to die.")
Oh, who on Earth listens seriously to Big Bill? He hardly has a great
track record at these predictions, after all: "640KB is more than
enough for anybody", right? (which is even more hilarious when people
probably could have half the RAM in their machines happily than they
do now, if Windows wasn't trying to compete for the "greatest waste of
memory ever in existence" award ;)...
No, quite right...unfortunately, even if utterly inaccurate in all his
predictions, he's a "computer superstar" so people will listen to him
regardless...but I really wish he'd stick to commenting on what he's
actually good at - money-making business practices...on that, sure,
he's the world's foremost expert of greed - and keep out of his
"technical" predictions because, without fail, he's proved he has very
little idea of what he's talking about...I mean, will he be buying up
Manchester United or Barcelona or wherever it is that Beckham is now
and then saying "I'm the world's best soccer player because I own the
best teams"? He's a businessman who's made his money in this
field...his utter contempt for the industry and his lack of even basic
accurate predictions tells me that he has little to no "spirit" for
the industry but for the money it can make him...it's not in his
soul...and he has no artistic spirit...well, I suppose you might say
he's a "piss artist", as we charmingly phrase things over here in the
UK, but that doesn't quite mean the same thing, I can assure you ;)...
It certainly is good news, of course...but I'd rather not look the
fool like Bush did declaration the "war is over" before it had even
really begun in earnest (also, just to point out, he actually NEVER
officially declared war in the first place - it was an illegal war
however "noble" you may or may not believe the sentiments of fighting
it were - so they never officially declared it as is demanded
internationally, as yet another "loophole" that this Bush
administration uses to avoid be subject to the law and scrutiny that
is demanded of them and America willingly signed up to...America,
often, was one of the principle founders in these laws, as, yes, She's
always saught to bring justice and democracy to the world...but Bush
only believes in the gun and certainly not any form of diplomacy
because he's the worst diplomat America has probably ever had...90% of
the bad feeling towards America is that her main representative is
this dreadful man...his Tough Texan talk of "you're with us or against
us" managed to completely unravel unprecedented sympathy and
international co-operation from all over the world for America after
9/11...no politician, I reckon, has ever turned such massive
unrestrained sympathy to want to assist America into outright denial
of her and her policies...even if you're a firm believer in the
Neo-con agenda then it's even in those interests to change the guy up
top because he's a total and utter liablility to America in
international eyes...of course, it's America's democratic right to
choose but, well, a word to the wise: even if you want right-wing
Republicans waging war, at least kick out this liability because he's
a dick and has consistently made America's job more difficult in the
world every time he opens his mouth because a diplomat he is NOT,
that's for sure)...
> I'm also a bit encouraged by the responses to the article.
> Again, none of the "what publisher would be stupid enough
> to come out with a book on such an outdated subject as this?"
> kind of statements you'd have seen in the 1990s.
Because Rome was not built in a day...these things take time but,
eventually, the truth will always force its way to the surface, even
with people who try to hide it and push it down being around...in
fact, that's how you can sort of tell that you're doing the right
thing...if you keep at it and the tide slowly turns then, yes, you had
it right and were simply the "pioneer" who saw it first and had to
bring it through...if, on the other hand, nothing seems to be
happening after a long while, then perhaps you really did grab the
wrong end of the stick...in your case, I don't believe that's correct
at all...in fact, I was able to see what you were doing pretty early
on and, thus, I'm actually frustrated by v2.x not being out yet and so
forth...I'd like to see it further along...but, well, don't take that
as "average" opinion, I'm just impatient and picked up the "vibe" of
HLA before many others did so, relatively speaking, I've been sitting
around longer (although, not as long as you, obviously ;)...
Beth :)
sinewave
> When Microsoft released MASM 611 in 1993 complete with 32 bit code,
> where and who was Betov ? While AOA was on the internet from as early
> as 1996, where and who was Betov ? When MASM32 was released in late
> 1997 where and who was Betov ?
he was eating mcdonalds fries, drinking coke, and rebooting his windows
box.
Mitch Crane
@newsread3.news.pas.earthlink.net:
> The good news is that it's articles like this that slowly begin
> turning people's attitudes around (versus the articles quoting
> Bill Gates when he said that "assembly language is the only
> programming language that is going to die.")
Ha! How else does he expect people to hack the Xbox?
--
ybbxvatyvxrnobeantnvayvivatyvxrnurergvpyvfgravatgbneguheyrrerpbeqfznxv
atnyylbhesevraqfsrryfbthvyglnobhggurveplavpvfznaqgurerfgbsgurvetrareng
vbaabgriragurtbireazragnertbaanfgbclbhabjohgnerlbhernqlgborurnegoebxra
Randall Hyde
"Mitch Crane" <a-...@a-two.a-three> wrote in message news:Xns941CDA19CF79761...@216.196.97.132...
> "Randall Hyde" <rand...@earthlink.net> wrote in news:ZLnlb.748$wc3.540
> @newsread3.news.pas.earthlink.net:
>
> > The good news is that it's articles like this that slowly begin
> > turning people's attitudes around (versus the articles quoting
> > Bill Gates when he said that "assembly language is the only
> > programming language that is going to die.")
>
> Ha! How else does he expect people to hack the Xbox?
>
By reading "Hacking the XBox"!
http://www.nostarch.com/
Cheers,
Randy Hyde
Mitch Crane
=) Yes, I should buy it just as a keepsake. Bunnie Huang is a very smart
and interesting guy. But that stuff's old hat now.
--
ybbxvatyvxrnobeantnvayvivatyvxrnurergvpyvfgravatgbneguheyrrerpbeqfznxv
atnyylbhesevraqfsrryfbthvyglnobhggurveplavpvfznaqgurerfgbsgurvetrareng
vbaabgriragurtbireazragnertbaanfgbclbhabjohgnerlbhernqlgborurnegoebxra
The Half A Wanna Bee
> Randy wrote:
> > Beth wrote:
> > [A whole lot that I won't repeat here]
So basically what you are saying, besides numerous other and well,
interessting things, is that a Black man would do well to follow HLA
example? Just wear make up ! You'll get the job, just get that Black look of
you face, and we'll hire you at once
:-) LOL.
Now I go back to read the rest of you post (I am half way in as allways),
incase I am missing something, but this going to take some time so I
thought I reply like this while my mind could still hold on to my desire to
do so....
The Half A Wanna Bee
> Randy wrote:
> > Beth wrote:
> > [A whole lot that I won't repeat here]
> Actually, it also reminds me of another gem of TV I once saw...Ruby
> Wax is a comedian, who's actually an American but works over here in
> Britain (and cleverly exploits her "dual culture" to sometimes be
> American when that works or be British-like when that works :)...and
> she's also Jewish, as well as being incredibly funny when she's on
> form...and she had a series of programmes where she would interview
> various people and one of her interviewees was some members of a Klu
> Klux Klan group...and, boy, did she totally rip them apart...but she
> did so by simply talking over their heads...they had no idea what
> complete morons and fools they were looking like - thinking she was
> just great - but the viewers were all laughing their heads off at some
> brilliant comedy...she didn't insult them in any way, she didn't need
> to...they did all that for her...she just set them up - talking over
> their heads completely - for them to hang themselves by their own
> rope...and, overall, there was the immense, immense comedy that this ....
I see your point, would have loved to see the show, and would probably make
me laugh as well. But I also see another point. Theese people run a theather
were its them against us, Black people or foreigners against them. Ruby Wax,
does exactly the same, but in her world, its the morons against the bright
people.
(Not having to mention that Ruby Wax is a moron in my world all the same).
In this group its the same, or some variation. Us against Them. It allways
is isnt it ? Would be quite intolerably boring without it ?
The Half A Wanna Bee
> Randy wrote:
> > Beth wrote:
> > [A whole lot that I won't repeat here]
(*
Oh, who on Earth listens seriously to Big Bill? He hardly has a great
track record at these predictions, after all: "640KB is more than
enough for anybody", right? (which is even more hilarious when people
probably could have half the RAM in their machines happily than they
do now, if Windows wasn't trying to compete for the "greatest waste of
memory ever in existence" award ;)...
*)
This is another of those rumors that I'd like to have confirmed properly.
The last time I heard it, it was 64K, not 640K. To THAT poster I told him to
verify it, and also told him that it would be strange for Bill to say such a
thing since 640K is standard in all the x86 machines. To which the poster in
anger posted a page full of links to other people repeating the same rumor,
and then he thought he had proven it !
I heard a similar rumor, back in 94, while on a networking seminar, the
theacher used to open the class with something funny so he told the story
about a writer for the BITS magazine who once had said that 256K of memory
was all the memory that a computer would ever need. Still that rumor is not
confirmed, but I guess its possible to confirm it if you can get hold of
those magazines.
I read Bill Gates book back in those days when it came out. You know once MS
was a small small company trying to make it. The Big Software houses in
those days, IBM and APPLE were laughing at MS and telling everyone that they
would never make it. I guess they are regretting that today. They are
regretting that they didnt take them seriously then, while there wore still
time.
I am regretting it too. Since then we would maybe have a REAL alternative.
The Half A Wanna Bee
> Randy wrote:
> > Beth wrote:
> > [A whole lot that I won't repeat here]
Puh! Dont get me wrong Beth, I love you postings ;-)
The Half A Wanna Bee
"Randall Hyde" <rand...@earthlink.net> wrote in message
news:M6Hlb.1579$wc3...@newsread3.news.pas.earthlink.net...
Randy. I tried to order your book. But is it impossible to order it without
a Creditcard ? I hate creditcards and I allways pay on delivery. Maybe I
could pay in advance ? I would never use a creditcard on the internet even
if I had one. The first thing I did with my creditcard when they mailed it
too me, was to break it in half and toss is into the trashbin. (To protect
myself from myself) It never cost me a dime since then :-) Maybe I should be
looking for it in the stores ? Maybe your book will be in Norwegian stores
any time soon? Do you know ?
I dont like the HLA code much, even if its syntactically correct perhaps. It
put me off, but I still would love to be able to read your book in paper
format. Since I have read some of the online PDF and I liked it very much.
And it contains a LOT of stuff I never knew. I generally think that good
information about environment etc is far more important than the language to
program in. So I try to addon the really good stuff whenever I can. And I
prefer to read away from the PC.
The Wannabee.
Randall Hyde
"The Half A Wanna Bee" <Shaka...@hotmail.com> wrote in message news:3f97effc$1...@news.broadpark.no...
>
> Oh, who on Earth listens seriously to Big Bill?
Lots of people who make the decisions in this world :-(
> He hardly has a great
> track record at these predictions, after all: "640KB is more than
> enough for anybody", right? (which is even more hilarious when people
> probably could have half the RAM in their machines happily than they
> do now, if Windows wasn't trying to compete for the "greatest waste of
> memory ever in existence" award ;)...
> *)
That quote was well before Windows came along, IIRC.
> This is another of those rumors that I'd like to have confirmed properly.
> The last time I heard it, it was 64K, not 640K. To THAT poster I told him to
> verify it, and also told him that it would be strange for Bill to say such a
> thing since 640K is standard in all the x86 machines. To which the poster in
> anger posted a page full of links to other people repeating the same rumor,
> and then he thought he had proven it !
It was 640K. I remember the original quote when it was made in the middle 1980's
and I remember laughing at it back then (note that hi-end machines had 256K at
the time and impressive machines were up to 512K).
> I heard a similar rumor, back in 94, while on a networking seminar, the
> theacher used to open the class with something funny so he told the story
> about a writer for the BITS magazine who once had said that 256K of memory
> was all the memory that a computer would ever need. Still that rumor is not
> confirmed, but I guess its possible to confirm it if you can get hold of
> those magazines.
I remember when 128K (on an Apple II) was a *very* impressive amount
of memory.
> I read Bill Gates book back in those days when it came out. You know once MS
> was a small small company trying to make it. The Big Software houses in
> those days, IBM and APPLE were laughing at MS and telling everyone that they
> would never make it. I guess they are regretting that today. They are
> regretting that they didnt take them seriously then, while there wore still
> time.
More likely, they regret showing Bill all their stuff in labs to give Bill
lots of ideas :-).
> I am regretting it too. Since then we would maybe have a REAL alternative.
Actually, it's a good idea Bill swiped that stuff. Else we'd all be doing DOS
still rather than using an OS ripped from from Apple (ripped off from Xerox).
Of course, we'd all be hating *NIX today, because that's the direction MS
was headed before the Windows push came along. I.e., had Bill not stolen
Apple's ideas, there would be no Linux today (as Microsoft would have
covered those bases).
Cheers,
Randy Hyde
Randall Hyde
"The Half A Wanna Bee" <Shaka...@hotmail.com> wrote in message news:3f97f760$1...@news.broadpark.no...
>
> Randy. I tried to order your book. But is it impossible to order it without
> a Creditcard ? I hate creditcards and I allways pay on delivery. Maybe I
> could pay in advance ? I would never use a creditcard on the internet even
> if I had one. The first thing I did with my creditcard when they mailed it
> too me, was to break it in half and toss is into the trashbin. (To protect
> myself from myself) It never cost me a dime since then :-) Maybe I should be
> looking for it in the stores ? Maybe your book will be in Norwegian stores
> any time soon? Do you know ?
Talk to the stores, the book is at the distributor so they can get it.
As for sending a check, that's something you'd have to talk to the
mail order outfit selling the book. That's one area, however, that
neither I nor the publisher has any control over.
> I dont like the HLA code much, even if its syntactically correct perhaps. It
> put me off, but I still would love to be able to read your book in paper
> format. Since I have read some of the online PDF and I liked it very much.
> And it contains a LOT of stuff I never knew. I generally think that good
> information about environment etc is far more important than the language to
> program in. So I try to addon the really good stuff whenever I can. And I
> prefer to read away from the PC.
Well, good luck finding the book.
Cheers,
Randy Hyde
Phil Carmody
> > I am regretting it too. Since then we would maybe have a REAL alternative.
>
> Actually, it's a good idea Bill swiped that stuff. Else we'd all be doing DOS
> still rather than using an OS ripped from from Apple (ripped off from Xerox).
> Of course, we'd all be hating *NIX today, because that's the direction MS
> was headed before the Windows push came along. I.e., had Bill not stolen
> Apple's ideas, there would be no Linux today (as Microsoft would have
> covered those bases).
What makes you think that Linus would have had less disdain for
Xenix 3.11 for Workgroups than he did for Minix?
Phil
--
Unpatched IE vulnerability: mhtml wecerr CAB flip
Description: Delivery and installation of an executable
Reference: http://msgs.securepoint.com/cgi-bin/get/bugtraq0305/48.html
Randall Hyde
"Phil Carmody" <thefatphi...@yahoo.co.uk> wrote in message news:87vfqfe...@nonospaz.fatphil.org...
> "Randall Hyde" <rand...@earthlink.net> writes:
> > > I am regretting it too. Since then we would maybe have a REAL alternative.
> >
> > Actually, it's a good idea Bill swiped that stuff. Else we'd all be doing DOS
> > still rather than using an OS ripped from from Apple (ripped off from Xerox).
> > Of course, we'd all be hating *NIX today, because that's the direction MS
> > was headed before the Windows push came along. I.e., had Bill not stolen
> > Apple's ideas, there would be no Linux today (as Microsoft would have
> > covered those bases).
>
> What makes you think that Linus would have had less disdain for
> Xenix 3.11 for Workgroups than he did for Minix?
>
Actually, Linus didn't so much have disdain for an existing OS as
he wanted to figure out how to write a scheduler himself. However,
the point being that Linux would probably have never reached
critical mass if MS' alternative had been available.
Cheers,
Randy Hyde
Beth
> Beth wrote:
> > Randy wrote:
> > > Beth wrote:
> > > [A whole lot that I won't repeat here]
>
> So basically what you are saying, besides numerous other and well,
> interessting things, is that a Black man would do well to follow HLA
> example? Just wear make up ! You'll get the job, just get that Black
look of
> you face, and we'll hire you at once
No, quite the contrary...the black man following this example will,
thanks to convincing make-up, get the job when there are racists who
would not give it to him because of his black face...
BUT I would not say that they are "doing well" to follow that example,
whatsoever...you may get the job...but the job is clearly NOT worth
having when you must deny yourself to get it and your bosses are all
racists so that's going to be intolerable crap to have to endure -
whatever skin colour you are - that such a job sounds like one of the
worst jobs imaginable (if I had a boss that was continually overtly
racist then I'd quit immediately...no, not actually "on principle"
specifically - though that is one aspect - but actually because I
really, really couldn't hack suffering such vile harassment...the
comments might not be aimed at me but that does not mean that I'd not
find them personally disgusting and the conduct deeply harassing,
upsetting and inexcusibly vile that I'd refuse to suffer it, no matter
what the job)...thus, they'd hardly be "doing well" to do so...
The point was merely that, in an actual real-life example, a black man
tried this and was treated differently for doing so (the only
significance of him being a TV personality is that he had some of the
best make-up artists and special effects people at his disposal to do
a convincing job of the disguise that it really did work in many
cases)...it should be noted carefully that he immediately removed his
make-up and did not put it back on ever again after completing his
little "social experiment"...clearly, he did not think it "doing well"
either and I'd support that conclusion 100%...
Because if there are people who will only treat you well when you have
a white face then those are people who really aren't worth knowing, so
who gives a flying crap how to get good reactions out of them?
Note, also, this was NOT an analogy in this case...I merely said that
the reaction to HLA _reminded_ me of this thing I saw on TV...it's not
an analogy so I was not actually implying there are any parallels to
be drawn whatsoever...
Except, possibly, the part about "if this is the only way to get a
good reaction out of them, then let them react as they like because
they aren't worth the effort" with regard to the various "phantom book
reviews" that HLA has received over the time...
Beth :)
Beth
> Beth wrote:
> > Randy wrote:
> > > Check it out:
> > > http://www.techimo.com/articles/i115.html
> >
> > Okay, you know me...I just got to bitch about something (but, no,
in
> > truth, I'm merely pointing out errors and interesting tid-bits, so
> > that they don't mislead or happen again or just for education and
> > entertainment...it's not really as "bitchy" as it may first appear
> > ;)...
>
> You know I only posted this message to piss off Rene :-)
Oh, indeed; But I also know from when I didn't say "oh, luvvie, you
were so perfect on the TV!" the last time, it was all like "'evil'
Beth is being nasty to Randy!" and stuff...hence, I thought I'd say
time by putting the "disclaimer" up front that I was delibrately in
full "nit-picking" mode, just to be delibrately awkward about
everything ;)
> The good news is that every one of these reviews that appears
> to be half-way positive winds up convincing a few more people
> to take a look at assembly language. That's the important thing.
Yup, it is a good review and it's all to the good...excellent
stuff...as you know, I've been a supporter of the HLA thing since I
first downloaded it...the rare exception of an assembly coder who
actually doesn't mind downloading and learning and trying out new
tools...I get the general gist of what you're doing - which is nothing
like what Rene seems to think it is - and that's cool...especially
because, despite what Rene implies, you started this all without any
sort of "reward" except "satisified customers" and have had to put up
with your fair share of crap for just trying to help by providing what
is a very powerful assembly language...what was it that someone else
once said: "you're an ASM angel!" ;)
Actually, ironically, because Rene's been spouting off against HLA
recently, I've been actually using it _more_ lately (the "Barnum"
effect...plus, I'm sorely tempted to start spamming the group with HLA
code, just to also piss off Rene a bit...although, in the interests of
fariness, I would later convert them to RosAsm...as I am really
"non-partisan" completely on these matters...if HLA gets a bit more
good PR from me then that's, sorry to say, just because there's more
good things to talk about with HLA ;)...and, with more usage, I'm
liking it more and more...
With every other tool, there's often a "sticking point" where there's
some missing feature or incompatibility or something that just
sucks...HLA actually has the _least_ of these kinds of problems,
though...and most tools fall over with Windows support...and _only_
HLA has excellent levels of Windows support while _also_ working quite
happily on Linux too...
The only problems I'd make a complaint about with HLA is actually on
the "integration" side with other things...I'd Love to use HLA for
adding assembly to some C++ programs and that sort of thing but, well,
MASM spits out COFF while my Borland C++ linker only eats
OMF...although, I've not tried the TASM option properly but I recall
you mentioning that it's more specifically tailored for working with
Delphi and wouldn't work otherwise...does FASM spit out the right
stuff? Anyway, that's something I'll have to experiment with, when I
get the time...I never bothered to look to deeply into it before
because I wasn't using HLA that much...but I'm thinking I'll be using
it more so I'll be playing around to find out how best to get the
thing to work :)
Also, here's one "biggie" complaint, in my opinion...HLA doesn't
accept "response files" for its command line and that would be
incredibly useful for integrating with my IDE which only spits out
_full pathnames_ (an option I select delirbately for other
reasons...namely, that I like to have lots of different folders for
"include", "source", "output" and so forth, as I don't like "file
sprawl"...which, by the way, was also a pain in the arse about HLA
before you added the "p" option to tidy those files away :) so, as you
can imagine, the command line just ain't long enough for all the
options and the full paths to the "temp" folder, output filename and
source filename and such (especially as I'm an "advanced" HLA user who
actually finds a use and switches on the "-sym" option, even though
that's only meant to be for your benefit in debugging :)...
Anyway, great...keep up the good work and all that jazz ;)
Beth :)
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message news:b2Amb.812$R85...@newsfep3-gui.server.ntli.net...
>
> The only problems I'd make a complaint about with HLA is actually on
> the "integration" side with other things...I'd Love to use HLA for
> adding assembly to some C++ programs and that sort of thing but, well,
> MASM spits out COFF while my Borland C++ linker only eats
> OMF...although, I've not tried the TASM option properly but I recall
> you mentioning that it's more specifically tailored for working with
> Delphi and wouldn't work otherwise...does FASM spit out the right
> stuff? Anyway, that's something I'll have to experiment with, when I
> get the time...I never bothered to look to deeply into it before
> because I wasn't using HLA that much...but I'm thinking I'll be using
> it more so I'll be playing around to find out how best to get the
> thing to work :)
You can, of course, tell MASM to emit OMF rather than COFF
(in fact, you have to tell it to emit COFF, it emits OMF by default).
By default, HLA tells MASM to generate an object file in COFF
format, but with a magical make file, you can tell HLA to let you
run MASM manually, e.g.,
hla -s myfile.hla
ml -c myfile.asm
<< now you have an OMF file>>
TASM output, of course, is another option.
> Also, here's one "biggie" complaint, in my opinion...HLA doesn't
> accept "response files" for its command line and that would be
> incredibly useful for integrating with my IDE which only spits out
> _full pathnames_ (an option I select delirbately for other
> reasons...namely, that I like to have lots of different folders for
> "include", "source", "output" and so forth, as I don't like "file
> sprawl"...which, by the way, was also a pain in the arse about HLA
> before you added the "p" option to tidy those files away :) so, as you
> can imagine, the command line just ain't long enough for all the
> options and the full paths to the "temp" folder, output filename and
> source filename and such (especially as I'm an "advanced" HLA user who
> actually finds a use and switches on the "-sym" option, even though
> that's only meant to be for your benefit in debugging :)...
That's a good point. Maybe I will do something about this today.
Cheers,
Randy Hyde
The Half A Wanna Bee
> > > I am regretting it too. Since then we would maybe have a REAL
alternative.
> >
> > Actually, it's a good idea Bill swiped that stuff. Else we'd all be
doing DOS
> > still rather than using an OS ripped from from Apple (ripped off from
Xerox).
> > Of course, we'd all be hating *NIX today, because that's the direction
MS
> > was headed before the Windows push came along. I.e., had Bill not stolen
> > Apple's ideas, there would be no Linux today (as Microsoft would have
> > covered those bases).
>
> What makes you think that Linus would have had less disdain for
> Xenix 3.11 for Workgroups than he did for Minix?
>
> Phil
FYI, I didnt post that. The post Randy replied too, was a mixup of two
posts. Mine was in reply to Beths. After sending it, I checked to see if it
reached the server. I couldnt find it, so I thought I done something wrong.
I raised my shoulders, good thing too, I thought, how many times have I not
regretted sending a reply out of some fire up my ass ?. So I thought it
wasnt here anymore, that it just wannished. I was ok. Then Randy reply to a
posting, where it looks like Beths writing and mine is from the same
original post, and it appears that it was I who wrote everything. But it
wasnt. I wrote only the last part. The part you are replying to is actually
Beths creation. Confusing isnt it. Well auf wiedersehen (The only german I
seem to recall).
Frank Kotler
> The only problems I'd make a complaint about with HLA is actually on
> the "integration" side with other things...
And the "-v" switch is fairly useless without the "-test" switch... Okay
for Linux users, stderr redirects easily. In the Windows version, at
least, the "v" switch ought to imply "stdout", IMO. And it might be nice
to be able to get Fasm output with just one switch, not two...
> I'd Love to use HLA for
> adding assembly to some C++ programs and that sort of thing but, well,
> MASM spits out COFF while my Borland C++ linker only eats
> OMF...although, I've not tried the TASM option properly but I recall
> you mentioning that it's more specifically tailored for working with
> Delphi and wouldn't work otherwise...does FASM spit out the right
> stuff?
That's an interesting question! As you know, Nasm will produce both OMF
and COFF output. If Fasm does the same thing (I'd have to look it up),
that might expand the range of useable linkers.
If you've read the thread in comp.lang.asm.x86, you know that using Fasm
with HLA results in a larger .exe than Masm (in some cases, at least -
I'm using that skeletal "game" you posted as test code). Different
problem than the ".bss" problem you posted about, apparently. I've
edited the (F)asm file output by HLA - changing the "dummy to placate
linker" that HLA places in the .bss section (there's a "dummy" in .data,
too - for Fasm only, not for Masm) to a large value does *not* increase
the .exe size. So it *is* apparently doing .bss right. I think I've got
two .text sections! (curiously, the .obj produced by Fasm is smaller
than Masm's! ...might be a clue there...)
I may look into this some more, but as I'm not a regular user of either
HLA or Fasm, I'm rather out of my depth. Some expertise with MSlink
would probably come in handy, too. I'm sure it's a solveable problem.
Best,
Frank
The Half A Wanna Bee
>
> "The Half A Wanna Bee" <Shaka...@hotmail.com> wrote in message
news:3f97f760$1...@news.broadpark.no...
> >
> > Randy. I tried to order your book. But is it impossible to order it
without
> > a Creditcard ? I hate creditcards and I allways pay on delivery. Maybe I
> > could pay in advance ? I would never use a creditcard on the internet
even
> > if I had one. The first thing I did with my creditcard when they mailed
it
> > too me, was to break it in half and toss is into the trashbin. (To
protect
> > myself from myself) It never cost me a dime since then :-) Maybe I
should be
> > looking for it in the stores ? Maybe your book will be in Norwegian
stores
> > any time soon? Do you know ?
>
> Talk to the stores, the book is at the distributor so they can get it.
> As for sending a check, that's something you'd have to talk to the
> mail order outfit selling the book. That's one area, however, that
> neither I nor the publisher has any control over.
>
Yes. I guess my posting is a bit silly. But I know that I am not the only
one who doesnt like the thought of using creditcards via the internet. But
it seems to be the most frequent form of payment used? (I am an internett
newbie) Some other company I use, send a E-Mail you print out and can take
to the bank and pay in advance. This seem a better option. If YOU dont have
any control over those people who are marketing your book, I can tell you
right away that I certainly do not. I have tried to email Angelfire about a
similiar request several times. But I guess they have a robot doing their
homepage, while they sit tight in the cafeteria laughing their head off
while careless people keep pumping money into their bankaccount. They never
ever give any feedback. So maybe you should tip them. If they listen to
anyone, it should be you.
I mean every word I said about you book. Its awsome, and I would be willing
to bet that Betov has read it too, nowmatter how much he refuses to admit
it. If he has not, he should run, not walk to get hold of a copy before its
to late. Thats what I am doing and thats why I posted this mail here.
Randall Hyde
try the -o:omf option.
I use HLA with Borland's C++ all the time...
HLA is compiled with BCC32, for example
Cheers,
Randy Hyde
Betov
@newsfep3-gui.server.ntli.net:
> ...
>
> I get the general gist of what you're doing - which is nothing
> like what Rene seems to think it is - and that's cool...especially
> because, despite what Rene implies, you started this all without any
> sort of "reward" except "satisified customers" and have had to put up
> with your fair share of crap for just trying to help by providing what
> is a very powerful assembly language...what was it that someone else
> once said: "you're an ASM angel!" ;)
>
> Actually, ironically, because Rene's been spouting off against HLA
> recently, I've been actually using it _more_ lately (the "Barnum"
> effect...plus, I'm sorely tempted to start spamming the group with HLA
> code, just to also piss off Rene a bit...although, in the interests of
> fariness, I would later convert them to RosAsm...
>
> ...
Usually, people have some difficulties to be both completely
stupid and intelligent, and, in case you would be a counter
example, be sure that i would never publish any of your works,
as the main reason why i made this switch from SpAsm to RosAsm,
was exactely to save me from such demential compromission cases.
Betov.
Beth
> Beth,
> try the -o:omf option.
> I use HLA with Borland's C++ all the time...
> HLA is compiled with BCC32, for example
Okay, will do...although, I _did_ try this out a long time ago and it
didn't work...perhaps whatever the problem was has been fixed,
though...I never really did look into it at the time because I wasn't
interested in linking it to any Borland C++ code...it could be that I
have a really old Borland linker (v4.52, the first one able to handle
PE files ;) built into the IDE thingy and maybe it's not a HLA problem
but a problem with this older thingy not being able to read the OMF
properly or something like that...anyway, I also have v5.5 from
Borland's "freebie compiler" offer and could try it with that if it
still is failing with v4.5...
Ah, I use all "freebie" tools (downloaded, off magazine cover discs,
etc. :) so there's often a lot of playing around that needs to be
done...to be honest, straying into the other thread around here, that
actually tends to be what you pay for with the commercial stuff...as I
can usually do anything that could be done with some other commercial
thing, it's just that it's nowhere near as "convenient" to do
so...it's often the case that it's not about paying for some feature
that can't be got with other free tools but that the commercial tool
has got it all "super-integrated" and "convenient" and stuff into some
whizz-bang IDE...while, on the other hand, GCC will certainly do it
but it's all playing around with command lines and tools and makefiles
instead of clicking a few buttons in an IDE...sometimes, that sort of
thing certainly is worth paying for...but, also, sometimes, it's just
an outright con because, say, using "MAKE" will be just as quick and
convenient - but a whole lot _more flexible_, in fact - even if it
don't look all "pretty" or anything as it does the work :)...
Anyway, as long as it's possible then I know I'm not wasting my time
trying to make it work, so it's worth making the effort to find out
how it all works properly :)
Beth :)
Beth
> Usually, people have some difficulties to be both completely
> stupid and intelligent, and, in case you would be a counter
> example, be sure that i would never publish any of your works,
> as the main reason why i made this switch from SpAsm to RosAsm,
> was exactely to save me from such demential compromission cases.
There's also a kind of "intelligence" not often acknowledged...the
kind that has the sense not to bang their head repeatedly against the
wall, merely "for ideal theory's sake"...being able to "get over" that
some things aren't going to go the way you want necessarily...and
_adapting_ to deal with that reality...such "instant adaption" is what
makes human intelligence so useful...rather than wait for a thousand
years of children jumping into fires for "evolution" to finally change
the genetics so as to make it "instinctual" not to do so, intelligence
allows their mother to say "hey, don't do that!" and, hey presto,
"instant evolution"...that, in some ways, is closer to "intelligence"
than what you're actually usually referring to, which tends to
actually be better described as "knowledge" and is more memory-related
than intelligence-related (though, true, these two go hand-in-hand so
much that it's difficult to be drawing any simple lines between the
two :)...
In your case, you made the switch to "exactely [sic] to save me from
such demential compromission cases"...indeed...but, simply, IT ISN'T
WORKING...and unless you "adapt" in some way, it never will work...
You're caught between two states here...you want to work towards this
"ideal" - which is great and I share your sentiments _entirely_ on
those sorts of things - but, also, you want to be "compatible" and
"useful" and "practical"...the rock of practice and the hard place of
theory is where you're stuck between...
Because, you see, with, say, wolfgang, he's made the choice to
"detach" from the practice is can't stand (Windoze, namely ;) and is
"whole hog" from top to bottom with his own ways of doing things...and
that's great and that's valid...he's got his own little world where
everything works as he wants it to and that's brilliant...
The problem is that you sort of want something like wolfgang's world
but to still use Microsoft PE files and have "code re-use" and OpenGL
and that sort of thing...you're trying to blend two basically
incompatible world together...and, sorry, that implicitly means a
"compromission case" or two...you _could_ be that strict and rigid if
you went wolfgang's way and started totally from scratch with your own
OS and so forth...but in this "half-way" place, you can't shout at
Microsoft (well, you can but they won't listen) to improve PE files in
some great "ideal" way...but you also can't simply give up PE files
and use your own format which has absolutely NO "compromission cases"
in it at all because you're going to create it from scratch _without_
any such things...
Logically, the only way to get what you seek is for the whole world to
fall in line with your thinking so that they are never going to
present you with any "compromission cases"...the likelihood of your
success in such a climate is nigh-on impossible...especailly because
people will simply ignore something that does not compromise to their
particular needs...
It's the essential political paradox...to change the system, you must
either tear it all down completely in "revolution"...or you must
become a _part of it_, in order to slowly and progressively
"influence" it towards your "ideal"...either way, to change the
system, you must either become a part of it or you must become _all of
it_ as you become the "alternative" when the current system is utterly
destroyed in "revolution"...you could try "anarchy" but I think you'll
find it's a political system with a 100% failure rate..."anarchy" is
actually the natural state of things when there is no system in
place...and, yet, without fail in 100% of cases, anarchy has failed in
practice because people have instituted "systems" of one sort or
another (even if only "social code" rather than "code of
laws"...although, "code of laws" really is just an extreme version of
"social code", anyway, because, as noted, "anarchy" _is_ the natural
default state and it's only because we co-operate with whatever
"system" is in place that the system works...if everyone was to
immediately go out and riot, refusing to obey laws then there would
effectively be no law and it would be anarchy...we're always sitting
on the verge of this at all times...it is only our "co-operation" and
"compromise" that means "the system" actually works)...
"Left-wing Anarchist" is an oxymoron, Rene...you can't be both
simultaneously and you have to choose one or the other...
Beth :)
The Half a Wannebee
re:s Hmm.
Beth
> Beth wrote:
> > The only problems I'd make a complaint about with HLA is actually
on
> > the "integration" side with other things...
>
> And the "-v" switch is fairly useless without the "-test" switch...
Okay
> for Linux users, stderr redirects easily. In the Windows version, at
> least, the "v" switch ought to imply "stdout", IMO.
Ah, yes...I think I mentioned this to Randy a while back too, didn't
I? Or, at least, I started writing a post where I intended to mention
this, which might still be sitting in the "Drafts" folder...anyway,
you're right about it outputting the messages to the wrong "stream"
because one thing I tried before was "HLA -v SomeProgam.hla >
SomeProgram.txt" so as to collect all the output into a text file with
redirection...except, oops, the file is blank, as the output isn't
being redirected by the ">" operator as you'd expect...I spotted this
a while ago...is it still doing that? Because I now just use the
"pause" command in a batch file instead and NT / XP's DOS box can be
set to have a big buffer so it remembers a few screens worth that you
can scroll through, which, if I recall correctly (which I might not
be), isn't so much of an option with Win9x, right? You know, tried it
once and it didn't work...found a different way to do it and haven't
tried the original way since to see if it's been fixed or not...
> And it might be nice
> to be able to get Fasm output with just one switch, not two...
Well, the whole interface thing with HLA could do with an
overhaul...but, in a sense, it _will_ have just such an overhaul...the
current HLA is, after all, just a "prototype" and v2.x won't be using
any other assembler at all...that's a "stop gap" solution just to get
HLA working for "prototype" purposes...one day, it should be an
_assembler_ rather than an "assembly compiler" (well, it'll still be a
"compiler" by Rene's definitions but then his definitions are
incredibly strict that, coincidentally, only RosAsm counts
properly...why, there's a coincidence for you! ;)...
> > I'd Love to use HLA for
> > adding assembly to some C++ programs and that sort of thing but,
well,
> > MASM spits out COFF while my Borland C++ linker only eats
> > OMF...although, I've not tried the TASM option properly but I
recall
> > you mentioning that it's more specifically tailored for working
with
> > Delphi and wouldn't work otherwise...does FASM spit out the right
> > stuff?
>
> That's an interesting question! As you know, Nasm will produce both
OMF
> and COFF output. If Fasm does the same thing (I'd have to look it
up),
> that might expand the range of useable linkers.
Cool :)
> If you've read the thread in comp.lang.asm.x86, you know that using
Fasm
> with HLA results in a larger .exe than Masm (in some cases, at
least -
> I'm using that skeletal "game" you posted as test code).
Nope, didn't know that, as I've not been out of this group to look at
CLAX for a while...
Also, what "skeletal game" did I post? And where did I post that? Oh,
wait...I've got you...the very "bare" code I posted up to demonstrate
my LINK program...that's not, of course, actually any sort of "game"
whatsoever...but, yes, it was intended to perhaps be something like
that in the end...confused myself - via you - there...it's hardly a
"game" but, yeah, I probably called it that, didn't I? As, initially,
that was my great idea for some HLA code example...the problem there,
of course, is that you either have to tackle horrible GDI or use
DirectX or something - as with HLA we're in Windows not DOS - which'll
lead to an "overkill" example that would actually be probably quite
useless to anyone else to read..."specific assembly" _and_ lots of
"jiggery pokery" with DirectX? It could be done but I'm thinking
better of it, as it wouldn't really be a useful post to make, other
than to perhaps annoy Rene that HLA can do "specific assembly"-like
things too, if you're willing to forsake the "HLL" stuff (as it really
is all "optional" rather than "mandatory"...switch it off and don't
use it then, really, HLA turns into an assembler like the others, just
using a very different syntax to everything else :)...
> Different
> problem than the ".bss" problem you posted about, apparently. I've
> edited the (F)asm file output by HLA - changing the "dummy to
placate
> linker" that HLA places in the .bss section (there's a "dummy" in
.data,
> too - for Fasm only, not for Masm) to a large value does *not*
increase
> the .exe size. So it *is* apparently doing .bss right. I think I've
got
> two .text sections! (curiously, the .obj produced by Fasm is smaller
> than Masm's! ...might be a clue there...)
All very curious...although, looking at the output of MASM when I had
my problems, then you might want to look closely at the
headers...because what I found with my problem was that MASM is
actually considering the ".bss" to be "initialised data" but is using
the ability to declare a "virtual size" for a section that's larger
than the actual on-disk size to do the allocation...
Whereas, there actually is a specific "size of uninitialised data"
field in the headers which MASM isn't putting anything but a big, fat
zero in...now, I'm not sure what difference this would make but
perhaps this difference you're seeing is because, at a guess, FASM
_is_ actually filling out this field (which would actually seem the
most logical thing to do with uninitialised data to put the values
into the "uninitialised data" fields ;)...while MASM is, instead,
taking a "BSS is part of DGROUP but only expands the 'virtual size' of
the section" (so, the BSS still gets a section all to itself, even if
it's all a case of no data but just a twiddle on the section's
"virtual size" :)...
This may also explain MASM's (well, LINK's) strange operation that
specifying an unusual "align" value suddenly means that the BSS stops
working properly (that is, suddenly starts taking up disk space to
store absolutely nothing)...perhaps what's happening here is simply
that the unusual "align" options are knocking MASM's "virtual size"
trick sideways...not exactly sure how this is happeing...but, to give
a completely uninformed guess just for illustration, MASM looks at
"BSS" as being tacked onto the end of "DGROUP"...due to the odd
alignment options, the location of "BSS" inside the "DGROUP" data
section is now not aligned to some useful 512 byte / 4K
boundary...and, thus, this is confusing LINK that's trying to package
"DATA + BSS" as one section with a "virtual size" that's larger than
merely the initialised data because it's starting "in the wrong place"
from its perspective and LINK instead spits out actual on-disk data
because this "virtual size" trick isn't working...
And then FASM, on the other hand, is actually doing more what you'd
expect - no "virtual size" tricks - and loading this figure into the
"size of uninitialised data" field and perhaps specifically creating a
"BSS" section (hence bigger EXE :) rather than just tacking it onto
the end of "DGROUP"...
Of course, the above is an absolute blind stab in the dark because I
haven't even looked at FASM yet to make any comments about what it's
doing...I just noticed that MASM isn't touching the COFF header's
"size of uninitialised data", which is logically the first place you'd
think it would fill out the BSS information...instead, from what I
could see in the headers, LINK's utilising a "virtual size" trick
(which, to be fair, probably is the cleverer option in the more
general case...to use "virtual size" to "virtually" expand the data
section with some uninitialised data, rather than actually create any
separate "BSS" sections itself :)...
Run some tool for looking at the headers with some FASM output to see
whether it actually touches the COFF header's "size of uninitialised
data"...as LINK, in all the tests I did, couldn't be persuaded to use
it with any set of options...my hypothesis could, of course, be
_wildly_ wrong here, as it's a pure guess from looking at LINK's
output alone (wondering how FASM's could be different to get different
results for the same thing :)...but, well, that's how all scientific
hypothesis start life as "pure guesswork", even if some scientists
would rather not call it that because it sounds so "unscientific"
;)...
MS's use and interpretation of COFF is dubious in many places...this
attempt to avoid the "official" COFF fields for uninitialised data -
even if this does actually end up producing smaller EXEs when you
aren't playing funny tricks with "align" like I was - can be looked at
as one more place where they aren't being 100% "COFF in spirit", using
"tricks" to go around the official expected way it should work...but
at least this method isn't strictly "incompatible" like the other
outright "different interpretation" mistake they made...actually,
thinking about it, is "virtual size of section" strictly part of the
COFF stuff or is this one of their "NT specific fields" that they've
added?
Sorry...I'd rather not be suspicious of MS...but, as we increasingly
see, they always give good cause for people to be suspicious...is this
another example of "decommoditizing", where they delibrately "MS-ify"
a common standard because Bill's ego can't handle having anything
"open" and not under his control?? Nah, probably overly paranoid
there...but, as I say, it's not because I want to be overly paranoid
about MS...it's because MS are always actually doing this sort of
thing that thinking ill of them first tends to be the closest to the
truth...as Stalin once said: "Just because you're paranoid, doesn't
mean they aren't out to get you" ;)...
> I may look into this some more, but as I'm not a regular user of
either
> HLA or Fasm, I'm rather out of my depth. Some expertise with MSlink
> would probably come in handy, too. I'm sure it's a solveable
problem.
Yeah, totally...anyway, I've given you one "line of enquiry",
anyway...might be totally barking up the wrong tree, of course...and
it wouldn't be the first time...but it's somewhere to start looking
(well, the most obvious thing to do - which'll cover this and
everything else - is to assemble the same program, which displays
these "differences" between tools and then look at the actual output
fields and sections and things with some "dump" type tool...whatever
is "different" must surely be clear by comparing the two outputs which
have different properties...something inside them is making them
behave differently, anyway ;)...
Beth :)
P.S. I took a radical "let's not bother with BSS at all" approach in
the end with the "very uncompleted and unfinished" example code you
were talking about above...
Right, pardon the messy state of the code...it's "specific assembly",
you see, so this is what things in the Win32 world tend to look like
when you give up "HLLisms" and work "to the bone" like with DOS
(actually, think yourself lucky...as it will be even worse once it's
completed...for example, the message table will be put into order so
that a binary search can be used...and a whole lot more "jumping into
the middle of a procedure" and "indexing off ESP directly, counting up
bytes" and other ugly, unreadable stuff :)...as well as not being
finished (nor is it working properly, as I was trying to use the
WM_NCCALCSIZE message to have a non-standard non-client area
shape...but I've done something wrong somewhere ;) - although it
should execute...it just doesn't do anything impressive but slap up an
uninteresting non-rectangular "blob" on the screen for a window that
you can drag around (note that you have to tap ALT + F4 to quit the
program, as the "close" button has disappeared...that was something to
be implemented later, as I created my own "non-client" area...which
also explains all the "non-client" window messages in the message
table thingy, as I was going to be filling those out with stuff next
to create a groovy graphical border to the "game" rather than the
boring Windows thing ;)...
It also carries its own Windows stuff just to make sure that it's all
"self-contained" and that, yeah, I leave open the option for nasty
"tricks" that Randy's Windows header files might not like seeing done
;)...
HLA BEGINNER WARNING: This code is NOT meant to be any sort of "good
example"...in fact, it's supposed to be a bit of a "bad example"
almost...a demonstration that, yes, HLA _can_ do "specific 'raw'
assembly" stuff but that it ends up creating messy code like
below...although, like all such code, it's not particularly designed
to be read or anything...if you have trouble following it then,
actually, "well done"...as most normal HLA code shouldn't really be
looking like this, anyway...as I say, strictly just to demonstrate
that it's _possible_, not that it's necessarily a good idea :)
EVERYONE ELSE WARNING: Don't judge too harshly...it's delibrately
"specific" with nasty tricks in it...also, yes, I _DO_ know that I
could combine the two "add esp" and "sub esp" commands into one and
other sorts of "optimisations" (for example, the "GetMessage" could
actually be kicked out and "PeekMessage" used to do the whole
job...this is a planned change coming soon ;)...it's still a "work in
progress" so things like this are _delibrately_ NOT yet combined or
optimised, until I get much more of the code working that I know what
I've got won't need much changing to "lock it down" as very "specific"
and "optimised" code...well, it has to stay partially "readable" so I
can write it, after all ;)...
-------------------------- >8 ------------------------
unit Example;
// switch off HLA's stack frame stuff...
//
// and, yes, using "unit" and these two
// lines below is all that's needed to
// switch it _ALL_ off for the entire length
// of the source file...and, yes, you've
// got to ask yourself why everyone makes
// such a fuss about HLA's generation when
// it's so easily switched off...
//
?@noframe := true;
?@nodisplay := true;
// like "public main" in other assemblers...making the
// entry point visible (but, also, using the HLA thing
// of being able to use an "alias" inside the file,
// different to its real "outside" name, as seen by the
// linker :)...
//
procedure Main; @external("_HLAMain");
// this is our "extern" section for defining links to
// the Windows API used...would be a bunch of "extern"
// or "proto" statements in some other assembler :)
//
static
GetModuleHandleA: procedure;
@external("__imp__GetModuleHandleA@4");
LoadCursorA: procedure;
@external("__imp__LoadCursorA@8");
RegisterClassExA: procedure;
@external("__imp__RegisterClassExA@4");
CreateWindowExA: procedure;
@external("__imp__CreateWindowExA@48");
DestroyWindow: procedure;
@external("__imp__DestroyWindow@4");
ShowWindow: procedure;
@external("__imp__ShowWindow@8");
UpdateWindow: procedure;
@external("__imp__UpdateWindow@4");
PeekMessageA: procedure;
@external("__imp__PeekMessageA@20");
GetMessageA: procedure;
@external("__imp__GetMessageA@16");
TranslateMessage: procedure;
@external("__imp__TranslateMessage@4");
DispatchMessageA: procedure;
@external("__imp__DispatchMessageA@4");
WaitMessage: procedure;
@external("__imp__WaitMessage@0");
ExitProcess: procedure;
@external("__imp__ExitProcess@4");
DefWindowProcA: procedure;
@external("__imp__DefWindowProcA@16");
PostQuitMessage: procedure;
@external("__imp__PostQuitMessage@4");
CreateRoundRectRgn: procedure;
@external("__imp__CreateRoundRectRgn@24");
SetWindowRgn: procedure;
@external("__imp__SetWindowRgn@12");
GetWindowDC: procedure;
@external("__imp__GetWindowDC@4");
ReleaseDC: procedure; @external("__imp__ReleaseDC@8");
endstatic;
// Constant section; basically, everything in this section
// is just an "EQU" for all Windows constants used...
//
const
FALSE := $00000000;
TRUE := $00000001;
IDC_ARROW := $00007F00;
COLOR_3DFACE := $0000000F;
WS_OVERLAPPED := $00000000;
WS_CAPTION := $00C00000;
WS_SYSMENU := $00080000;
WS_MINIMIZEBOX := $00020000;
WS_OVERLAPPEDWINDOW := WS_OVERLAPPED | WS_CAPTION |
WS_SYSMENU | WS_MINIMIZEBOX;
CW_USEDEFAULT := $80000000;
HWND_DESKTOP := $00000000;
SW_SHOWNORMAL := $00000001;
PM_NOREMOVE := $00000000;
WM_CREATE := $00000001;
WM_DESTROY := $00000002;
WM_PAINT := $0000000F;
WM_QUIT := $00000012;
WM_ERASEBKGND := $00000014;
WM_NCCREATE := $00000081;
WM_NCDESTROY := $00000082;
WM_NCCALCSIZE := $00000083;
WM_NCHITTEST := $00000084;
WM_NCPAINT := $00000085;
WM_NCACTIVATE := $00000086;
WM_NCMOUSEMOVE := $000000A0;
WVR_VALIDRECTS := $00000400;
HTCAPTION := 2;
WindowWidth := 480;
WindowHeight := 320;
endconst;
// Actual code; Don't be fooled by "procedure Main" as
// _nothing_ is generated for the procedure but what
// you specifically see in the code...in this context,
// the "procedure" is actually acting like a code section
// wrapper only (you know, "_text segment" / "_text ends" ;)...
//
// Note, there are no other sections because the program's
// initialised data is delibrately thrown into the code
// section and the stack alone provides us writeable data
// (although, there's NO use of EBP in the code so following
// the stack is no fun...in fact, I might indeed have messed
// up counting those bytes or something...anyway, if I have,
// it's not in any "fatal" way that stops it running ;)...
//
procedure Main;
begin Main;
sub (48, esp);
cld ();
mov (&MainWndClass, esi);
mov (esp, edi);
mov (12, ecx);
rep.movsd();
pushd (0);
call (GetModuleHandleA);
mov (eax, ebx);
mov (ebx, [ esp + 20 ]);
pushd (IDC_ARROW);
pushd (0);
call (LoadCursorA);
mov (eax, [ esp + 28 ]);
pushd (esp);
call (RegisterClassExA);
add (48, esp);
cmp (eax, 0);
je Terminate;
pushd (0);
pushd (ebx);
pushd (0);
pushd (HWND_DESKTOP);
pushd (WindowHeight);
pushd (WindowWidth);
pushd (CW_USEDEFAULT);
pushd (CW_USEDEFAULT);
pushd (WS_OVERLAPPEDWINDOW);
pushd (0);
pushd (&ClassName);
pushd (0);
call (CreateWindowExA);
cmp (eax, 0);
je Terminate;
mov (eax, ebx);
pushd (SW_SHOWNORMAL);
pushd (ebx);
call (ShowWindow);
pushd (ebx);
call (UpdateWindow);
sub (28, esp);
MsgLoop:
pushd (PM_NOREMOVE);
pushd (0);
pushd (0);
pushd (0);
lea (ebx, [ esp + 16 ]);
pushd (ebx);
call (PeekMessageA);
cmp (eax, 0);
je NoMessage;
pushd (0);
pushd (0);
pushd (0);
pushd (ebx);
call (GetMessageA);
cmp (eax, 0);
je ExitProgram;
pushd (ebx);
call (TranslateMessage);
pushd (ebx);
call (DispatchMessageA);
NoMessage:
call (WaitMessage);
jmp MsgLoop;
ExitProgram:
mov ([ esp + 8 ], eax);
add (28, esp);
Terminate:
pushd (eax);
call (ExitProcess);
align(4);
WndProc:
mov (&MsgTable, edx);
sub (8, edx);
NextMsg:
add (8, edx);
mov ([ edx ], eax);
cmp (eax, 0);
je DefProcessing;
cmp ([ esp + 8 ], eax);
jne NextMsg;
jmp ([ edx + 4 ]);
DefProcessing:
pushd ([ esp + 16 ]);
pushd ([ esp + 16 ]);
pushd ([ esp + 16 ]);
pushd ([ esp + 16 ]);
call (DefWindowProcA);
ret (16);
align (4);
CreateProc:
xor (eax, eax);
ret (16);
align (4);
DestroyProc:
pushd (0);
call (PostQuitMessage);
xor (eax, eax);
ret (16);
align (4);
PaintProc:
xor (eax, eax);
ret (16);
align (4);
NcCreateProc:
pushd (24);
pushd (24);
pushd (WindowHeight);
pushd (WindowWidth);
pushd (0);
pushd (0);
call (CreateRoundRectRgn);
pushd (FALSE);
pushd (eax);
pushd ([ esp + 12 ]);
call (SetWindowRgn);
mov (TRUE, eax);
ret (16);
align (4);
NcDestroyProc:
xor (eax, eax);
ret (16);
align (4);
NcCalcSizeProc:
cmp ((type dword [ esp + 12 ]), FALSE);
je NoValidRect;
mov ([ esp + 16 ], ebx);
mov ([ ebx ], eax);
mov (eax, [ ebx + 16 ]);
add (8, eax);
mov (eax, [ ebx + 32 ]);
mov ([ ebx + 4 ], eax);
mov (eax, [ ebx + 20 ]);
add (24, eax);
mov (eax, [ ebx + 36 ]);
mov ([ ebx + 8 ], eax);
mov (eax, [ ebx + 24 ]);
sub (16, eax);
mov (eax, [ ebx + 40 ]);
mov ([ ebx + 12 ], eax);
mov (eax, [ ebx + 28 ]);
sub (32, eax);
mov (eax, [ ebx + 44 ]);
mov (WVR_VALIDRECTS, eax);
jmp EndOfNcCalcSizeProc;
NoValidRect:
xor (eax, eax);
EndOfNcCalcSizeProc:
ret (16);
align (4);
NcHitTestProc:
mov (HTCAPTION, eax);
ret (16);
align (4);
NcPaintProc:
xor (eax, eax);
ret (16);
align (4);
NcActivateProc:
xor (eax, eax);
ret (16);
// *** Data ***
// (Read-only data, as we're still in the code section)
align (4);
MainWndClass:
dword 48;
dword NULL;
dword &WndProc;
dword NULL;
dword NULL;
dword NULL;
dword NULL;
dword NULL;
dword COLOR_3DFACE + 1;
dword NULL;
dword &ClassName;
dword NULL;
MsgTable:
dword WM_CREATE, &CreateProc;
dword WM_DESTROY, &DestroyProc;
dword WM_PAINT, &PaintProc;
dword WM_NCCREATE, &NcCreateProc;
dword WM_NCDESTROY, &NcDestroyProc;
dword WM_NCCALCSIZE, &NcCalcSizeProc;
dword WM_NCHITTEST, &NcHitTestProc;
dword WM_NCPAINT, &NcPaintProc;
EndOfMsgTable:
dword WM_NCACTIVATE, &NcActivateProc;
ClassName: byte "Example", 0;
end Main;
end Example;
-------------------------- 8< ------------------------
Assemble with HLA and MASM (Windows only because it's being "specific"
;) and feel free to play with LINK's "response file" in order to
squeeze it down...about 1.5KB is the size I got the EXE down to
myself...although, only 500 or so bytes of this is actually the actual
code and data it really needs...the old wasteful PE file format for
you there ;)...
You will be severely _unimpressed_ by what it actually does on the
screen, mind you...a grey irregular "blob" that you can drag around
with the mouse...when finished, the idea is that this "blob" would
actually have a whole "non-standard" interface look to it, like one of
the many media player things out there which also have odd window
shapes and their own buttons and things...
Oh, and, of course, credit where credit's due...rounded corners on
window (C)1984 Apple...I ain't no Bill, I'll admit where I stole my
ideas...hehehe ;)
Frank Kotler
> you're right about it outputting the messages to the wrong "stream"
> because one thing I tried before was "HLA -v SomeProgam.hla >
> SomeProgram.txt" so as to collect all the output into a text file with
> redirection...except, oops, the file is blank, as the output isn't
> being redirected by the ">" operator as you'd expect...I spotted this
> a while ago...is it still doing that?
Last version I tried, yes (Randy's gettin' ahead of me). But the "-test"
switch causes it to use stdout instead of stderr, so there's an easy
workaround, "-v -test". (Nasm uses the "-s" switch to put error messages
on stdout...)
> Well, the whole interface thing with HLA could do with an
> overhaul...but, in a sense, it _will_ have just such an overhaul...
That's why I mention it...
>>>I'd Love to use HLA for
>>>adding assembly to some C++ programs and that sort of thing but,
>>> well,
>>>MASM spits out COFF while my Borland C++ linker only eats
>>>OMF...
As Randy's reminds us, Masm *will* do OMF if you ask it to - and HLA has
the mechanism to pass the request on, apparently. I still haven't looked
into what Fasm's capabilities are.
>>If you've read the thread in comp.lang.asm.x86, you know that using
>> Fasm
>>with HLA results in a larger .exe than Masm (in some cases, at
>> least -
>>I'm using that skeletal "game" you posted as test code).
>
> Nope, didn't know that, as I've not been out of this group to look at
> CLAX for a while...
"HLA and FASM/MASM" started by John Guillory - turns out it's a
different problem, apparently(?).
> Also, what "skeletal game" did I post? And where did I post that? Oh,
> wait...I've got you...the very "bare" code I posted up to demonstrate
> my LINK program...
No, this was some code you posted when Paul Panks was asking about a bug
in his text adventure game (it was an array-indexing problem - I think
HLA looks so high-level that Paul expected it to do pointer arithmetic
:) You posted a "text adventure" - only a few rooms - to demonstrate an
alternative method to using "stdout.put" for every single line of text :)
No graphics - very different code from this...
> It could be done but I'm thinking
> better of it, as it wouldn't really be a useful post to make, other
> than to perhaps annoy Rene that HLA can do "specific assembly"-like
> things too,
I've thought of writing a "raw" example for HLA - probably for Linux
(specifically) so I can put parameters in registers and do int 80h so
it'll "look like real assembly". (Pointless otherwise - what int 80h
does with your parameters doesn't bear thinking about!) But not to annoy
Rene - he's annoyed enough without my help. Just to "see if I can do it".
> All very curious...although, looking at the output of MASM when I had
> my problems, then you might want to look closely at the
> headers...because what I found with my problem was that MASM is
> actually considering the ".bss" to be "initialised data" but is using
> the ability to declare a "virtual size" for a section that's larger
> than the actual on-disk size to do the allocation...
I think the Fasm "problem" is something different, but this is an
interesting subject, too. Well, not "interesting" (to me, at least), but
I fear I'm going to have to learn more about it than I care to. There's
an issue with Nasm's "-f win32" output and the Mingw/Cygwin binutils,
apparently. I *think* the story is that the binutils guys are trying to
do it according to the spec, and what MS does is different - has to do
with those "data size" and "virtual size" fields - they differ between
the .obj format and the .exe format, and *somebody's* got it wrong. Nasm
can implement still another COFF variant to fix it, if need be (we've
got code for it - thanks to Charles Bilyue'! - anyone needing that?)
I'll have to find a good "objdump" tool. Right now when I type "objdump"
I get the djgpp version (which might be close enough, but I don't trust
it to do PECOFF right). I've probably got something, just have to find
it... Cygwin's objdump oughtta work...
> P.S. I took a radical "let's not bother with BSS at all" approach in
> the end with the "very uncompleted and unfinished" example code you
> were talking about above...
Different code, actually, but...
> ...if you have trouble following it then,
> actually, "well done"...
Perhaps predictably, I rather *like* that coding style!
> DefProcessing:
> pushd ([ esp + 16 ]);
> pushd ([ esp + 16 ]);
> pushd ([ esp + 16 ]);
> pushd ([ esp + 16 ]);
> call (DefWindowProcA);
Did you look at "Guillermito's Particles"? A link was posted to it here
a while ago. I've been "translating" it to Nasm (written for Tasm). He
uses an odd trick... upon entering "WndProc" he "pop [addresse_retour]".
I couldn't imagine why, until I got here - it allows him to call
DefWindowProc with the stack as it is. "push [addresse_retour]" before
returning, of course. Since you're into "dirty tricks" with this code, I
thought I'd mention it... (come to think of it, how the hell does that
work? wouldn't you "ret N" twice? must look at that again... ah, okay,
he just does a straight "ret" from WndProc...))
Best,
Frank
Beth
> Beth wrote:
> > you're right about it outputting the messages to the wrong
"stream"
> > because one thing I tried before was "HLA -v SomeProgam.hla >
> > SomeProgram.txt" so as to collect all the output into a text file
with
> > redirection...except, oops, the file is blank, as the output isn't
> > being redirected by the ">" operator as you'd expect...I spotted
this
> > a while ago...is it still doing that?
>
> Last version I tried, yes (Randy's gettin' ahead of me). But the
"-test"
> switch causes it to use stdout instead of stderr, so there's an easy
> workaround, "-v -test". (Nasm uses the "-s" switch to put error
messages
> on stdout...)
Ah, good point...a bit weird that Randy was sending it to the wrong
"stream" in the first place...but, hey, as long as there's a
workaround switch :)
> > Well, the whole interface thing with HLA could do with an
> > overhaul...but, in a sense, it _will_ have just such an
overhaul...
>
> That's why I mention it...
Ah, yes...good point...get the complaints and suggestions in now so as
to make sure Randy knows to get them "fixed" for v2.x :)
> >>>I'd Love to use HLA for
> >>>adding assembly to some C++ programs and that sort of thing but,
> >>> well,
> >>>MASM spits out COFF while my Borland C++ linker only eats
> >>>OMF...
>
> As Randy's reminds us, Masm *will* do OMF if you ask it to - and HLA
has
> the mechanism to pass the request on, apparently.
Yes, I'm already passing through "/Fl" with "-aFl" in order to get
MASM to spit out a listing file (have I mentioned how much I like
listing files? Hmmm, probably ;)...
As I say, I did try this out ages back and it didn't work at that
time...but perhaps it was something that's now fixed...it _should_ be
perfectly possible, as Randy himself uses Borland C++ too...it's
probably either that an earlier version had a "bug" or something...or
it's an "issue" on the Borland C++ end because the compiler I usually
use - because it comes with a useful IDE - isn't the latest or
greatest they've produced...
Or maybe I just made a really stupid mistake...anyway, tried it ages
back and it didn't work so I simply did things in a different way as a
"workaround"...and, umm, because I've been doing that, I have
re-attempted the "experiment" lately...but if Randy's saying that it
should be working then, clearly, it's worth another go :)
> I still haven't looked
> into what Fasm's capabilities are.
I still haven't downloaded it...no, it's purely just not getting
around to it...in fact, that's it...I'm doing it _right now_ or I'll
just forget...give me five minutes...
Right, there...that was relatively painless...should have done that
ages ago ;)
> >>If you've read the thread in comp.lang.asm.x86, you know that
using
> >> Fasm
> >>with HLA results in a larger .exe than Masm (in some cases, at
> >> least -
> >>I'm using that skeletal "game" you posted as test code).
> >
> > Nope, didn't know that, as I've not been out of this group to look
at
> > CLAX for a while...
>
> "HLA and FASM/MASM" started by John Guillory - turns out it's a
> different problem, apparently(?).
Oh...
> > Also, what "skeletal game" did I post? And where did I post that?
Oh,
> > wait...I've got you...the very "bare" code I posted up to
demonstrate
> > my LINK program...
>
> No, this was some code you posted when Paul Panks was asking about a
bug
> in his text adventure game (it was an array-indexing problem - I
think
> HLA looks so high-level that Paul expected it to do pointer
arithmetic
> :) You posted a "text adventure" - only a few rooms - to demonstrate
an
> alternative method to using "stdout.put" for every single line of
text :)
Ah, I remember that "game" now...yes, the one where you can't actually
do anything but wander around aimlessly in about five rooms or
something tiny like that...although, of course, the whole point of the
example was to demonstrate an "expandable" way to go about programming
an adventure game...so, it's quite easy to add new rooms or change the
current ones and stuff...all it needs, really, is a few similar
data-centric systems for items, characters, puzzles and other
"independent" things in the game...and, well, it might even manage to
be fun for the player :)
> No graphics - very different code from this...
Yes, quite right...I know which code you're talking about
now...absolutely nothing to do with the code I posted here...oh
well...it's something different to use (although, this code is
"Windows only" because it uses the Win32 API directly :)...
> > It could be done but I'm thinking
> > better of it, as it wouldn't really be a useful post to make,
other
> > than to perhaps annoy Rene that HLA can do "specific
assembly"-like
> > things too,
>
> I've thought of writing a "raw" example for HLA - probably for Linux
> (specifically) so I can put parameters in registers and do int 80h
so
> it'll "look like real assembly". (Pointless otherwise - what int 80h
> does with your parameters doesn't bear thinking about!)
[ Probably a damn sight _less_ things than Windows does with one of
their API calls...have we added the fact that Rene's "specific
assembly" is just programming the "HLL" that Win32 has now effectively
become onto the list of contradictions? ;) ]
> But not to annoy
> Rene - he's annoyed enough without my help. Just to "see if I can do
it".
Yeah, well...I thought better of that too...he's backed himself into a
sticky enough corner without making it worse for no particular
reason...that would just be being nasty...
I suppose I was also "seeing if it could be done" but I had no real
doubts about that...looking at the formulation of HLA, I couldn't see
anything that would prohibit it...so, it was also a "test" of whether
it could be done but I had no doubts that it could because HLA allows
raw data and all the machine instructions and "naked" procedures, so
there shouldn't have been anything to cause problems...
> > All very curious...although, looking at the output of MASM when I
had
> > my problems, then you might want to look closely at the
> > headers...because what I found with my problem was that MASM is
> > actually considering the ".bss" to be "initialised data" but is
using
> > the ability to declare a "virtual size" for a section that's
larger
> > than the actual on-disk size to do the allocation...
>
> I think the Fasm "problem" is something different,
...probably...as I warned, I was just waffling on after seeing
something in MASM's output that was interesting...
> but this is an
> interesting subject, too. Well, not "interesting" (to me, at least),
but
> I fear I'm going to have to learn more about it than I care to.
Oh dear! :\
> There's
> an issue with Nasm's "-f win32" output and the Mingw/Cygwin
binutils,
> apparently. I *think* the story is that the binutils guys are trying
to
> do it according to the spec, and what MS does is different - has to
do
> with those "data size" and "virtual size" fields - they differ
between
> the .obj format and the .exe format, and *somebody's* got it wrong.
Nasm
> can implement still another COFF variant to fix it, if need be
(we've
> got code for it - thanks to Charles Bilyue'! - anyone needing that?)
Yeah, sounds like the thing that I discovered in LINK's output,
alright...it doesn't use the the "obvious" fields but, instead, plays
tricks with "virtual size"...to be fair, those tricks should actually
end up smaller in the general case...but if there's some utility
that's expecting it in a more COFF-like way - where the fields are
actually used rather than fudged around - then they could be in for a
surprise looking at LINK's output...
> I'll have to find a good "objdump" tool. Right now when I type
"objdump"
> I get the djgpp version (which might be close enough, but I don't
trust
> it to do PECOFF right). I've probably got something, just have to
find
> it... Cygwin's objdump oughtta work...
Hey, write your own that handles all of NASM's output formats...call
it "NDUMP" and then throw it into the NASM package, along with the
disassembler...
Well, okay...maybe not ;)
> > P.S. I took a radical "let's not bother with BSS at all" approach
in
> > the end with the "very uncompleted and unfinished" example code
you
> > were talking about above...
>
> Different code, actually, but...
Yup; But the original description was a bit "vague"...I mean, if you'd
said "adventure game" - or the more politically correct "interactive
fiction", as it likes to be known these days - then I'd have twigged
what you were talking about immediately...
> > ...if you have trouble following it then,
> > actually, "well done"...
>
> Perhaps predictably, I rather *like* that coding style!
Ah, good point...it's heading towards the NASM "bare bones" spirit,
isn't it? Well, now you know that if someone tries the "you can't
write things like this in HLA's 'Pascal' HLL syntax" then you're
reading a "phantom book review" from someone who hasn't actually tried
it out...dumb thing about these "phantom book reviews" too: Because I
have tried it out, I'm actually in a position to make _valid_
criticism of HLA with any faults it does have...everyone else can sort
of shouting angrily in its direction, which isn't going to work very
well now, is it? While because I bothered to look, I can hit Randy
with the odd nasty issue which he can't really defend..."Isn't case
neutrality getting in the way of the data typing system here?" /
"Seeing as LINK and Windows allow me to set the code section as
writeable, shouldn't HLA not actually forbid 'write to code section'
instructions?" / etc....ironic, really, isn't it? If Rene hit Randy
with comments more along these lines because he'd spent five or ten
minutes actually coding some HLA then he could actually begin to make
things uncomfortable for Randy...but, as it is, he says something,
Randy shows that it's not true, he looks a bit silly and it happens
all over again and again...as the saying goes: "once is 'accident',
twice is 'a dumb mistake' but three times is just criminally
stupid"...you'd reckon Rene would spot that he's constantly scuppered
in his criticisms by them not actually being valid...so you'd think
he'd put two and two together that if he just "informs himself up" on
the subject to even a basic level then it's a fairer fight and Randy
can't just dismiss him so easily by just pointing out that his
description of HLA is basically just wrong...
You don't have to "like it" in any way...just like you're not
particularly interested in going through output formats with a
magnifying glass...but you do it just the once to get the basic
information you need and then it's out of your way with no need to do
it ever again...oh well...
> > DefProcessing:
> > pushd ([ esp + 16 ]);
> > pushd ([ esp + 16 ]);
> > pushd ([ esp + 16 ]);
> > pushd ([ esp + 16 ]);
> > call (DefWindowProcA);
>
> Did you look at "Guillermito's Particles"? A link was posted to it
here
> a while ago. I've been "translating" it to Nasm (written for Tasm).
He
> uses an odd trick... upon entering "WndProc" he "pop
[addresse_retour]".
> I couldn't imagine why, until I got here - it allows him to call
> DefWindowProc with the stack as it is. "push [addresse_retour]"
before
> returning, of course. Since you're into "dirty tricks" with this
code, I
> thought I'd mention it... (come to think of it, how the hell does
that
> work? wouldn't you "ret N" twice? must look at that again... ah,
okay,
> he just does a straight "ret" from WndProc...))
Ah, yes...that's a nice, simple one I just didn't think about...mind
you, the WndProc was going to be a lot more complicated than it is
there...that's a basic thing to get it to function so I can write the
other bits (everything in Windows depends on the whole "message queue"
stuff :)...it was already scheduled to be converted to a binary search
or hash table or something off the "message table" (as it is going to
handle its own "non-client area" and various other things, then the
message count will likely be high enough to justify the effort of
shaving off a bit with something more complex than a straight linear
search...also, messages come in a particular "order" from the
perspective of the program that we could even have a "moving message
table"...for example, multiple WndProcs for a "state machine" kind of
deal...at first, only WM_CREATE is important so there's a WndProc
primed specifically for that and immediately dumps anything that
isn't...in WM_CREATE, you re-wire the WndProc to a more complete
version...if there's different "parts" to your program, where
different messages are likely and dealt with differently, then you can
come up with some elaborate set of WndProcs that switch around like a
"state machine" kind of thing...
Although, top of the list, in my opinion, is to deal with any child
windows yourself in code...Windows message passing and API take an
absolute age and consume weirdly big amounts of memory keeping track
of a few rectangles somehow...but, for child windows, they are all
entirely within the borders and boundaries of your application's
window...so, strictly, these can all be dealt with directly in the
program code...there's opportunities there for optimisation
too...although, the "top level" window has to basically fit into the
Windows scheme in order to make sure it operates with the desktop
properly on all the different Windows versions (and all the different
options...like returning "HTCAPTION" from "WM_NCHITTEST" to tell
Windows "this bit is a window title bar" and letting it do all the
"rubber band box" or "show contents while dragging" nonsense :)...
No, the basic pattern is "take more of the responsibility into the
program and then hard-wire it to work as fast as possible"...and this
is where the full extents of Microsoft's "world domination" attitude
because clear...you _can't_...for example, one idea someone might
consider (especially if you've used X Windows, where this is perfectly
possible..."standard" even ;) is that you're just grabbing messages
off the message queue in the main message loop and then just pass this
straight back to Windows to "dispatch" to your window
procedure...like, why not process the message right there after
grabbing it off the queue? What is it with this "window procedure"
nonsense, anyway?
With X Windows, it does basically work that way...there's a message
queue and an API to grab messages off the queue...if you want to
structure it into one "procedure" per "window class" with a big switch
statement to branch off to all the different message handlers then
you're free to do that by simply coding it in that way...if you want
to handle an entire application inside some "main" function by dealing
with the messages as they come off the queue, you can do that too...
But you can't actually do this with Windows...superficially, it might
look like you can...just don't call "DispatchMessage" and process
things as you pull them off with "GetMessage"...just like similar code
in X Windows...but, nope, Windows' "control freakism" won't allow
this, in fact...because, for some messages, Windows sends them
directly to your "window procedure" without consultation...if you
don't have valid code sitting there, then you could be in for a
surprise...and, also, even if you fill it in with some sort of lone
"RET 16" instruction, then you'll find that some messages aren't
showing up on your message queue...Windows is pretty unique in this
"window class" / "window procedure" nonsense, forcing you into
structuring things in a very specific way...there's not really any
need for it either...just the original way that Microsoft half cobbled
together their Apple copy and now it's just stuck like that while
"compatibility" rules the roost...
Anyway, anyway...
Beth :)
Randall Hyde
>
> Ah, good point...a bit weird that Randy was sending it to the wrong
> "stream" in the first place...but, hey, as long as there's a
> workaround switch :)
Generally, error and diagnostic messages should go to the stderr
device. Considering that 90% of the time people don't need to actually
capture this output, but they *do* need to see it, stderr isn't so bad.
>
> > > All very curious...although, looking at the output of MASM when I
> had
> > > my problems, then you might want to look closely at the
> > > headers...because what I found with my problem was that MASM is
> > > actually considering the ".bss" to be "initialised data" but is
> using
> > > the ability to declare a "virtual size" for a section that's
> larger
> > > than the actual on-disk size to do the allocation...
> >
> > I think the Fasm "problem" is something different,
>
> ...probably...as I warned, I was just waffling on after seeing
> something in MASM's output that was interesting...
>
> > but this is an
> > interesting subject, too. Well, not "interesting" (to me, at least),
> but
> > I fear I'm going to have to learn more about it than I care to.
>
LINK (and most MS languages) like to keep sections on a 4K boundary.
This allows the loader to deal with each section using the high-performance
virtual memory subsystem rather than having to read stuff off the disk and
relocate it on the fly. IMO, a good use of wasted disk space. Those who
force the linker to pack the data in the EXE file pay a heavy performance
penalty for doing so.
>
> Yeah, sounds like the thing that I discovered in LINK's output,
> alright...it doesn't use the the "obvious" fields but, instead, plays
> tricks with "virtual size"...to be fair, those tricks should actually
> end up smaller in the general case...but if there's some utility
> that's expecting it in a more COFF-like way - where the fields are
> actually used rather than fudged around - then they could be in for a
> surprise looking at LINK's output...
See the above.
>
> Ah, good point...it's heading towards the NASM "bare bones" spirit,
> isn't it? Well, now you know that if someone tries the "you can't
> write things like this in HLA's 'Pascal' HLL syntax" then you're
> reading a "phantom book review" from someone who hasn't actually tried
> it out...dumb thing about these "phantom book reviews" too: Because I
> have tried it out, I'm actually in a position to make _valid_
> criticism of HLA with any faults it does have...everyone else can sort
> of shouting angrily in its direction, which isn't going to work very
> well now, is it? While because I bothered to look, I can hit Randy
> with the odd nasty issue which he can't really defend..."Isn't case
> neutrality getting in the way of the data typing system here?" /
> "Seeing as LINK and Windows allow me to set the code section as
> writeable, shouldn't HLA not actually forbid 'write to code section'
> instructions?" / etc....ironic, really, isn't it?
HLA doesn't forbid this at all.
HLA creates a linker response file that, by default, marks the
code section as read-only, but with the -@ option you can tell
HLA to skip creating the linker response file (so you can write your
own, that write-enables the code section to your heart's content).
Doing so is taking your life into your own hands, of course, but
it's perfectly possible to do so. Like many advanced things in HLA,
the default compilation errs on the side of safety, but you always have
the option of tweaking it yourself.
> If Rene hit Randy
> with comments more along these lines because he'd spent five or ten
> minutes actually coding some HLA then he could actually begin to make
> things uncomfortable for Randy...but, as it is, he says something,
> Randy shows that it's not true, he looks a bit silly and it happens
> all over again and again...as the saying goes: "once is 'accident',
> twice is 'a dumb mistake' but three times is just criminally
> stupid"...you'd reckon Rene would spot that he's constantly scuppered
> in his criticisms by them not actually being valid...so you'd think
> he'd put two and two together that if he just "informs himself up" on
> the subject to even a basic level then it's a fairer fight and Randy
> can't just dismiss him so easily by just pointing out that his
> description of HLA is basically just wrong...
There are many things in HLA that I don't like. That's why God invented
"version two".
Fortunately, most of the really bad things are in the "advanced features"
section of HLA, so most people aren't aware of these issues.
Only recently have I been getting hit with a bunch of complaints about
defects in HLA classes. I guess as time passes, it's only reasonable to
expect that some people who actually *know* about object-oriented
programming were going to start using classes in HLA :-)
Another weak area is FASM code generation. I haven't used this
much, so I'm sure there are going to be some problems (e.g., the
"externs" problem that I just fixed for HLA v1.59).
So Beth, I encourage you to use FASM, a lot!
Cheers,
Randy Hyde
Frank Kotler
> Generally, error and diagnostic messages should go to the stderr
> device. Considering that 90% of the time people don't need to actually
> capture this output, but they *do* need to see it, stderr isn't so bad.
Some question whether the product of the "-v" switch ought to be
considered "error and diagnostic"... With Nasm, and I think this applies
to HLA, there *isn't* any "normal output" that someone would reasonably
want to redirect, so sending even error messages to stderr is more a
matter of "tradition" than any practical use. Nasm sends the output of
the "-h" switch to stdout, but errors to stderr - unless "-s" is used to
send 'em to stdout, or "-E myfile.err", to send 'em to a file - kinda
overkill to have both options...
As you say, we need to see the output. It scrolls offscreen unless piped
to "more" or something. If XP offers a "scrollback buffer" as Beth
indicates, I guess it would only be an issue with Win9x... Newbies seem
to be posting the output of the "-v" switch, so I guess they're figuring
something out!
>>Ah, good point...it's heading towards the NASM "bare bones" spirit,
>>isn't it?
Yep! :)
> There are many things in HLA that I don't like. That's why God invented
> "version two".
I've heard rumors that even "version three" is permissable. Nasm's
scared stiff of "1.0", preferring "0.99.99.99" and let the user round it
off. But there are plenty of numbers, actually...
> Only recently have I been getting hit with a bunch of complaints about
> defects in HLA classes. I guess as time passes, it's only reasonable to
> expect that some people who actually *know* about object-oriented
> programming were going to start using classes in HLA :-)
I've noticed that even with the "resistance" to changing, there are a
few knowledgeable programmers starting to be interested in HLA.
Naturally, they're the ones who are finding the "exotic" bugs. This
makes the "shakedown" phase of 1.x longer than you'd like, I'm sure, but
it'll make a stronger 2.0. It's actually a very good sign!
> Another weak area is FASM code generation.
Another weak area is NASM code generation! :) FWIW, I tried translating
HLA's Fasm output (Beth's "minimalist interactive fiction") to Nasmese,
just to see what would be involved. The "ptr equ" had to be changed to
"%define ptr" - Nasm uses "equ" only for numbers and doesn't do text
equates. The "define"s needed to be changed to "%define"s. The section
declarations needed to be changed. "%define rb resb" etc. took care of
that problem. The only part that worries me is "label _HLA042_foo_
dword" and the like. I can (and did) do "%define label" to get rid of
that ("label" is a valid identifier to Nasm, and I sometimes use it -
probably a bad idea). I "hand deleted" the sizes. I anticipated this
drawing "operation size not specified" errors from Nasm, but this
particular code went okay. Nasm's lack of type info may turn out to be a
problem, still. As expected, the executable was exactly the same size as
the Fasm version.
I agree with you that Nasm output ought to be a very low priority. It
really doesn't matter which assembler is being used... except when it
does... Fasm assembles files with large static data *much* faster than
Masm. On the Yahoo list, Rodger mentions using 32k buffers because 64k
assembled too slowly - using Fasm would be another option here. (maybe
Nasm's good at something, too). With the working version of Bison
available, I may have another go at building HLA, but it isn't high on
my priority list, either.
> I haven't used this
> much, so I'm sure there are going to be some problems (e.g., the
> "externs" problem that I just fixed for HLA v1.59).
I'll get 1.59 Real Soon Now - that minor deterrent to using Fasm is a
bit annoying. Oh, yeah, "%define extrn extern", too - Nasm spells it
right... I take your comments on "externdef" as a vote for adding it to
Nasm... we've got the code, but the author ("Stealth" - thanks,
Stealth!) describes it as a "dirty hack", so it isn't "in" yet...
> So Beth, I encourage you to use FASM, a lot!
Encourage experienced Fasm users to give HLA a spin, too!
Best,
Frank
Randall Hyde
"Frank Kotler" <fbko...@comcast.net> wrote in message news:O6Fnb.41157$ao4.90071@attbi_s51...
> Randall Hyde wrote:
>
> > Generally, error and diagnostic messages should go to the stderr
> > device. Considering that 90% of the time people don't need to actually
> > capture this output, but they *do* need to see it, stderr isn't so bad.
>
> Some question whether the product of the "-v" switch ought to be
> considered "error and diagnostic"... With Nasm, and I think this applies
> to HLA, there *isn't* any "normal output" that someone would reasonably
> want to redirect, so sending even error messages to stderr is more a
> matter of "tradition" than any practical use. Nasm sends the output of
> the "-h" switch to stdout, but errors to stderr - unless "-s" is used to
> send 'em to stdout, or "-E myfile.err", to send 'em to a file - kinda
> overkill to have both options...
-test was literally added for my ability to run regression tests on HLA
and capture error messages being sent to the screen (I assume it *is*
reasonable to write error message to the stderr device :-)). The whole
"-v" issue was an unintended consequence.
For as long as I've known, the cmd.exe command line processor has
supported capture of the output (along with a scrollable window).
I haven't used Win95 since, well, about 1997 (when I went totally NT).
So I don't remember what was happening with that version.
>
> As you say, we need to see the output. It scrolls offscreen unless piped
> to "more" or something. If XP offers a "scrollback buffer" as Beth
> indicates, I guess it would only be an issue with Win9x... Newbies seem
> to be posting the output of the "-v" switch, so I guess they're figuring
> something out!
95% of them are probably just cutting and pasting from the command window.
That's what I would do.
And yes, there is a scrollback buffer when running cmd.exe.
> >>Ah, good point...it's heading towards the NASM "bare bones" spirit,
> >>isn't it?
>
> Yep! :)
>
> > There are many things in HLA that I don't like. That's why God invented
> > "version two".
>
> I've heard rumors that even "version three" is permissable. Nasm's
> scared stiff of "1.0", preferring "0.99.99.99" and let the user round it
> off. But there are plenty of numbers, actually...
Well, I've created this roadmap for HLA v2.0 and the two things I've
promised is compilation to object code and a rewrite of the whole thing
(in HLA). I'm not afraid of running out of 1.x numbers, though. I'm at
version 1.59 and that means the 59th version since 1.00. I don't play
funny games with version numbers like 1.2.3.4 - it's too confusing.
Besides, those games are intended to allow commercial firms to extract
more money out of people (e.g., it used to be that Mac OS only cost
money when they had a major version change; now they hit you up for
$120 when then go from 10.2 to 10.3; so they have to stick another
decimal point in there to cover the screw-ups they made by shipping the
product too soon :-(. I don't have this problem with HLA).
> > Only recently have I been getting hit with a bunch of complaints about
> > defects in HLA classes. I guess as time passes, it's only reasonable to
> > expect that some people who actually *know* about object-oriented
> > programming were going to start using classes in HLA :-)
>
> I've noticed that even with the "resistance" to changing, there are a
> few knowledgeable programmers starting to be interested in HLA.
> Naturally, they're the ones who are finding the "exotic" bugs. This
> makes the "shakedown" phase of 1.x longer than you'd like, I'm sure, but
> it'll make a stronger 2.0. It's actually a very good sign!
Yep. At the rate things are going, HLA will be a big hit with everyone
by 2010 :-).
Seriously, though, last year a bunch of old-timers (die-hard assembly
types) started recommending HLA for beginners with no assembly
experience. Now, I'm starting to see a few people who've written
assembly in the past using HLA (the reviews on Amazon, for example,
are interesting). Part of this interest is due to "Windows Programming
in Assembly" (and the realization that I'm going to be doing some more
advanced books in assembly before too much longer) and those who
want to read this stuff will need a "reading" knowledge of HLA.
Part of it is just time. The longer HLA is around, the more time
people have to be comfortable with it and begin to realize that it's
not all that different, functionally, from MASM (I'd bet 90% of the
people who complain about HLA haven't looked at a whole lot
of HLA code beyond the "hello world" program and automatically
assume that it's not really assembly). Now, however, there is source
code starting to get posted here and there in HLA and people are
getting the opportunity to see some real assembly apps written in
HLA.
>
> > Another weak area is FASM code generation.
>
> Another weak area is NASM code generation! :) FWIW, I tried translating
> HLA's Fasm output (Beth's "minimalist interactive fiction") to Nasmese,
> just to see what would be involved. The "ptr equ" had to be changed to
> "%define ptr" - Nasm uses "equ" only for numbers and doesn't do text
> equates. The "define"s needed to be changed to "%define"s. The section
> declarations needed to be changed. "%define rb resb" etc. took care of
> that problem. The only part that worries me is "label _HLA042_foo_
> dword" and the like. I can (and did) do "%define label" to get rid of
> that ("label" is a valid identifier to Nasm, and I sometimes use it -
> probably a bad idea). I "hand deleted" the sizes. I anticipated this
> drawing "operation size not specified" errors from Nasm, but this
> particular code went okay. Nasm's lack of type info may turn out to be a
> problem, still. As expected, the executable was exactly the same size as
> the Fasm version.
Type info is not the problem.
AFAIK, the major problem is forward EQUs (equating a symbol to another
symbol that hasn't been defined yet). I've tried to clean as much of that
as possible up, but there may be a couple of cases yet where HLA
emits some equates that NASM will choke on. The syntax for FASM and
NASM is sufficiently close that doing the port would be easy, were it not
for this issue. I haven't looked at NASM in a while (to be truthful, I haven't
even looked at NASM since you added the optimizer), so maybe this is
no longer a problem.
OTOH, I haven't fully shaken down the FASM code generator yet.
So I have no idea how well that works.
> I agree with you that Nasm output ought to be a very low priority. It
> really doesn't matter which assembler is being used... except when it
> does... Fasm assembles files with large static data *much* faster than
> Masm. On the Yahoo list, Rodger mentions using 32k buffers because 64k
> assembled too slowly - using Fasm would be another option here. (maybe
> Nasm's good at something, too). With the working version of Bison
> available, I may have another go at building HLA, but it isn't high on
> my priority list, either.
Actually, NASM would be a fun project. NASM would be cool because
of the portability of that assembler (almost as good as Gas, and easier to
work with than Gas). As ports to BSD and other *NIX OSes are in the
works, having NASM code output would be a good idea in the event
I get into trouble with Gas.
What I really want, though, is a free linker.
I looked at alink a while back (and even agreed to take on supporting
alink when I get the time .... :-(...), but it will take some work to get
alink to the point it can handle MASM output.
> > I haven't used this
> > much, so I'm sure there are going to be some problems (e.g., the
> > "externs" problem that I just fixed for HLA v1.59).
>
> I'll get 1.59 Real Soon Now - that minor deterrent to using Fasm is a
> bit annoying. Oh, yeah, "%define extrn extern", too - Nasm spells it
> right... I take your comments on "externdef" as a vote for adding it to
> Nasm... we've got the code, but the author ("Stealth" - thanks,
> Stealth!) describes it as a "dirty hack", so it isn't "in" yet...
Actually, as I told Thomasz, though externdef (or GLOBAL) is a
great thing for his assembler to have, HLA no longer requires that.
HLA keeps track of the external symbols it references and only
emits extern declarations for those symbols (if it screws up, that's
a bug in HLA that needs to be fixed). Although HLA still uses
externdef in MASM output, it could just as easily emit "extrn" without
any problems (well, assuming I don't find any more defects in the
externs tracking code...). This feature was one I added specifically
to support FASM and NASM.
> > So Beth, I encourage you to use FASM, a lot!
>
> Encourage experienced Fasm users to give HLA a spin, too!
Always.
OTOH, I'm not a big fan of pushing people who are happy with
their current assembler to switch to HLA. That generates a lot of
flamefests :-). I'm happy with the beginners!
cheers,
Randy Hyde
Beth
> As you say, we need to see the output. It scrolls offscreen unless
piped
> to "more" or something. If XP offers a "scrollback buffer" as Beth
> indicates, I guess it would only be an issue with Win9x... Newbies
seem
> to be posting the output of the "-v" switch, so I guess they're
figuring
> something out!
At least, so far as XP goes "more" doesn't help whatsoever...let me
just check again (in case this has been "fixed" or something since I
tried last :)...yup, it's still not working...HLA spits out its output
as if "more" wasn't there...but then, this is probably to be expected
as you "redirect" the output into "more" and, well, it's the
redirection that's the issue...
Although, "more"'s behaviour here _could_ be used to justify that HLA
_is_ spitting the output to the "wrong" stream...at least, in terms of
"convention" for the ">", "|" and "more" command line stuff...granted,
there's nothing really to say whether this particular output is
logically "stdout" or "stderr" because it _is_ spitting out error
messages and standard output messages...it could be logically
considered either...but, well, as it could be either of the two but
the "redirection" and "more" stuff chooses only to functin with
"stdout" then it should spit it out onto that "stream" merely for
"convenience's sake"...
Yes, I'll accept the "it could feasibly be either stream"
reason...but, regardless, on a practical and useful level, if it spits
it out onto the other stream then there's a whole host of command line
utilities and tricks that can be employed (using "more", redirecting
output into a file for "archiving" compilation / later reading,
etc....in fact, when it comes to the more "exotic" UNIXy command line
tools for post-processing, counting, converting, looking for patterns
inside patterns, etc....I'm sure you could combine them in some
masterful batch file to end up conducting a philaharmonic ochestra or
something silly like that ;)...
I agree..."logically" it makes not an ounce of difference which
"stream" it comes out on...which actually, to my mind means that as
there's nothing "logical" to dictate which "stream" makes the most
sense then we should simply defer this all to _practical_ and _useful_
considerations...switch streams and then command line junkies who
redirect things from batch files into other batch files and so forth
are made happy but it makes not a blind bit of difference to anyone
else because "stdout" and "stderr" are one and the same - the
console - if no redirection stuff is applied...
I've not looked at the source...but wouldn't this actually be quite
simple to change? Just alter it from "fprintf(stderr, ...)" to
"fprintf(stdout, ...)" or whatever...after all, isn't the "-test"
switch already making the change? Just swap around the default
"streams" or something ;)...
> >>Ah, good point...it's heading towards the NASM "bare bones"
spirit,
> >>isn't it?
>
> Yep! :)
Which, of course, is probably something me or Randy should have posted
a long time ago to counter the "it's Pascal!" claims...nothing makes
the point better than actual code people can compile to see for
themselves...
Anyway, perhaps those who doubted the claim - that HLA may "default"
to being HLL-like for the beginners but really can do things "bare
bones" as well - can begin to see some of the stuff about what I was
saying in "HLA basically just changes all the 'directives' into
Pascal-like equivalents to be 'familiar' to HLL coders"...and, well,
"directives" in all assemblers are completely "non-standard", totally
arbitrary and all made up on the spot that HLA being yet one more
"completely different" set of directives is a criticism that _ONLY_
TASM (in being able to assembler MASM code ;) can really sit in a
comfortable position to make...HLA only real difference in attitude
here was: "these 'directive' thingies are all arbitrary made-up stuff,
anyway...so, let's make up stuff for HLA that looks like Pascal and C
and other HLLs, so that HLL programmers are instantly familiar with
what to put where and so forth because they already know much of that
stuff from HLL coding"...
Obviously, if you're already an ASM coder then the "familiarity" thing
ain't so useful...but, then, it wasn't really designed with such
people in mind...although, _still_, I'd point out that HLL data
declarations - which HLA uses - are infinitely easier to use and allow
more complex stuff to be put together...you know, like manually
putting together some "table of arrays to structures of pointers to
structures" or some such nonsense...HLL-like syntax for data
declarations, on the whole, tends to be less cumbersome and bothersome
to use than manually coding out "dword 12345678h" a few hundred times
or whatever...and, of course, data is data is data that this stuff is
quite, quite identical in size, structure, etc. as the ASM version...
Although, on this point, I'm _still_ going to complain that HLA is
lacking the "count the initialisers" functionality that you can find
in C / C++...you know, where you put "int Integers [] = { 1, 2, 3,
4 };" and then the C / C++ compiler counts up that there's four
initialisers and makes "Integers" into a "int [4]" array...this is
_ALL_ a "strictly compile-time" thing processed as it reads the source
making not an ounce of difference to the final output...but it has a
_very handy_ use...if you've got any sort of "variable-length array"
then you can "NULL terminate" that array (and any code that reads from
the array looks for a "NULL" value - or some other "invalid" code you
might use to signal the end - and then just stops reading from the
array :)...
For instance, in the "minimalist interactive fiction" example I gave,
you have to count up how many rooms you have yourself manually and
then insert the number into the "rooms [NumberOfRooms]"
declaration...if you add a new room, then you also have to go back up
to the declaration and add one...if you take away a room then you have
to edit the value again...this can be awkward and is "error-prone"...
So, one simple solution here - which I've tried to suggest to Randy
would make a great little addition to HLA - is a special syntax like
C's "[] = {};" which says "the size of this array is defined by how
many initialisers we have for the array"...then, you can literally add
and remove rooms without doing anything else (well, other than to make
sure that the links to and from other rooms all make sense and fit in
with the map, of course ;)...a "NULL terminator" isn't needed on this
particular example because the rooms are all pointing to one another
and as long as there's no mistakes in the "links" from room to room -
and the code that processes it - it should be impossible for the
player to ever walk "outside" the map...but, for other things, like
"variable-length lists" that need to be processed sequentially then
you can just stick a "NULL" value at the end of the list...exactly
like a "NULL terminated character string" (ASCIIZ :), except that
we've got a more "exotic" form of "string" here...a "NULL terminated
string of structures" or whatever...though it's usual to think of
"string" as something different and "fundamental", it's not
really..."characters" are the primitive type, "strings" are really a
more general name of any sort of "vector" of objects ;)...
> > Only recently have I been getting hit with a bunch of complaints
about
> > defects in HLA classes. I guess as time passes, it's only
reasonable to
> > expect that some people who actually *know* about object-oriented
> > programming were going to start using classes in HLA :-)
>
> I've noticed that even with the "resistance" to changing, there are
a
> few knowledgeable programmers starting to be interested in HLA.
Well, I can be "half smug" on that score because I jumped on the
bandwagon first before it was actually "popular" to do so...when, in
fact, it wasn't even really a "bandwagon" because there was no-one
else on board...
Although, even in my case, as I took HLA seriously earlier on than
most, I'm onto "phase two"...I'm looking at the features of all the
assemblers and remembering the "no structure support" problems of one
assembler and the "no OOP helpers" of another or the "no this" or "no
that" of all the tools...and, though HLA is far from perfect either,
there is serious consideration on my part about using it more and
more...well, when it comes to Windows code, of course, as it doesn't
do 16-bit DOS stuff...although, as you've seen, I often write that
"bare bones" enough that _any_ 16-bit assembler will swallow it with
but the slightest changes to directives (well, okay...fair dues to
Annie...the 32-bit instructions I stuffed into one of my posted
examples took a bit more than usual conversions to add in the prefixes
and things...that wasn't so "as is" bare bones code, as A86 - or DEBUG
too, thinking about it - won't swallow the 32-bit without
changes...but even those are somewhat "systematic"...I try my best,
anyway...apologies when it doesn't quite always work...I confess to
simply forgetting about A86 and the other "strictly 16-bit" assemblers
when I wrote that code with some "naughty" 32-bit instructions inside
them ;)...
At least, when HLA v2.x shows up then it's a very serious
consideration that I might just make that one of my main assemblers
(said vaguely because I never really "commit" to any of them...not
just being delibrately "non-partisan", mind you...but simply because
it's "healthy" to keep an open mind and take a wide view of
things...NASM's "flat binary" will always remain handy until the other
assemblers start realising that for some uses - bootloaders, OS code,
"manual" MZ headers, etc. - it's a very simple but very, very useful
function to include :)...
Rene's complaints about that understood...the "it hides ASM!" bit
doesn't apply in my case because I can write very "bare bones" code -
16 or 32 bit - that HLA isn't "hiding" anything from me in particular,
even if we presume Rene to be correct about ASM learners or
whatever...that is, Randy can't "swindle" me - at least, not in the
same way - because I knew the stuff in his AoA before I knew it
existed...so, Hopefully, though Rene might not be greatly pleased by
this possibility, his usual arguments about "learners" don't mean the
same for people who've already learnt the basic stuff...anyway, I
always like a challenge so I can convert things to RosAsm to remain
"non-partisan" on the matter...well, to the extents permissible by
Rene's "specific" philosophy, as "snippets" or any sort of short
routine someone else might borrow could constitute "library
code"...so, really, only entire example programs - and, under Win32,
entire programs tend to be quite large, source code-wise, when there's
a full blown interface and such, programmed directly with the API -
would really fit in with the "philosophy" there...
> Naturally, they're the ones who are finding the "exotic" bugs. This
> makes the "shakedown" phase of 1.x longer than you'd like, I'm sure,
but
> it'll make a stronger 2.0. It's actually a very good sign!
Actually, yes, I'd agreed with that...I'm eager to see v2.x but that's
actually from the perspective that I'm presuming it'll sort out a lot
of the smaller HLA problems...the implementation stuff - not needing
another assembler, better error message output (from doing this stuff
itself rather than using Bison), better speed, etc. - should certainly
be fixed with v2.x because of how it'll be created...but, then again,
if v1.x is being extended for eliminating bugs, issues, adding new
useful ideas, etc. then as that stuff could contribute to a better
v2.x, it's a justifiable - even desirable - postponement...
Remember, Bill Gates talks out of his rear...so do the complete
opposite of his "advice"...he'd say that there's nothing more
"irrelevent" than working on "bugfixed" versions, as the sole purpose
of new versions is for introducing new features...thus, do the exact
opposite and you'll hit the "magic formula"...
I wonder sometimes if Bill says this stuff because he actually 100%
believes it - wouldn't surprise me - or because so many people still
haven't worked out that he's the world's greatest poker player...and
this is a _delibrate_ business tactic?
Ever wondered why the world's richest man _still_ looks like a "geek"?
Another "bluff"...he _looks_ "innocent" like that...he just doesn't
look like the same guy we actually _know him to be_ from his quotes,
leaked internal memos and business practices...when he was cream
pie'd, he actually looked slightly pathetic that you almost felt sorry
for the "poor guy"...until, of course, you remember that "poor" is the
last applicable description for Mr.Gates and that if that cream pie
guy had been a company, he'd have not blinked in eradicating him off
the face of planet Earth for daring not to worship
"Mr.The-Universe-Was-Created-Specifically-For-Me", who can't tell the
difference between _cheating_ to get himself into a classful of girls
and _actually being popular_ with those girls...the quote doesn't
mention it but you think those girls in that class really would have
considered him a "success" for the pretty low, desparate and pathetic
_cheating_ of manipulating their time-tables so he could just sit next
to them looking "Hopeful" at them all day long? The most condemning
part of Bill's quote is that, to this day, he still doesn't realise
that it was a _pathetic_ thing to do...a tacit admission of "failure"
with the girls, in fact, that he could only manage to sit next to them
by _cheating_ and _deception_...on the other hand, if he'd had the
courage to talk to them and, yeah, "made a play" being himself then
that would have been "success", even if she'd told him to piss
off...because there would have been one girl who might like him and
not said piss off but he's taught himself to believe in himself and
take the risk with honesty and courage...and, yup, to this very day,
he's STILL not seen the very big difference that he's measuring
"success" all wrong and that employing such _underhand_, _illegal_,
_deceptive_ and _immoral_ tactics is actually an implicit admission
that he's a _failure_ because he cannot operate as a normal human
being and "succeed"...the "strong" are never afraid of anything
because nothing scares them...it's the _weak_ who cheat like this
because they know that they simply _aren't good enough_ to "succeed"
in any other way but not to play fair at all...
Thus, there's also good odds on the fact that he says these sort of
things _expecting_ people to take it seriously and copy it...a
bluff...a "dummy" pass...delibrately throwing them a curve...to get
everyone to jump in the wrong direction while he kicks the soccer ball
into the other side of the net, while the goal keeper jumped thw wrong
way because of his "dummy", pretending he was going to kick it one way
and then changing direction at the last minute...but, oh dear, the
goal keeper's jumped and has committed himself so he's no longer able
to change direction to stop the ball going into the goal...
Either way, the winning formula is to _do the opposite_ of what Bill
advises...hence, release new versions in order to "bugfix" and don't
just "add more features" but consolidate multiple features together
into a seamless feature...make it reliable and make it non-bloated and
so forth...whatever he says is "good" should be avoided...because
Bill's either throwing you a curveball delibrately here, as the "poker
face" has always been the way he's succeeded (note, again, this is
another tacit admission of "failure"...because the "poker face" is the
face of a liar implicitly ;)...either that, or he really is stupid and
doesn't know what he's talking about because, by pure coincidence,
when he says "640KB is enough for anybody", that's exactly the very
next thing he breaks straight through with "bloatware"
everywhere...now, as I say, this could be one of two things...he has
very little idea what he's talking about...or that's the "poker face"
he wants you to believe in and what he's doing is delibrately throwing
a "curveball"...as he knows that all the "wannabes" for his position
are listening intently to his interviews, Hoping that he'll
"accidentally" drop the "secret of my success" into everyone's laps...
Considering Microsoft internal policies...that it was by such "bluffs"
that he took on IBM, Apple and hardware manufacturers in significant
movements that secured Microsoft's monopoly...that an otherwise
clearly clever businessman in Bill Gates then suddenly talks
completely out of his arse repeatedly? Something that makes people
_underestimate_ him...and those who don't take him at his word -
whatever he says - and tries to copy his "secret of success" (yet,
no-one is in any sort of real position to come anywhere near
Microsoft)...the world's richest man still giving out an image of
"geekiness" (never appearing with his family or even that there's a
mild suggestion that he has one...despite using himself to promote
Microsoft everywhere but NOT playing the "family man" card...I mean,
look at politicians...that's the very first card people like this
play...because, of course, that would actually look "non-geeky" and
that he's, perhaps, not the "innocent" image he gives off publicly at
all but the ruthlessly merciless Bill Gates we know from Microsoft
internal policies and decisions that come straight from the man at the
top ;)...
No, I credit Bill with a bit more shrewd ruthlessness than this...how
could anyone be in the position he is, in any other way? And we do
_know_ that the image of him personally doesn't quite logically fit
with the image of the man on paper in Microsoft memos...he's where he
is by being one of the best poker players - skilled liars - there
is...and I suspect that these sort of "curveballs" he throws are just
more of the same...demonstrating just how damn good he is at this to
dupe most people so convincingly...repeatedly...stop judging him with
your eyes...don't look at the book's cover...instead, consider how he
is _known_ to have pulled such convincing "bluffs" with a perfect
"poker face" to many businesses to get where he is...consider the man
in terms of the Microsoft policies he sets up for absolute eradication
of any and all competition with complete and utter ruthlessness...to
the extent that he's walked straight through laws and morality
repeatedly without hesitating or blinking at doing so...he's
personally worth billions and yet still pursues more and more money
with utter mercilessness? As one of the quotes I posted up actually
gets straight...that's highly, highly _obsessive_
behaviour...pathalogically so (very much like the ruthless English
King fighting the Scots on a movie I saw who ordered "fire the
arrows!" and his military advisor replied "but our own men are
fighting amongst them...we'd hit our own troops!"...and the King
replied with a firm, stern and cold voice: "So? I won't repeat my
order again: Fire the arrows!"...from the actions of Microsoft, this
is closer to the real Bill that the carefully planned public image
used to "bluff" people as has _always_ been Bill's way of doing
business from the start)...
> > Another weak area is FASM code generation.
>
> Another weak area is NASM code generation! :)
Though it's not as bad as the weakness in the RosAsm code generation
;)
> FWIW, I tried translating
> HLA's Fasm output (Beth's "minimalist interactive fiction")
Oh, I Love that term..."minimalist interactive fiction"...it makes it
sound almost clever, where "tiny unplayable adventure game using
hard-coded data statements" sounds a bit crap in comparison ;)
> to Nasmese,
> just to see what would be involved. The "ptr equ" had to be changed
to
> "%define ptr" - Nasm uses "equ" only for numbers and doesn't do text
> equates. The "define"s needed to be changed to "%define"s. The
section
> declarations needed to be changed. "%define rb resb" etc. took care
of
> that problem. The only part that worries me is "label _HLA042_foo_
> dword" and the like. I can (and did) do "%define label" to get rid
of
> that ("label" is a valid identifier to Nasm, and I sometimes use
it -
> probably a bad idea). I "hand deleted" the sizes. I anticipated this
> drawing "operation size not specified" errors from Nasm, but this
> particular code went okay. Nasm's lack of type info may turn out to
be a
> problem, still. As expected, the executable was exactly the same
size as
> the Fasm version.
Although, I've wondered about that...does the type facilities of the
underlying assembler have to be all that good? What I mean is, if HLA
itself is keeping track of all these things for its own purposes
(analysing the HLA source code for "correctness") then doesn't it and
couldn't it use its own typing facilities and the underlying
assembler's lack of typing isn't such a problem? Except for the
already suggested problem Randy's mentioned about not automatically
"optimising" jumps (which is a different kind of issue, not really
related to "typing" of data :)...
Perhaps I should actually look into the HLA source code...but, well,
the whole "unravelling massive Bison files" stuff puts me off that
idea...yes, that's just laziness but justified laziness, I reckon ;)
> I agree with you that Nasm output ought to be a very low priority.
It
> really doesn't matter which assembler is being used... except when
it
> does... Fasm assembles files with large static data *much* faster
than
> Masm. On the Yahoo list, Rodger mentions using 32k buffers because
64k
> assembled too slowly - using Fasm would be another option here.
(maybe
> Nasm's good at something, too). With the working version of Bison
> available, I may have another go at building HLA, but it isn't high
on
> my priority list, either.
Also, if Randy instead works on v2.x instead of spending lots of time
bringing Nasm into the fold, then that deals with the issue
completely...note that Randy says he plans to still output ASM code
with v2.x as an "alternative option" (I guess because HLA doing this
at the moment _has_ proved to be useful for some things in being able
to do this :)...so Nasm output can be added there instead...including
the possibility that Nasm output might even be easier when HLA is
itself a fully-fledged "assembler"...that is, the "typing" system of
some "underlying" assembler shouldn't matter at all when HLA itself is
perfectly capable of dealing with typing and other issues
itself...because at the moment, HLA does "depend" on one or two
facilities of the underlying assembler...but once it's its own
assembler then it can do all this stuff itself internally and the
"output" need only actually "work", if you understand me...HLA can
deal with "types" itself and then just spit out the right "non-typed"
instructions that'll do the job, where it matters not what the
underlying assembler's type facilities are or not...and other
situations like the "jump optimisation"...HLA itself could do the
"optimisation" internally then spit out the specific "jmp short"
instruction or whatever itself, not needing to rely on that
assembler's facilities to work it out for HLA...
So, in many ways, it might make a lot more sense NOT to bother with
Nasm output for v1.x but, instead, concentrate on v2.x...where the
whole sitation is improved - like not even needing a separate
assembler to "support" HLA at all - and it would actually probably be
far, far easier to create all these different types of output,
anyway...if HLA itself is a proper "assembler" then it can deal with
these issues itself internally...and only need output "valid NASM /
FASM / MASM code" that the other assemblers would correctly assemble
into the right opcodes and data...by-passing the issue of what these
assemblers "support", other than that they support all the necessary
means for HLA to specify the output precisely (which all assemblers
seem capable of doing to the required level, even if it's messy
putting "jmp short", "ds:[]", "dword ptr" and stuff like that
everywhere ;)...
Although, this would delay NASM output...and might even conspire to
making it pointless to attempt, anyway...I'm not totally sure why
specifically Randy wants things like MASM and FASM output on v2.x,
which'll be a proper assembler itself...although, it won't hurt to
have these facilities, other than to take up Randy's time...and, well,
it's his time to spend...plus, Randy's usually a pretty speedy coder
that it probably wouldn't take him all that long to do :)...
> > I haven't used this
> > much, so I'm sure there are going to be some problems (e.g., the
> > "externs" problem that I just fixed for HLA v1.59).
>
> I'll get 1.59 Real Soon Now - that minor deterrent to using Fasm is
a
> bit annoying. Oh, yeah, "%define extrn extern", too - Nasm spells it
> right... I take your comments on "externdef" as a vote for adding it
to
> Nasm... we've got the code, but the author ("Stealth" - thanks,
> Stealth!) describes it as a "dirty hack", so it isn't "in" yet...
Oh, I'm not quite sure what you're talking about here...but would I be
correctly extrapolating from the "externdef" mention that this is
about HLA depending on "conditional inclusion"? That is, that it
defines the prototypes for a ton of stuff, expecting the linker to
correctly ignore anything that actually isn't used...the usual little
attribute of the "externdef" directive?
Yes; In fact, in general, I'd recommend a general policy of more
"virtual" directives that don't necessarily generate code and
data...like structures, where it just defines the "pattern" of some
aggregate data without necessarily creating that data "in-place"...as
I mentioned before, ASM actually "gets this right" where even C needs
a "typedef" on structures to tell it just to _define_ the structure
and NOT actually create an instance of that structure...mind you, I do
say this from the bias of having plans for an assembler that's
_purely_ in a permanent "macro mode" and takes this approach for
_everything_, including machine instructions (everything is a "macro"
and you have to "pin down" every bit of code...sounds odd, I know...it
is a radical different approach to view how a tool should work, that's
true :)...
> > So Beth, I encourage you to use FASM, a lot!
Oh, give us a chance...I've only just downloaded it recently!!! ;)
> Encourage experienced Fasm users to give HLA a spin, too!
Yes; Perhaps that's the more sensible option...at the very least, it
takes the workload off just me on my lonesome testing everything ;)
Beth :)
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message news:zFaob.373$NR5...@newsfep3-gui.server.ntli.net...
>
> I've not looked at the source...but wouldn't this actually be quite
> simple to change? Just alter it from "fprintf(stderr, ...)" to
> "fprintf(stdout, ...)" or whatever...after all, isn't the "-test"
> switch already making the change? Just swap around the default
> "streams" or something ;)...
Actually, the current statements are "fprintf( output, ....);" and I simply
assign the FILE* variable output the value of stderr or stdout depending
on the presence/absence of the "-test" command line parameter.
It would be trivial to recompile the HLA.C file (which is a stand-alone
program and doesn't require recompiling the entire compiler) do
change the default behavior.
>
> Which, of course, is probably something me or Randy should have posted
> a long time ago to counter the "it's Pascal!" claims...nothing makes
> the point better than actual code people can compile to see for
> themselves...
Actually, the "it's Pascal!" claims help *sell* HLA!
Most of the people complaining about HLA "not being true assembler"
have already made up their mind a long time ago; I'm not going to convince
them that they should learn HLA. OTOH, a lot of people are interested
in HLA because it looks so much like Pascal (or "C wrapper" as a lot
of people mistakenly call it).
Yep, there's a few individuals who have concerns about learning
a product that "isn't a real assembler." But they are a small percentage and
I'm not going to get 100% of the incoming population to learn HLA anyway
(heck, this isn't the problem at all; the big problem to wide acceptance of
HLA is the inertia behind the MASM32 project).
>
> Although, on this point, I'm _still_ going to complain that HLA is
> lacking the "count the initialisers" functionality that you can find
> in C / C++...you know, where you put "int Integers [] = { 1, 2, 3,
> 4 };" and then the C / C++ compiler counts up that there's four
> initialisers and makes "Integers" into a "int [4]" array...this is
> _ALL_ a "strictly compile-time" thing processed as it reads the source
> making not an ounce of difference to the final output...but it has a
> _very handy_ use...if you've got any sort of "variable-length array"
> then you can "NULL terminate" that array (and any code that reads from
> the array looks for a "NULL" value - or some other "invalid" code you
> might use to signal the end - and then just stops reading from the
> array :)...
No, it's not missing.
I added this feature a couple of versions ago.
> So, one simple solution here - which I've tried to suggest to Randy
> would make a great little addition to HLA - is a special syntax like
> C's "[] = {};" which says "the size of this array is defined by how
> many initialisers we have for the array"...then, you can literally add
> and remove rooms without doing anything else (well, other than to make
> sure that the links to and from other rooms all make sense and fit in
> with the map, of course ;)...a "NULL terminator" isn't needed on this
> particular example because the rooms are all pointing to one another
> and as long as there's no mistakes in the "links" from room to room -
> and the code that processes it - it should be impossible for the
> player to ever walk "outside" the map...but, for other things, like
> "variable-length lists" that need to be processed sequentially then
> you can just stick a "NULL" value at the end of the list...exactly
> like a "NULL terminated character string" (ASCIIZ :), except that
> we've got a more "exotic" form of "string" here...a "NULL terminated
> string of structures" or whatever...though it's usual to think of
> "string" as something different and "fundamental", it's not
> really..."characters" are the primitive type, "strings" are really a
> more general name of any sort of "vector" of objects ;)...
Well, I don't remember the suggestion, but I added this feature anyway :-)
>
> Well, I can be "half smug" on that score because I jumped on the
> bandwagon first before it was actually "popular" to do so...when, in
> fact, it wasn't even really a "bandwagon" because there was no-one
> else on board...
And I appreciate that.
>
> Actually, yes, I'd agreed with that...I'm eager to see v2.x but that's
> actually from the perspective that I'm presuming it'll sort out a lot
> of the smaller HLA problems...the implementation stuff - not needing
> another assembler, better error message output (from doing this stuff
> itself rather than using Bison), better speed, etc. - should certainly
> be fixed with v2.x because of how it'll be created...but, then again,
> if v1.x is being extended for eliminating bugs, issues, adding new
> useful ideas, etc. then as that stuff could contribute to a better
> v2.x, it's a justifiable - even desirable - postponement...
Don't forget listings :-)
>
> Although, I've wondered about that...does the type facilities of the
> underlying assembler have to be all that good? What I mean is, if HLA
> itself is keeping track of all these things for its own purposes
> (analysing the HLA source code for "correctness") then doesn't it and
> couldn't it use its own typing facilities and the underlying
> assembler's lack of typing isn't such a problem? Except for the
> already suggested problem Randy's mentioned about not automatically
> "optimising" jumps (which is a different kind of issue, not really
> related to "typing" of data :)...
At some point (HLA v3, HLA v4?) it would be nice to have a data
flow analyzer that optionally warns people if they're doing some
crazy things (e.g., pushes and pops don't match, attempts to access
FP variables with integer registers, mixing signed and unsigned values
in a computation). One has to be careful, though. The warnings can
get quite annoying if someone is doing all this on purpose. OTOH,
it is *great* for beginning students.
> Perhaps I should actually look into the HLA source code...but, well,
> the whole "unravelling massive Bison files" stuff puts me off that
> idea...yes, that's just laziness but justified laziness, I reckon ;)
AAAAAGH!
Don't do that.
A few people are looking at the source code right now and
it's convinced me that I really need to go in and clean up that
kludge before anyone else looks at it :-).
>
> Also, if Randy instead works on v2.x instead of spending lots of time
> bringing Nasm into the fold, then that deals with the issue
> completely...note that Randy says he plans to still output ASM code
> with v2.x as an "alternative option" (I guess because HLA doing this
> at the moment _has_ proved to be useful for some things in being able
> to do this :)...so Nasm output can be added there instead...including
> the possibility that Nasm output might even be easier when HLA is
> itself a fully-fledged "assembler"...that is, the "typing" system of
> some "underlying" assembler shouldn't matter at all when HLA itself is
> perfectly capable of dealing with typing and other issues
> itself...because at the moment, HLA does "depend" on one or two
> facilities of the underlying assembler...but once it's its own
> assembler then it can do all this stuff itself internally and the
> "output" need only actually "work", if you understand me...HLA can
> deal with "types" itself and then just spit out the right "non-typed"
> instructions that'll do the job, where it matters not what the
> underlying assembler's type facilities are or not...and other
> situations like the "jump optimisation"...HLA itself could do the
> "optimisation" internally then spit out the specific "jmp short"
> instruction or whatever itself, not needing to rely on that
> assembler's facilities to work it out for HLA...
Actually, one of the main reasons for doing NASM output in
HLA v1.x is specifically to see the kinds of problems I'll encounter
*before* doing the code for HLA v2.0 (i.e., use HLA v1.x as
a prototype). This, plus the ability to port HLA to other OSes is
one of the main reasons I'm interested in the NASM port.
> So, in many ways, it might make a lot more sense NOT to bother with
> Nasm output for v1.x but, instead, concentrate on v2.x...where the
> whole sitation is improved - like not even needing a separate
> assembler to "support" HLA at all - and it would actually probably be
> far, far easier to create all these different types of output,
> anyway...if HLA itself is a proper "assembler" then it can deal with
> these issues itself internally...and only need output "valid NASM /
> FASM / MASM code" that the other assemblers would correctly assemble
> into the right opcodes and data...by-passing the issue of what these
> assemblers "support", other than that they support all the necessary
> means for HLA to specify the output precisely (which all assemblers
> seem capable of doing to the required level, even if it's messy
> putting "jmp short", "ds:[]", "dword ptr" and stuff like that
> everywhere ;)...
NASM output is something I can sneak in between other projects.
HLA v2.0 is a *huge* undertaking. That's one argument for putting
NASM output in earlier.
> Although, this would delay NASM output...and might even conspire to
> making it pointless to attempt, anyway...I'm not totally sure why
> specifically Randy wants things like MASM and FASM output on v2.x,
> which'll be a proper assembler itself...although, it won't hurt to
> have these facilities, other than to take up Randy's time...and, well,
> it's his time to spend...plus, Randy's usually a pretty speedy coder
> that it probably wouldn't take him all that long to do :)...
Mostly, NASM output depends upon that whole issue of "forward
equates" and whether I've completely solved that problem in HLA v1.x.
Other than that, most of the time would actually be spent *learning*
NASM.
>
> Oh, I'm not quite sure what you're talking about here...but would I be
> correctly extrapolating from the "externdef" mention that this is
> about HLA depending on "conditional inclusion"? That is, that it
> defines the prototypes for a ton of stuff, expecting the linker to
> correctly ignore anything that actually isn't used...the usual little
> attribute of the "externdef" directive?
Originally, whenever HLA included a header file, it emitted an
"externdef" statement for every external declaration. MASM, of
course, wouldn't link in the corresponding code unless you actually
*called* that function. Alas, other assemblers didn't have this
feature, so I had to manually track which external symbols a program
uses and only emit "extern" directives for those symbols. Otherwise,
you wound up linking in the entire HLA Standard Library for
a short code sequence. Not Good. This feature is pretty much under
control, now.
> Yes; In fact, in general, I'd recommend a general policy of more
> "virtual" directives that don't necessarily generate code and
> data...like structures, where it just defines the "pattern" of some
> aggregate data without necessarily creating that data "in-place"...as
> I mentioned before, ASM actually "gets this right" where even C needs
> a "typedef" on structures to tell it just to _define_ the structure
> and NOT actually create an instance of that structure...mind you, I do
> say this from the bias of having plans for an assembler that's
> _purely_ in a permanent "macro mode" and takes this approach for
> _everything_, including machine instructions (everything is a "macro"
> and you have to "pin down" every bit of code...sounds odd, I know...it
> is a radical different approach to view how a tool should work, that's
> true :)...
Templates would be nice, yes.
That's something I'm thinking about in the v2.0 timeframe.
Cheers,
Randy Hyde
Guillermito
> Did you look at "Guillermito's Particles"? A link was posted to it here
> a while ago.
<shameless plug>
It's still there:
http://www.guillermito2.net/archives/2003_08_10.html
> I've been "translating" it to Nasm (written for Tasm).
You're welcome to send me a copy of the Nasm source / binary when it's
done :)
> He
> uses an odd trick... upon entering "WndProc" he "pop [addresse_retour]".
> I couldn't imagine why, until I got here - it allows him to call
> DefWindowProc with the stack as it is.
The thing is that I'm a control freak (for code only). I don't like
when the assembler (TASM, in this case) adds instructions that I
didn't ask him to put there. And that is what happens when you declare
a PROC. I don't want any kind of stack frame or other useless thing
(for me, in this particular case). I want to have in the binary
exactly what I wrote in the source, no less, no more. I can handle the
stack myself.
Well, actually, not all the time :) About this particular trick, I
simplified it even more in the first versions (I don't remember the
detail but I can probably check), but then I discovered that it worked
under Win98 but not Win2000. I still don't know why. And frankly, I
didn't have the time nor the envy to dig inside Windows internal
differences to understand why it happened, I generally progress by
trial and error. If my code works, whatever dirty it is, I'm happy :)
--
Guillermito
http://www.guillermito2.net
Randall Hyde
"mchiper" <not...@yahoo.com> wrote in message news:1of3qv8qq665tt7bj...@4ax.com...
>
>
> wrt COFF and OMF..
> Speaking as an assembly language programmer.
> If the CPU doesn't know or care, why should I?
> Does it have something to do with compiling?
> And things like "passing parameters to sub-routines".
It's other compilers and the OS that cares, not the CPU.
Of course, if the OS can't load your code into memory, then
I guess you could say that the CPU cares because it will never
see it.
COFF: all (modern) Microsoft language use this
OMF: many Borland languages use this.
If you want to write code that links with Borland C++, you'll
want to emit OMF code. If you want to link with MSVC++,
you'll want COFF.
If you want to write a stand-along assembly executable, it
doesn't matter which you use because they both, ultimately,
become a PE file (under Windows, anyway).
>
> Another question:
> Then I include a lib, are only the funtions I actaully USE
> compiled/assembled into the object file?
Generally this is the case (this is the difference between a LIB
file and an OBJ file, in most people's minds).
Cheers,
Randy Hyde
Beth
> Beth wrote:
> > I've not looked at the source...but wouldn't this actually be
quite
> > simple to change? Just alter it from "fprintf(stderr, ...)" to
> > "fprintf(stdout, ...)" or whatever...after all, isn't the "-test"
> > switch already making the change? Just swap around the default
> > "streams" or something ;)...
>
> Actually, the current statements are "fprintf( output, ....);" and I
simply
> assign the FILE* variable output the value of stderr or stdout
depending
> on the presence/absence of the "-test" command line parameter.
Of course...that's how I'd tend to format it too so that it could be
easily changed...but, as I say, I'd not looked at the HLA source code
so this was more a "rough description" of the changes needed...if
you've already prepared things so that all you need do is change one
variable then all to the better :)
> It would be trivial to recompile the HLA.C file (which is a
stand-alone
> program and doesn't require recompiling the entire compiler) do
> change the default behavior.
Well, basically, are you going to do that? Because that's really my
point here...that, yes, there's not much to logically separate
"stdout" from "stderr" (they point to the same place by default
:)...and though you could reasonably think "well, these are error
messages it's spitting out so they should go to 'stderr'", which makes
some sense...this is unfortunately NOT how most tools view things,
expecting everything on "stdout"...so, for practical reasons, it's
actually a lot more useful for it to be coming out on "stdout" for
operators like "|" and ">" to work and other command line utilities to
happily work with the output...then "-test" can just do the reverse,
as it does now, but the defaults are swapped...
Yes, a small trivial little thing...but, as you yourself have noted,
it's in these little details that a "professional" product that users
like resides...although, thinking about it, changing the stream won't
effect RadAsm or something, will it? Or is RadAsm happy to intercept
output whatever it's routed through?
And, while we're on the subject, I've noticed that you've now added
the "response file" stuff to the command line...much
appreciated...except, ummm, it's not quite working...the final
character in the response file gets chopped off (fine if it's just a
carriage return but it might not always be the case ;)...it worked
with just a filename in the file but if other options were put in
there - but without a new line between them - then it looks at the
whole thing as an option and rejects it...also, switching on the "-v"
option, it once produced a very weird display where it output
something like "1: response file" and "-o:omf" over and over again
before just stopping, having done nothing...
It seems to be somewhat "fragile" at the moment...not very "robust" to
odd inputs...but it's great that you've included it...very much
appreciated...so don't get me wrong when I'm forced to say: I look
forward to when it actually works...because, as I noted, I wanted to
see this option included to be able to get it to work with my
IDE...and the particular things it can't handle are exactly what my
IDE spits out (for example, the IDE uses macros to create the contents
of the response file but doesn't put any new lines in it...it's just
like an ordinary command line but just inside a file to allow it to be
really long...and HLA seems to consider this as one long command line
option, as if it can't see the spaces between arguments or
something...and rejects it...that is, it says that
"-w -v -c -p:temp -o:omf" etc. isn't a valid option...well, yes,
_combined_ it is a valid option because it's supposed to be a series
of options...but, oddly, HLA's looking at the entire thing as if it's
just one big option and the spaces weren't there...if this is any help
in diagnosing why it's behaving strangely like this ;)...
> > Which, of course, is probably something me or Randy should have
posted
> > a long time ago to counter the "it's Pascal!" claims...nothing
makes
> > the point better than actual code people can compile to see for
> > themselves...
>
> Actually, the "it's Pascal!" claims help *sell* HLA!
> Most of the people complaining about HLA "not being true assembler"
> have already made up their mind a long time ago; I'm not going to
convince
> them that they should learn HLA. OTOH, a lot of people are
interested
> in HLA because it looks so much like Pascal (or "C wrapper" as a lot
> of people mistakenly call it).
>
> Yep, there's a few individuals who have concerns about learning
> a product that "isn't a real assembler." But they are a small
percentage and
> I'm not going to get 100% of the incoming population to learn HLA
anyway
> (heck, this isn't the problem at all; the big problem to wide
acceptance of
> HLA is the inertia behind the MASM32 project).
Yeah, well...notwithstanding, "it's Pascal!" is inaccurate...it should
be addressed with a more accurate picture of what is going on than to
simply accept it because it's not a bad thing to have people
believe...a "principle" thing, you know? It's not right so it should
be corrected but this shouldn't actually effect those who are looking
at HLA because they think "it's Pascal!"...because, even though it
isn't Pascal, what it is, is close enough to what they want that the
difference doesn't matter...that is, when people come to HLA thinking
along "it's Pascal!" lines, it's not really _Pascal_ that they're
looking for...but something that's about as easy to code with as
Pascal...and HLA mostly reaches that for them...
If you like, an apple isn't an orange...so, rightly, you must call the
apple "an apple" and the orange "an orange"...but when someone's
hungry, they will not care actually in the slightest if it's "an
apple" or "an orange" so long as it's a tasty fruit that they can
eat...it's the same basic rough principle when it's "hungry for
knowledge" rather than for food :)
Regardless, there's no sense lying when there's actually no particular
reason to do so, as the truth isn't in any way harmful to be
stated...especially when, after all, you would not actually want to do
anything so silly as prove Rene correct about "Lies! Swindles!
Sh*t-selling!" and so forth, when there was absolutely no actual good
reason not to just put your hands up and admit what HLA is...because
though it may not be "Pascal!" nor even perhaps "'real' assembly" in
someone's eyes, what it is, is a good, useful and noble thing in its
own right...
To my mind, that's what makes HLA good...the fact that it _isn't_ any
of these things specifically but rather something different that's "in
between" and, thus, is able to work towards a "best of both worlds"
solution...that, in effect, HLA does NOT make a needless "compromise"
just to fit into some arbitrary category of jargon but concentrates on
giving what is actually useful...
Human instinct may generally stray towards automatically presuming
"different" means "bad"...but, often, that instinct has got things
totally backwards and seriously wrong, in fact...fearing change is
understandable...even a sensible thing to do, if it makes you take a
cynical and critical perspective of it before you're willing to adopt
it...that's really what the "we fear change!!" human instinct is
_supposed_ to be all about...to make you _cautious_ about anything
"new" and "different" so that you take the time to review it to see if
it'll actually work and whether it's a good thing for you to follow
it...the problem, though, is that sometimes it kicks in too hard and
ends up paralysing someone from actually adopting what is a good,
useful new method or technology or whatever...the "rabbit in the
headlights" syndrome...
Like going on stage in front of an audience, you _should_ be
nervous...that's a _very good_ thing, as it keeps you concentrated and
focussed...it proves that you actually _give a crap_ about giving a
good performance and not messing up...but this healthy instinct
becomes totally _unhealthy_ when you walk out on stage to the
microphone and - bang! - you're a "rabbit in the headlights" (or
"spotlights" in this particular case ;) just standing there doing and
saying nothing...the fear has paralysed you because you're
over-worrying, over-panicking, to fearful to make even the slightest
movement, lest you get it wrong...and that fear of messing up is
actually your very downfall...the thing that makes you mess
up...worse, realising this as you stand there, you could become _even
more_ paralysed because you know you've messed up and now you're
scared crapless worrying over how you're going to get yourself out of
this mess without making it worse than it already is...it's a
"downward spiral" kind of deal...once you start locking up with fear
paralysis, it makes you even more fearful and prone to lock up even
further...
So, sometimes, whatever your instincts are telling you, you simply
have to disregard them to get yourself out of this "downward
spiral"...when the audience laughs, then laugh along with them
because, sure, you _do_ look stupid...happens to the best of us...no
big deal...hey, crack a joke and just accept your new role as a
comedian...that's a valuable and respectable profession - in fact, an
incredibly difficult and harsh one, constantly working against your
natural instincts not to want to look stupid, that if you can master
it, you're arguably a better performer than most - to have too ;)...
So, fine, if it's a "joke" to some people then just make it a damn
good, intelligently witty "joke", so to speak...craft the very best
"joke" you can think up and then take your bow and do it all again the
next day...that requires, in fact, usually _more talent_ to
master...so it's a perfectly respectable profession and, as always,
"the only thing to fear is fear itself" ;)
> > Although, on this point, I'm _still_ going to complain that HLA is
> > lacking the "count the initialisers" functionality that you can
find
> > in C / C++...you know, where you put "int Integers [] = { 1, 2, 3,
> > 4 };" and then the C / C++ compiler counts up that there's four
> > initialisers and makes "Integers" into a "int [4]" array...this is
> > _ALL_ a "strictly compile-time" thing processed as it reads the
source
> > making not an ounce of difference to the final output...but it has
a
> > _very handy_ use...if you've got any sort of "variable-length
array"
> > then you can "NULL terminate" that array (and any code that reads
from
> > the array looks for a "NULL" value - or some other "invalid" code
you
> > might use to signal the end - and then just stops reading from the
> > array :)...
>
> No, it's not missing.
> I added this feature a couple of versions ago.
Oh, okay...I didn't notice that...the "updates" come thick and fast
with HLA that, oops, I wasn't keeping up with the "latest"
there...apologies...
Well, I did make the suggestion and you did reply to it at the time,
if I recall correctly...perhaps, then, it was a "subconscious"
thing...or maybe you'd always intended it, anyway...who knows? And,
basically, who cares? As long as it's now been added, that's all that
really counts :)
> > Well, I can be "half smug" on that score because I jumped on the
> > bandwagon first before it was actually "popular" to do so...when,
in
> > fact, it wasn't even really a "bandwagon" because there was no-one
> > else on board...
>
> And I appreciate that.
Ah, you're welcome...but, really, it's just me and the way I am...I
don't take "sides"...or, at least, my "side" is defined by what
appears to be the most correct...not simply because some "cause" or
another has some celebrity or the most people or whatever...I take up
"the cause" when it appears right (I may be mistaken in that, of
course, but I do try my best to get it "right" as far as I can :),
yes...but I don't "join the gang", simply for the sake of joining the
gang...often, this can cause difficulties, I know well, because some
take it as like a "personal" thing...but it's nothing of the
sort...the company I keep is defined by the company I keep...and what
I believe to be correct is defined by what I believe to be
correct...the two can, unfortunately, interfere with each other
sometimes (especially when people _insist_ that they do because
they've chosen to "define themselves" by these things and expect me to
do likewise :)...but I consider the two to be essentially independent
and though it can't always be done - a bit like the proverbial
"business and pleasure" - there's no compulsion to mix them...it's
probably, in fact, even a "healthy" thing NOT to mix them :)
> > Actually, yes, I'd agreed with that...I'm eager to see v2.x but
that's
> > actually from the perspective that I'm presuming it'll sort out a
lot
> > of the smaller HLA problems...the implementation stuff - not
needing
> > another assembler, better error message output (from doing this
stuff
> > itself rather than using Bison), better speed, etc. - should
certainly
> > be fixed with v2.x because of how it'll be created...but, then
again,
> > if v1.x is being extended for eliminating bugs, issues, adding new
> > useful ideas, etc. then as that stuff could contribute to a better
> > v2.x, it's a justifiable - even desirable - postponement...
>
> Don't forget listings :-)
Oh, yes...don't forget listing files! Never forget those listing
files! _Very_ important and everything! ;)
> > Although, I've wondered about that...does the type facilities of
the
> > underlying assembler have to be all that good? What I mean is, if
HLA
> > itself is keeping track of all these things for its own purposes
> > (analysing the HLA source code for "correctness") then doesn't it
and
> > couldn't it use its own typing facilities and the underlying
> > assembler's lack of typing isn't such a problem? Except for the
> > already suggested problem Randy's mentioned about not
automatically
> > "optimising" jumps (which is a different kind of issue, not really
> > related to "typing" of data :)...
>
> At some point (HLA v3, HLA v4?) it would be nice to have a data
> flow analyzer that optionally warns people if they're doing some
> crazy things (e.g., pushes and pops don't match, attempts to access
> FP variables with integer registers, mixing signed and unsigned
values
> in a computation). One has to be careful, though. The warnings can
> get quite annoying if someone is doing all this on purpose. OTOH,
> it is *great* for beginning students.
Well, just make everything "optional" and provide "switches" and so
forth, then it's pretty hard to go wrong...with HLA's "target
audience", these switches may tend to be "on" rather than "off" by
default, to help those beginners...but as long as there's always an
"off" switch, then you cater for everyone's preferences :)...
Just make it as easy "not to do" as it is "to do" and then there can't
really be any great complaints to be made...in fact, here's a nice
little idea which tends to happily cater for all...have a plain text
"configuration file" - HLA.INI - and then have HLA read its "default
settings" out of the file (not out of the registry! Though it's
similar in principle, the registry's "hidden" nature is a horrible
thing ;)...the "HLA.INI" that comes with the package unedited is set
to "beginner" defaults...but the "advanced" user opens it up in
Notepad and changes "Analyse = yes" to "Analyse = no"...
Now, a simple command line switch to turn it "off" is just as valid
and any command line switches would automatically "override" anything
in the ".ini" file...but the ".ini" file allows the user to set the
"defaults" just the _once_ and then HLA is always in "advanced mode"
every time they use it without having to type in anything extra...
Mind you, at the moment, there's not really enough switches and
settings to probably justify taking an approach like this at the
moment...but it's an idea to consider - for _any_ tool, really - when
there's a lot of options and settings, where the "defaults" could
equally be "beginner" or "advanced"...
> > Perhaps I should actually look into the HLA source code...but,
well,
> > the whole "unravelling massive Bison files" stuff puts me off that
> > idea...yes, that's just laziness but justified laziness, I reckon
;)
>
> AAAAAGH!
> Don't do that.
> A few people are looking at the source code right now and
> it's convinced me that I really need to go in and clean up that
> kludge before anyone else looks at it :-).
:)
> > Also, if Randy instead works on v2.x instead of spending lots of
time
[ snip ]
> > assembler's facilities to work it out for HLA...
>
> Actually, one of the main reasons for doing NASM output in
> HLA v1.x is specifically to see the kinds of problems I'll encounter
> *before* doing the code for HLA v2.0 (i.e., use HLA v1.x as
> a prototype). This, plus the ability to port HLA to other OSes is
> one of the main reasons I'm interested in the NASM port.
Ah, of course...I was thinking from "user perspective", not "author
perspective" there...that makes sense..."prototyping" and all that :)
> > So, in many ways, it might make a lot more sense NOT to bother
with
[ snip ]
> > putting "jmp short", "ds:[]", "dword ptr" and stuff like that
> > everywhere ;)...
>
> NASM output is something I can sneak in between other projects.
> HLA v2.0 is a *huge* undertaking. That's one argument for putting
> NASM output in earlier.
Okay...I'm convinced...ah, it was probably just me being impatient to
suggest different, anyway ;)
> > Although, this would delay NASM output...and might even conspire
to
> > making it pointless to attempt, anyway...I'm not totally sure why
> > specifically Randy wants things like MASM and FASM output on v2.x,
> > which'll be a proper assembler itself...although, it won't hurt to
> > have these facilities, other than to take up Randy's time...and,
well,
> > it's his time to spend...plus, Randy's usually a pretty speedy
coder
> > that it probably wouldn't take him all that long to do :)...
>
> Mostly, NASM output depends upon that whole issue of "forward
> equates" and whether I've completely solved that problem in HLA
v1.x.
> Other than that, most of the time would actually be spent *learning*
> NASM.
Actually, on a completely unrelated subject but this has just reminded
me, I tried writing to a code section using HLA and got a lot of error
messages...none of which actually related to what the actual issue
was...HLA doesn't support writes to code sections...now, of course, I
do know that such things are a "bad idea" and "not very good software
engineering" and all that stuff...but should HLA be the one
prohibiting this? Especially if we consider HLA being used for, say,
OS development or maybe embedded stuff...stuff which ain't so
important at the moment, perhaps, but if you're getting more
"advanced" users...well, the point being that beginners will be
putting all their data into their program with "static" data
declarations which put it into the data rather than code section,
anyway...even though it's "bad idea" stuff for beginners, maybe, this
actually naturally would only be something "advanced" users would be
encountering anyway, trying to stuff their data into a code
section...and, as we know, "advanced" users tend not to appreciate
these sorts of things...
Perhaps, instead, you could maybe do a bit like TASM's "check for code
segment overrides in protected mode" switch...or, come to think of it,
something like the ".386" versus ".386p" directives in other
assemblers...that is, by default - for the beginners - this stuff is
signalled by a warning or error or something...and then there could be
a set of switches about relaxing checks / prohibitions on "dangerous"
things to allow it to be done when the "advanced" user specifically
says "yes, this stuff is okay" with an optional switch...so that
writing to code sections or using "priviledged" instructions - which
would generally make Windows blow a fuse unless you've set the section
flags properly or were writing, say, a device driver or something - is
picked up and warned against unless it's been specifically okay'd by
the programmer because they actually _want_ the code to do something
like this...
In fact, that's something else that's in other assemblers that might
also have a place in HLA, now that I pick up on it in passing...the
".386" / ".486" / ".MMX" style of directives...these do get less
useful as time goes on...but could come in handy if someone wants to
specifically write code that should still work on a 486 or one of
those original Pentiums that lacked MMX and that sort of
thing...although, it's actually possibly getting more useful as Intel
and AMD compete with 3DNow! and so forth which aren't necessarily on
each other's chips...so, restricting the available machine
instructions to specific chips has its uses for people who might need
wide "compatibility" to run on older machines or just to make sure
that, though it may run happily on an AMD, it won't blow a fuse on an
Intel...blah-blah-blah...
Of course, I'm waffling on here...you don't have to immediately
include any of these suggestions...perhaps v2.x things...and you
_could_ equally choose to decide that you'd rather mark which
instructions work on which chips in the _documentation_
instead...because as long as there's some way to ensure this stuff,
though a manual way might not be as "convenient" as an automatic
solution, "it'll do for now" ;)
> > Oh, I'm not quite sure what you're talking about here...but would
I be
> > correctly extrapolating from the "externdef" mention that this is
> > about HLA depending on "conditional inclusion"? That is, that it
> > defines the prototypes for a ton of stuff, expecting the linker to
> > correctly ignore anything that actually isn't used...the usual
little
> > attribute of the "externdef" directive?
>
> Originally, whenever HLA included a header file, it emitted an
> "externdef" statement for every external declaration. MASM, of
> course, wouldn't link in the corresponding code unless you actually
> *called* that function. Alas, other assemblers didn't have this
> feature, so I had to manually track which external symbols a program
> uses and only emit "extern" directives for those symbols. Otherwise,
> you wound up linking in the entire HLA Standard Library for
> a short code sequence. Not Good. This feature is pretty much under
> control, now.
Ah, an old problem...okay, cool...just wondering what the topic was,
as this seems to be something discussed on CLAX or whatever, when I
wasn't looking or something :)
> > Yes; In fact, in general, I'd recommend a general policy of more
> > "virtual" directives that don't necessarily generate code and
[ snip ]
> > is a radical different approach to view how a tool should work,
that's
> > true :)...
>
> Templates would be nice, yes.
> That's something I'm thinking about in the v2.0 timeframe.
Well, what I'm talking about is a tool that's _purely_ templates
throughout...but that's not a HLA suggestion or anything...that's just
me and my "alien brain" heading off passed Jupiter, as per normal ;)
Beth :)
Beth
> Dear Beth,
> You are growing old, wasting your time.
Ummm, isn't that a description of the entire human race? I'm in good
company, then :)
> This thread appears to me
> (with minor diversions into other time wasters)
> Like a Mutual Admiration Time Wasters Society.
Yes, probably...although, strictly, this newsgroup - though it's hard
to credit it at times - is actually about discussing things along
these lines...you know, ASM programming and assemblers and that sort
of thing...
This may be "time wasting" from various perspectives...but,
officially, this is actually the general stuff the group is supposed
to be talking about...and the strange diversions into meta-physics and
Yoda-like wisdoms is actually the thing that's technically "wasting
the group's time"...
Admittedly, it's incredibly easy to get the wrong impression with the
"relaxed" attitude that tends to be in this group at times...but,
really, it's actually sort of the other way around, in fact...
> In my recent Interent bowsing wrt hackers..
> I came accross the "magic Switch"..
> A switch with only one wire connected that crashed a computer.
> The author, and the "hacker" community at large was confounded.
>
> After five seconds thought, I said "Grounding".
> Cuz I know nobody really has a clue what it is...
>
> Then I read on about the latest opinion..
> It was connected to a ground pin in the computer.
> And the crashed the system, when switched..
>
> What really took some doing, in building the switch..
> Was to keep the computer from crashing when the touched it,,, !!!
> Or the metal cabinet, it as attached to..:)
>
> Strange as it may seem..
> Ground paths are what computers are all about.
> Can't find one, when you need one.
> Can't keep it out when you want to.
> The more you use it, the futher a way it is..
>
> Holey, Moley.. It's Magic!!
Again, I'm not entirely sure what it is you're trying to address here
specifically...but it's all very interesting to read, anyway...
If I'm understanding you through the general "vagueness" you tend to
write with, you're talking about crashing a computer by
short-circuiting it to ground? Yes, short-circuiting electrical
devices tends to make them cease to function properly...though I'd
hardly call it "magic"...for example, I can also make a computer cease
to function properly by swinging a large sledgehammer onto the CPU to
shatter it into a million pieces...or, an alternative way of
"short-circuiting" the machine might be to drop it into a bath,
perhaps...but these methods would, by most people's reckoning, not
constitute anything all that particularly "magical" in that the
machine stops functioning properly afterwards...
But, then again, there is an element of subjectivity here...after all,
the very concept of the computer itself would appear to be "magic" to
past generations...it's all a "relative" sort of deal, really ;)
Beth :)
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message news:9JCob.1244$yH4...@newsfep1-gui.server.ntli.net...
>>
> > It would be trivial to recompile the HLA.C file (which is a
> stand-alone
> > program and doesn't require recompiling the entire compiler) do
> > change the default behavior.
>
> Well, basically, are you going to do that?
To be truthful, I don't really care one way or the other :-)
But since you guys are complaining about it, I'm more than
happy to change the "-v" option so that it sends its output to
stdout rather than the default of stderr. After all, if I'm going to
bitch about Rene not listening to users, I'd better not behave
the same way :-).
There are some issues I'm going to have to resolve at some
point or another, though. E.g., "Does #print send it's output to
the stderr (always), stderr (always), or to whereever the current
output stream is headed?" "Where does #error send its output?"
Stuff like that...
Because that's really my
> point here...that, yes, there's not much to logically separate
> "stdout" from "stderr" (they point to the same place by default
> :)...and though you could reasonably think "well, these are error
> messages it's spitting out so they should go to 'stderr'", which makes
> some sense...this is unfortunately NOT how most tools view things,
> expecting everything on "stdout"...so, for practical reasons, it's
> actually a lot more useful for it to be coming out on "stdout" for
> operators like "|" and ">" to work and other command line utilities to
> happily work with the output...then "-test" can just do the reverse,
> as it does now, but the defaults are swapped...
"-test" actually does more than simply redirect the output.
"-v", however, doesn't do those extra things; but it will (as of HLA v1.60)
switch the output to stdout.
> Yes, a small trivial little thing...but, as you yourself have noted,
> it's in these little details that a "professional" product that users
> like resides...although, thinking about it, changing the stream won't
> effect RadAsm or something, will it? Or is RadAsm happy to intercept
> output whatever it's routed through?
RadASM doesn't have a problem at all with the stderr route.
It's just as easy to intercept stderr under Windows as it is stdout
(they are both standard streams and the file handles to both are
equally accessible). That's why I never thought that there would
be an issue with this. Of course, the fact that cmd.exe doesn't seem
to have a way to redirect stderr is a bit problematic for command-line
users, but cmd.exe also lets you cut & paste stuff from the command
window, so even this hasn't been a problem in the past.
> And, while we're on the subject, I've noticed that you've now added
> the "response file" stuff to the command line...much
> appreciated...except, ummm, it's not quite working...the final
> character in the response file gets chopped off (fine if it's just a
> carriage return but it might not always be the case ;)...it worked
> with just a filename in the file but if other options were put in
> there - but without a new line between them - then it looks at the
> whole thing as an option and rejects it...also, switching on the "-v"
> option, it once produced a very weird display where it output
> something like "1: response file" and "-o:omf" over and over again
> before just stopping, having done nothing...
Actually, there are several other problems.
In particular, I needed to trim whitespace and other stuff.
This is getting cleaned up for v1.60.
> It seems to be somewhat "fragile" at the moment...not very "robust" to
> odd inputs...but it's great that you've included it...very much
> appreciated...so don't get me wrong when I'm forced to say:
It's still going to be fragile.
It will be a while before I've tried all kinds of garbage in a response
file to see what happens. But if you're careful it will give you the
functionality you're seeking today.
> I look
> forward to when it actually works...because, as I noted, I wanted to
> see this option included to be able to get it to work with my
> IDE...and the particular things it can't handle are exactly what my
> IDE spits out (for example, the IDE uses macros to create the contents
> of the response file but doesn't put any new lines in it...it's just
> like an ordinary command line but just inside a file to allow it to be
> really long...and HLA seems to consider this as one long command line
> option, as if it can't see the spaces between arguments or
> something...and rejects it...that is, it says that
> "-w -v -c -p:temp -o:omf" etc. isn't a valid option...well, yes,
> _combined_ it is a valid option because it's supposed to be a series
> of options...but, oddly, HLA's looking at the entire thing as if it's
> just one big option and the spaces weren't there...if this is any help
> in diagnosing why it's behaving strangely like this ;)...
I would almost argue that you should dump HLA.EXE and call
HLAPARSE.EXE directly from your IDE. I'd have to think about
the ramifications of that, though.
> Regardless, there's no sense lying when there's actually no particular
> reason to do so, as the truth isn't in any way harmful to be
> stated...especially when, after all, you would not actually want to do
> anything so silly as prove Rene correct about "Lies! Swindles!
> Sh*t-selling!" and so forth, when there was absolutely no actual good
> reason not to just put your hands up and admit what HLA is...because
> though it may not be "Pascal!" nor even perhaps "'real' assembly" in
> someone's eyes, what it is, is a good, useful and noble thing in its
> own right...
Who's lying? I'm just not able to respond to every post out there
that says "this is Pascal!" As I've found that such proclamations
tend to help HLA more than hurt it, I've let a lot of such comments
slide rather than get all puffy about them.
> To my mind, that's what makes HLA good...the fact that it _isn't_ any
> of these things specifically but rather something different that's "in
> between" and, thus, is able to work towards a "best of both worlds"
> solution...that, in effect, HLA does NOT make a needless "compromise"
> just to fit into some arbitrary category of jargon but concentrates on
> giving what is actually useful...
Of course.
HLA's greatness is because it's HLA.
Not because it's Pascal, C, MASM, or what have you.
> Like going on stage in front of an audience, you _should_ be
> nervous...that's a _very good_ thing, as it keeps you concentrated and
> focussed...it proves that you actually _give a crap_ about giving a
> good performance and not messing up...but this healthy instinct
> becomes totally _unhealthy_ when you walk out on stage to the
> microphone and - bang! - you're a "rabbit in the headlights" (or
> "spotlights" in this particular case ;) just standing there doing and
> saying nothing...the fear has paralysed you because you're
> over-worrying, over-panicking, to fearful to make even the slightest
> movement, lest you get it wrong...and that fear of messing up is
> actually your very downfall...the thing that makes you mess
> up...worse, realising this as you stand there, you could become _even
> more_ paralysed because you know you've messed up and now you're
> scared crapless worrying over how you're going to get yourself out of
> this mess without making it worse than it already is...it's a
> "downward spiral" kind of deal...once you start locking up with fear
> paralysis, it makes you even more fearful and prone to lock up even
> further...
As my vocal coach says: "harness that energy for good."
> So, sometimes, whatever your instincts are telling you, you simply
> have to disregard them to get yourself out of this "downward
> spiral"...when the audience laughs, then laugh along with them
> because, sure, you _do_ look stupid...happens to the best of us...no
> big deal...hey, crack a joke and just accept your new role as a
> comedian...that's a valuable and respectable profession - in fact, an
> incredibly difficult and harsh one, constantly working against your
> natural instincts not to want to look stupid, that if you can master
> it, you're arguably a better performer than most - to have too ;)...
Which is exactly why it's not worth arguing too much with the
crowd that insists HLA is a "C wrapper" or "Pascal clone".
You spend a small amount of effort to correct any misconceptions,
but once it's clear that the person on the other end of the conversion
is simply being malicious, you add them to your kill file and move on.
> Well, just make everything "optional" and provide "switches" and so
> forth, then it's pretty hard to go wrong...with HLA's "target
> audience", these switches may tend to be "on" rather than "off" by
> default, to help those beginners...but as long as there's always an
> "off" switch, then you cater for everyone's preferences :)...
I'm not even worried about it at this point :-) Such features are a long
ways off into the future. We've had discussions (and flame-fests) about
"optimizing assemblers" and data flow analyzers around here before
(and over in C.L.A.X.). Until something enters active development,
however, it's not even worth the discussion.
> Just make it as easy "not to do" as it is "to do" and then there can't
> really be any great complaints to be made...in fact, here's a nice
> little idea which tends to happily cater for all...have a plain text
> "configuration file" - HLA.INI - and then have HLA read its "default
> settings" out of the file (not out of the registry! Though it's
> similar in principle, the registry's "hidden" nature is a horrible
> thing ;)...the "HLA.INI" that comes with the package unedited is set
> to "beginner" defaults...but the "advanced" user opens it up in
> Notepad and changes "Analyse = yes" to "Analyse = no"...
I hate the registry. Period. One of the worst kludges Microsoft ever
created.
> Now, a simple command line switch to turn it "off" is just as valid
> and any command line switches would automatically "override" anything
> in the ".ini" file...but the ".ini" file allows the user to set the
> "defaults" just the _once_ and then HLA is always in "advanced mode"
> every time they use it without having to type in anything extra...
By the time such a feature becomes real, one would hope that there is an
interface to these features from and IDE so a user can turn them on or off
from a project-based set of checkboxes in a window.
Of course, such switches would be modifiable as pragmas within the
source code to a project as well (something you want to be able to
turn on and off on a line by line basis).
But much beyond that, I'm not willing to think about it because it's
just too far off into the future.
>
> Actually, on a completely unrelated subject but this has just reminded
> me, I tried writing to a code section using HLA and got a lot of error
> messages...none of which actually related to what the actual issue
> was...HLA doesn't support writes to code sections...now, of course, I
> do know that such things are a "bad idea" and "not very good software
> engineering" and all that stuff...but should HLA be the one
> prohibiting this? Especially if we consider HLA being used for, say,
> OS development or maybe embedded stuff...stuff which ain't so
> important at the moment, perhaps, but if you're getting more
> "advanced" users...well, the point being that beginners will be
> putting all their data into their program with "static" data
> declarations which put it into the data rather than code section,
> anyway...even though it's "bad idea" stuff for beginners, maybe, this
> actually naturally would only be something "advanced" users would be
> encountering anyway, trying to stuff their data into a code
> section...and, as we know, "advanced" users tend not to appreciate
> these sorts of things...
Uh....
This is just a bug. This isn't an intended feature.
I will look into this problem and try to have it fixed by the v1.60 release.
Now as to whether the code section is actually writable in memory or
not is another question altogether...
>
> In fact, that's something else that's in other assemblers that might
> also have a place in HLA, now that I pick up on it in passing...the
> ".386" / ".486" / ".MMX" style of directives...these do get less
> useful as time goes on...but could come in handy if someone wants to
> specifically write code that should still work on a 486 or one of
> those original Pentiums that lacked MMX and that sort of
> thing...although, it's actually possibly getting more useful as Intel
> and AMD compete with 3DNow! and so forth which aren't necessarily on
> each other's chips...so, restricting the available machine
> instructions to specific chips has its uses for people who might need
> wide "compatibility" to run on older machines or just to make sure
> that, though it may run happily on an AMD, it won't blow a fuse on an
> Intel...blah-blah-blah...
Too messy to add at this point.
A "cheating" way to add this capability is via an include file
that uses the "#id" pragma to disable all the reserved words
corresponding to the extra instructions. E.g., "#include( "486.hhf" )
could disable all the instructions that don't work on a 486.
If someone is *really* interested, this file wouldn't be hard to create
(well, set of files, actually, you'd need 386.hhf, 486.hhf,
pentium.hhf, pentiumII.hhf, pentiumIII.hhf, and pentiumIV.hhf).
> Of course, I'm waffling on here...you don't have to immediately
> include any of these suggestions...perhaps v2.x things...and you
> _could_ equally choose to decide that you'd rather mark which
> instructions work on which chips in the _documentation_
> instead...because as long as there's some way to ensure this stuff,
> though a manual way might not be as "convenient" as an automatic
> solution, "it'll do for now" ;)
Well, you have the ability to do this yourself. So if you really need it,
have at it :-)
Cheers,
Randy Hyde
Betov
news:1ed8586c.03103...@posting.google.com:
> Frank Kotler <fbko...@comcast.net> wrote ...
>
>> Did you look at "Guillermito's Particles"? A link was posted to it
>> here a while ago.
>
> <shameless plug>
> It's still there:
> http://www.guillermito2.net/archives/2003_08_10.html
Chez moi, sous 2000, ta Demo tourne bien.
C'est écrit sous TASM??? Si oui, je suis un peu étonné: C'est
un vrai bordel dans les Sections (Import groupé avec Ressources,
Virtual Section marquée SNC_MEM_EXECUTE, etc...).
Est-ce-que tu as écrit du code auto-modifiable, pour la première
section?
J'ai essayé de le désassembler avec RosAsm sans succès. Je vais
voir ça plus à fond... comme exercice pour tester les capacités
des fonctions de reconnaissances du desassembleur de RosAsm.
Belle Demo, qui, en tout cas, mériterait un peu plus que "Some
useless Code", comme titre. ;)
Site interressant, aussi. Juste une petite connerie dans le
paragraphe sur Leni Riefenstahl, à propos du croisement
Hitler / Jesse Owens, qui relève de la propagande, et non
de l'histoire... mais, bon... personne n'est parfait... :))
Salut amical. René.
Betov
213.228.0.133:
> guill...@pipo.com (Guillermito) wrote in
> news:1ed8586c.03103...@posting.google.com:
>
>> Frank Kotler <fbko...@comcast.net> wrote ...
>>
>>> Did you look at "Guillermito's Particles"? A link was posted to it
>>> here a while ago.
>>
>> <shameless plug>
>> It's still there:
>> http://www.guillermito2.net/archives/2003_08_10.html
>
>
Oooopppssss! Ah oui, c'est bien du Code auto-modifiable. De plus, le "Code"
recopié, au lancement, dans la première Section semble être encrypté.
Est-ce bien le cas? Si oui... pourquoi?
betov.
< http://betov.free.fr/RosAsm.html >
Anonymous Guy
On 2003-11-01 be...@free.fr said:
> Chez moi, sous 2000, ta Demo tourne bien.
>
> C'est écrit sous TASM??? Si oui, je suis un peu étonné:...
Alors, Rene! En Anglais, s'il vous plait.
C'est un newsgroup d'Anglais!
Frank Kotler
Oui! Nous ne parlons pas Francais ici!
Meilleur,
Francois
Frank Kotler
>> Did you look at "Guillermito's Particles"? A link was posted to it
>> here a while ago.
>
> <shameless plug> It's still there:
> http://www.guillermito2.net/archives/2003_08_10.html
Great! I was too lazy to look up the URL. Sorry.
>> I've been "translating" it to Nasm (written for Tasm).
>
> You're welcome to send me a copy of the Nasm source / binary when
> it's done :)
I've sent it in its current condition - working, but a bit of a mess. If
I hold off until it's "done", entropy will have turned us into a black
hole, or something. Source only, pointless to send the binary... I
didn't compress it, so it's twice the size of yours.
[Betov, let me know if you want the uncompressed binary - I think you'll
find it easier to disassemble]
...
> The thing is that I'm a control freak (for code only). I don't like
> when the assembler (TASM, in this case) adds instructions that I
> didn't ask him to put there. And that is what happens when you
> declare a PROC.
Right. I hate to see beginners being taught to use "PROC" everywhere,
whether it's needed or not. I don't *think* it actually generates any
code if there are no parameters, does it?
Nasm doesn't have "PROC" of any kind built in, but there are macro files
that can be %included. One such file (myc32.mac, I think it is, in the
"misc" directory) doesn't set up a stack frame, but indexes parameters
and locals off esp. When it's invoked, it sets a "context", creates a
"fudge factor" set to zero, and defines your named parameters and locals
as "esp +/- N + fudge_factor". Then push and pop are made macros, too -
if in the context of a proc, they adjust fudge_factor, otherwise they
just push and pop. So you can have the convenience of named parameters
and locals without the clutter of a stack frame, and leaving ebp free
for "width", or whatever. (I haven't used that include file for your
example, but I think it would fit in nicely - I may try it)
> I don't want any kind of stack frame or other useless thing (for me,
> in this particular case).
Exactly! A stack frame isn't appropriate everywhere. Your example shows
that you can leave it out and "do it yourself" even using an assembler
that's "noted" for its high-level features. (Tasm is being peddled - as
"Pasm" - by an outfit called "Paradigm" as a "C++ assembler", I understand)
> I want to have in the binary exactly what I wrote in the source, no
> less, no more. I can handle the stack myself.
>
> Well, actually, not all the time :) About this particular trick, I
> simplified it even more in the first versions (I don't remember the
> detail but I can probably check),
I recall removing an "address_retour2" that appeared to be unused...
> but then I discovered that it worked under Win98 but not Win2000. I
> still don't know why. And frankly, I didn't have the time nor the
> envy to dig inside Windows internal differences to understand why it
> happened, I generally progress by trial and error.
Yeah, I'm still running '98 so I'm mystified by the reports that
something "doesn't run on XP". (mostly dos programs) I know it's a
different beast, but I thought the interface was supposed to be the same
- and if MS can't emulate dos, who can? Not if you get low-level with
it, I guess...
> If my code works, whatever dirty it is, I'm happy :)
Sure. I forget who said "First make it work, you've got the rest of your
life to make it elegant." I've translated your example to Nasm, Betov's
interested, I wouldn't be too surprised to see an HLA version of it turn
up... You could get to be famous for this, Guillermito!
One problem I had was with "[esi - ebp]" - Nasm claims that's not a
valid effective address! Bug (or "misfeature") in Nasm, I think. Wound
up doing "neg ebp"/"add al, [esi + ebp]"/"adc ah, 0"/"neg ebp". Seems to
work, but it's pretty ugly. I'm no expert on what's a valid effective
address and what isn't, but if Tasm assembles it, Nasm ought to! I've
been meaning to consult the Intel docs to see what the story is, and
then try to chase down the problem in Nasm. I may name the bug after
you, too :)
Now that you've shared your code with the world, you might start to see
improvements offered, too. I think we could initialize the WndClass
structure with "offset WndProc" (just "WndProc" for Nasm) statically
rather than at runtime, for example - haven't tried it. Also, I'm a
little troubled by the need for "isolation". I notice that you use "ja"
and "jb" to check if the pixel's in the buffer - I wonder if that
shouldn't be a signed comparison - "jg" and "jl" - in some places...
xor eax, eax ;check minimum Y
cmp [esi+8], eax ;outside?
jb neg_y_speed ;yes => inverse the speed
...for example... I'm suspicious of that, but haven't played with it. I
don't think "jb" is ever going to be true, is it? (yet the thing
works... I dunno...) I wonder if that's why "isolation" is neccessary,
tho...
I'm curious what we might be able to do with the dialog process, too.
These numbers we use for "resources" are arbitrary, right? Could we
choose numbers that would serve as an index into a table? Any
interesting possibilities there?
Normally I'm not too interested in Windows programming, but your example
has caught my fancy and given me something to study, and I thank you for it!
Best,
Frank
Betov
@news.wplus.net:
Si c'est tout ce que tu as à répondre à ma question
... va te faire foutre.
(N'importe comment, je pense avoir compris, ce qui
enlève, pour moi, tout interet à la chose. Domage).
Betov.
Betov
@attbi_s02:
1) It was on purpose, in order to irritate a little
bit all of the fucky US Nazis flying around here.
2) As Herbert Kleebauer, said in another thread,
there is no reason why various national languages
should or could not be used here. At that time, i
answered to him the same remarks you are answering
to me to day, because, i was as well a bit irritated,
as i need the help of a dictionary for many words
in german. Since then, he convinced me and i changed
my mind. After all, a good occasion, for me, for
improving my poor knowledge of the german language.
And, at the end, if we had to choose for a new
international Computing Language, my vote would go
for the most in use one on earth:
Arabian.
This would help us to understand the interresting
things Bin Laden may say, on occasion, instead
of understanding the tons of bullshits Georges
Bush says everyday.
3) Hopefully for the US bastards, other countries'
people are intelligent enough to make the effort
of learning your barbarian language.
4) When China will be the world leader in the
Computers and computing areas, you will have
a bigger problem than with reading my couple of
french sentences.
:)) :)) :))
< http://betov.free.fr/RosAsm.html >
Frank Kotler
> 1) It was on purpose, in order to irritate a little
> bit all of the fucky US Nazis flying around here.
You're so cute when you're mad! :)
Best,
Baron Von Kotler, the flying Nazi
Betov
> [Betov, let me know if you want the uncompressed binary - I think
> you'll find it easier to disassemble]
No. Thanks. There are many other clean Demos available. (Too bad,
this one was really great...).
> One problem I had was with "[esi - ebp]" - Nasm claims that's not a
> valid effective address! Bug (or "misfeature") in Nasm, I think. Wound
> up doing "neg ebp"/"add al, [esi + ebp]"/"adc ah, 0"/"neg ebp". Seems
> to work, but it's pretty ugly. I'm no expert on what's a valid
> effective address and what isn't, but if Tasm assembles it, Nasm ought
> to!
No. It's an invalid Address. RosAsm does not assemble this either and
never will. ;)
For all your other remarks, you are 100% right... Just,... a bit
of consistency would be to help denigrating HLA as much as possible
instead of supporting an Anti-Assembly Project...
Betov.
Frank Kotler
>>One problem I had was with "[esi - ebp]" - Nasm claims that's not a
>>valid effective address! Bug (or "misfeature") in Nasm, I think. Wound
>>up doing "neg ebp"/"add al, [esi + ebp]"/"adc ah, 0"/"neg ebp". Seems
>>to work, but it's pretty ugly. I'm no expert on what's a valid
>>effective address and what isn't, but if Tasm assembles it, Nasm ought
>>to!
>
> No. It's an invalid Address. RosAsm does not assemble this either and
> never will. ;)
Right. I looked into it some more, and Tasm's doing "compiler tricks" -
it assembles [esi - ebp] as [esi + ebp]... Well, it's a "C++ assembler",
what do you expect :)
> For all your other remarks, you are 100% right... Just,... a bit
> of consistency would be to help denigrating HLA as much as possible
> instead of supporting an Anti-Assembly Project...
Okay, but what if I view HLA as an "alternate approach", rather than
"Anti-Assembly". Do I bash it anyway, just on your say-so?
> < http://betov.free.fr/RosAsm.html >
If I feel that there are some projects for which the RosAsm approach is
inappropriate, should I denigrate RosAsm as "Anti-Assembler" too?
What if I like *both* Apples and Oranges (which I do - Bananas, too!)?
Am I forced to choose one, and be the enemy of all other fruits?
"Different strokes for different folks" - surely there's a similar
saying in French...
Best,
Frank
Ed Beroset
> Guillermito wrote:
>
>> The thing is that I'm a control freak (for code only). I don't like
>> when the assembler (TASM, in this case) adds instructions that I
>> didn't ask him to put there. And that is what happens when you
>> declare a PROC.
>
> Right. I hate to see beginners being taught to use "PROC" everywhere,
> whether it's needed or not. I don't *think* it actually generates any
> code if there are no parameters, does it?
You're right that it doesn't generate anything if there are no
parameters, but I think you're wrong about what to teach beginners.
Beginners *should* be taught to use PROC everywhere and then to be told
about the very few instances where it be better not to use it.
> Nasm doesn't have "PROC" of any kind built in, but there are macro files
> that can be %included. One such file (myc32.mac, I think it is, in the
> "misc" directory) doesn't set up a stack frame, but indexes parameters
> and locals off esp.
Maybe you didn't notice that the instructions which use esp as an index
are usually longer than the same instruction with ebp? That's not much
of an optimization!
> just push and pop. So you can have the convenience of named parameters
> and locals without the clutter of a stack frame, and leaving ebp free
> for "width", or whatever.
If you're writing in assembly language, it often makes sense to pass
parameters in registers, and PROC certainly allows that. If you don't
pass parameters in a stack frame, there's no stack frame.
>> I don't want any kind of stack frame or other useless thing (for me,
>> in this particular case).
>
> Exactly! A stack frame isn't appropriate everywhere. Your example shows
> that you can leave it out and "do it yourself" even using an assembler
> that's "noted" for its high-level features.
Let's look a little more closely at that. Here's a snippet of this code:
dlgproc:
pusha
push ebp
mov ebp, esp
mov ebx, [ebp+8+20h]
mov eax, [ebp+12+20h]
mov edx, [esp+16+20h]
Now here's an alternative I wrote which uses PROC and ARG:
dialog proc C
arg alpha:DWORD, beta:DWORD, gamma:DWORD
pusha
mov ebx,[alpha]
mov eax,[beta]
mov edx,[gamma]
Which do you think is smaller? Which do you think would be easier to
modify without error? Which is easier to read and understand? The
answer to the first question is that they are *exactly the same size*.
Here's the listing file that shows both:
5 00000000 dialog proc C
6 ARG alpha:DWORD, beta:DWORD, gamma:DWORD
1 7 00000000 C8 0000 00 ENTERD 00000h,0
1 8 00000004 60 pusha
9 00000005 8B 5D 08 mov ebx,[alpha]
10 00000008 8B 45 0C mov eax,[beta]
11 0000000B 8B 55 10 mov edx,[gamma]
12
13 0000000E dlgproc:
14 0000000E 60 pusha
15
16 0000000F 55 push ebp
17 00000010 8B EC mov ebp, esp
18
19 00000012 8B 5D 28 mov ebx,[ebp+8+20h]
20 00000015 8B 45 2C mov eax,[ebp+12+20h]
21 00000018 8B 54 24 30 mov edx,[esp+16+20h]
This is with TASM 4.0, which is not the latest one that Borland produced.
>> I want to have in the binary exactly what I wrote in the source, no
>> less, no more. I can handle the stack myself.
Maybe, but apparently not as well as the assembler. Note that the third
mov instruction above actually uses esp instead of ebp. Since there's a
one-byte penalty for using the esp-referenced version, and esp and ebp
are equal here, I'd conclude that this was simply an error on the part
of the programmer -- an error that would not have occurred had he used
the PROC style I demonstrated.
Ed
Randall Hyde
"Frank Kotler" <fbko...@comcast.net> wrote in message news:5b3pb.82836$Fm2.63882@attbi_s04...
>
> ...
> > The thing is that I'm a control freak (for code only). I don't like
> > when the assembler (TASM, in this case) adds instructions that I
> > didn't ask him to put there. And that is what happens when you
> > declare a PROC.
Of course, if you really knew the assembler well, you'd know how to
turn all that stuff on or off at a whim
> Right. I hate to see beginners being taught to use "PROC" everywhere,
> whether it's needed or not. I don't *think* it actually generates any
> code if there are no parameters, does it?
This harkens back to the days when MASM first appeared and people
couldn't stand creating segments and stuff like that. The nice thing about
using procs everywhere, versus the original "label and ret" definition of
a procedure, is that by simply changing one statement you could reassemble
the code for different memory models and environments. For example,
with MASM, it's a relatively trivial operation to recompile a library module
to be called from Pascal or C. This takes a bit of effort (especially with a large
set of library routines) if you're using the "label and ret" form.
Even programmers who work exclusively in flat mode assembly language
tend to find the Proc/Endp approach useful because, if nothing else, it
completely delineates where a procedure begins and ends in the source
file -- something that the "label and ret" approach doesn't do as well.
>
> > I don't want any kind of stack frame or other useless thing (for me,
> > in this particular case).
>
> Exactly! A stack frame isn't appropriate everywhere. Your example shows
> that you can leave it out and "do it yourself" even using an assembler
> that's "noted" for its high-level features. (Tasm is being peddled - as
> "Pasm" - by an outfit called "Paradigm" as a "C++ assembler", I understand)
OTOH, a stack frame is appropriate in certain places. It's nice if your
assembler can automatically associate offsets into the stack frame with
symbolic names for you when it is appropriate to use the stack frame. It's
also nice if your assembler can keep track of the number of parameters
and (at the very least) provide you with a named constant that you can use
to remove those parameters from the stack upon returning from the procedure.
This helps make your code far more maintainable during development (when
parameter lists might be changing).
>
> > If my code works, whatever dirty it is, I'm happy :)
>
> Sure. I forget who said "First make it work, you've got the rest of your
> life to make it elegant." I've translated your example to Nasm, Betov's
> interested, I wouldn't be too surprised to see an HLA version of it turn
> up... You could get to be famous for this, Guillermito!
Often, however, writing "dirty code" results in code that doesn't work
and cannot be maintained. Programming style, alas, is not independent
of robustness. Those who take a "quick and dirty" approach to coding
pay the price down the road.
> One problem I had was with "[esi - ebp]" - Nasm claims that's not a
> valid effective address! Bug (or "misfeature") in Nasm, I think. Wound
> up doing "neg ebp"/"add al, [esi + ebp]"/"adc ah, 0"/"neg ebp". Seems to
> work, but it's pretty ugly. I'm no expert on what's a valid effective
> address and what isn't, but if Tasm assembles it, Nasm ought to! I've
> been meaning to consult the Intel docs to see what the story is, and
> then try to chase down the problem in Nasm. I may name the bug after
> you, too :)
If TASM assembles this, the bug is in TASM, not NASM.
There is no such addressing mode. You can subtract a *constant*
(which the assembler computes the two's complement of and then
adds), but you can't subtract a register.
Cheers,
Randy Hyde
Betov
@attbi_s04:
> If I feel that there are some projects for which the RosAsm approach is
> inappropriate, should I denigrate RosAsm as "Anti-Assembler" too?
I am used to range the Assemblers into two families:
* The multi-purpose Assemblers (NASM, FASM, ...)
* The specific-purpose Assemblers (RosAsm, GoAsm, ...)
So, saying that "there are some projects for which the RosAsm
approach is inappropriate",... is nothing but what i could extend
the definition with, by myself... The purpose of RosAsm is to
write PEs and is, by definition "inappropriate" to anything else.
Now, ranging the various Assemblers from "True Low Level" to
HLL able Assemblers (Compilers), it is evident that RosAsm is
not in first Pos. Assemblers like NASM and FASM are more "Low
Level" than RosAsm. It is also evident that the true low level
features of these Multi-Purpose Assemblers would be absolutly
useless in a Specific Assembler like RosAsm.
At this point of view, it will be interresting to compare the
result of the FASM Fresh Project, when finished, with the results
of RosAsm. I am yet convinced that the way i choosed to go, with
this, was the accurate one. The results will say... as they actually
may say, when comparing NaGoa to RosAsm, today (...).
> What if I like *both* Apples and Oranges (which I do - Bananas, too!)?
> Am I forced to choose one, and be the enemy of all other fruits?
>
> "Different strokes for different folks" - surely there's a similar
> saying in French...
The "Beth Attitude". Unfortunately, that does not work: Assembly is
not a fruit, and, _yes_, you _have_ to choose: Being both *pro* and
*anti* is nothing but incoherency. Good is good. Bad is bad.
Since the oncoming of the first versions of Windows, that kicked
Assembly out for many years, the oncoming of HLA is the next
important attempt to kick Assembly back to the grave-yard again.
The fact that Master Pdf is not that much rejected from a List
like this one, but, instead admited as a full-right member, only
shows the competency level of most participants.
Given the actual catastrophic state of Assembly such incoherent
attitudes will have an heavy cost, as the significative number
of beginners that will be lost by HLA (added to the ones lost
by MASM) will have to be substracted from the Assembly Rebirth.
Being "Pro-HLA", or even saying that HLA is an Assembler _is_
working _against_ Assembly.
I am a bit estonished, that a guy like you, who seems to
perfectely understand the interresting details of Assembly
programming, does not seem to understand in what manner the
programming methods pushed by HLA and master Pdf are nothing
but Anti-Asm (not talking of the demential syntax -which is
only a detail problem- not talking of the fact that HLA is
only a ridiculous and awfuly written Pre-Parser, not talking
of the real Randall motivations, and so on...).
Betov.
Frank Kotler
>> Right. I hate to see beginners being taught to use "PROC" everywhere,
>> whether it's needed or not. I don't *think* it actually generates any
>> code if there are no parameters, does it?
>
> You're right that it doesn't generate anything if there are no
> parameters, but I think you're wrong about what to teach beginners.
> Beginners *should* be taught to use PROC everywhere and then to be told
> about the very few instances where it be better not to use it.
Well... I guess all I can say is that I disagree. Teaching beginners to
use a macro that may or may not generate additional code, or alter the
code I wrote, seems like a bad idea to me. Obviously, it's a minority
opinion.
...
> Let's look a little more closely at that. Here's a snippet of this code:
>
> dlgproc:
>
> pusha
>
> push ebp
> mov ebp, esp
>
> mov ebx, [ebp+8+20h]
> mov eax, [ebp+12+20h]
> mov edx, [esp+16+20h]
>
> Now here's an alternative I wrote which uses PROC and ARG:
>
> dialog proc C
> arg alpha:DWORD, beta:DWORD, gamma:DWORD
>
> pusha
> mov ebx,[alpha]
> mov eax,[beta]
> mov edx,[gamma]
>
> Which do you think is smaller?
A question of fact - doesn't matter what I think.
> Which do you think would be easier to
> modify without error?
Now *that's* a matter of opinion. It's fairly obvious in the "non-macro"
version that if I do "mov ebp, [width]", kaboom! Whether this is obvious
in the "proc" case depends on how well I understand what "proc" does, I
guess.
> Which is easier to read and understand?
Again, "in the eye of the beholder". As someone who learned on an
assembler that doesn't do "proc", and having to translate examples that
use "proc" I can state as a fact that *I* find the "explicit" version
much easier to understand. YMMV.
> Maybe, but apparently not as well as the assembler. Note that the third
> mov instruction above actually uses esp instead of ebp. Since there's a
> one-byte penalty for using the esp-referenced version, and esp and ebp
> are equal here, I'd conclude that this was simply an error on the part
> of the programmer -- an error that would not have occurred had he used
> the PROC style I demonstrated.
Ya got us dead to rights on this one. Good catch! Avoiding typos like
this (I assume it was unintentional) is a point in favor of using
macros, no question. I still feel I'd rather see the code "right in
front of my face", but that's just my opinion (and there are cases where
I *would* prefer a macro).
Thanks for looking at that code, Ed. I always learn something from you,
even when we disagree! :)
Best,
Frank
Frank Kotler
> "Frank Kotler" <fbko...@comcast.net> wrote in message news:5b3pb.82836$Fm2.63882@attbi_s04...
>
>>...
>> [Guillermito]
>>>The thing is that I'm a control freak (for code only). I don't like
>>>when the assembler (TASM, in this case) adds instructions that I
>>>didn't ask him to put there. And that is what happens when you
>>>declare a PROC.
>
> Of course, if you really knew the assembler well, you'd know how to
> turn all that stuff on or off at a whim
He did.
>>Right. I hate to see beginners being taught to use "PROC" everywhere,
>>whether it's needed or not. I don't *think* it actually generates any
>>code if there are no parameters, does it?
>
> This harkens back to the days when MASM first appeared and people
> couldn't stand creating segments and stuff like that.
Before my time :) I *do* think there are situations where you're better
off to do without "creating segments", too, so I guess I see the
parallel there...
> The nice thing about
> using procs everywhere, versus the original "label and ret" definition of
> a procedure, is that by simply changing one statement you could reassemble
> the code for different memory models and environments. For example,
> with MASM, it's a relatively trivial operation to recompile a library module
> to be called from Pascal or C. This takes a bit of effort (especially with a large
> set of library routines) if you're using the "label and ret" form.
I'll confess I hadn't thought much about that advantage (I don't compile
a lot of Pascal modules :) That's a good point, but I don't think it
really applies to this particular piece of code.
> Even programmers who work exclusively in flat mode assembly language
> tend to find the Proc/Endp approach useful because, if nothing else, it
> completely delineates where a procedure begins and ends in the source
> file -- something that the "label and ret" approach doesn't do as well.
Okay, but it's just serving as a "comment without a semicolon" in this
case. (nothing wrong with that, I guess)
> OTOH, a stack frame is appropriate in certain places. It's nice if your
> assembler can automatically associate offsets into the stack frame with
> symbolic names for you when it is appropriate to use the stack frame. It's
> also nice if your assembler can keep track of the number of parameters
> and (at the very least) provide you with a named constant that you can use
> to remove those parameters from the stack upon returning from the procedure.
> This helps make your code far more maintainable during development (when
> parameter lists might be changing).
Absolutely agreed.
>>One problem I had was with "[esi - ebp]" - Nasm claims that's not a
>>valid effective address! Bug (or "misfeature") in Nasm, I think. Wound
>>up doing "neg ebp"/"add al, [esi + ebp]"/"adc ah, 0"/"neg ebp". Seems to
>>work, but it's pretty ugly. I'm no expert on what's a valid effective
>>address and what isn't, but if Tasm assembles it, Nasm ought to! I've
>>been meaning to consult the Intel docs to see what the story is, and
>>then try to chase down the problem in Nasm. I may name the bug after
>>you, too :)
>
> If TASM assembles this, the bug is in TASM, not NASM.
> There is no such addressing mode. You can subtract a *constant*
> (which the assembler computes the two's complement of and then
> adds), but you can't subtract a register.
I *knew* I should have looked into that before I mentioned it! Whether
you call it a "bug" or a "helpful feature", Tasm quietly changes your
"-" to a "+". In this code, it occurs in a "smoothing" routine -
intended to access the pixel above the one we're calculating - so it
doesn't really do what's intended. I've tried it with and without "neg
ebp" around it, and I can't see any visual difference, so I guess it
doesn't make any difference here. Not the kind of thing I like to see an
assembler doing...
Thanks for the clarification on that, Randy. I know, I should have
looked it up myself...
Best,
Frank
Frank Kotler
>>"Different strokes for different folks" - surely there's a similar
>>saying in French...
>
> The "Beth Attitude".
I hope Beth is pleased to have the attitude named after her, but I hope
she and I aren't the *only* ones who can keep an open mind!
> Unfortunately, that does not work: Assembly is
> not a fruit, and, _yes_, you _have_ to choose:
What will happen if I *refuse* to choose? Lets find out...
> Being both *pro* and
> *anti* is nothing but incoherency.
Agreed. What's wrong with being "pro" and "pro"?
> Good is good. Bad is bad.
So is a rainstorm good or bad?
> Since the oncoming of the first versions of Windows, that kicked
> Assembly out for many years, the oncoming of HLA is the next
> important attempt to kick Assembly back to the grave-yard again.
Perhaps because I only got into computers around the first versions of
Windows, I may not fully appreciate the "first reign" of assembly. It
seemed more interesting to me than HLLs - I never noticed it was in a
graveyard.
> The fact that Master Pdf is not that much rejected from a List
> like this one, but, instead admited as a full-right member, only
> shows the competency level of most participants.
Well, ignoring the fact that no one is "admitted" or "rejected" to/from
this newsgroup, what *does* that tell us? Many of the "regulars"
actually *don't* like HLA that much. Does the degree of their dislike
for HLA predict their competence? I hadn't noticed much correlation.
> I am a bit estonished, that a guy like you, who seems to
> perfectely understand the interresting details of Assembly
> programming, does not seem to understand in what manner the
> programming methods pushed by HLA and master Pdf are nothing
> but Anti-Asm (not talking of the demential syntax -which is
> only a detail problem- not talking of the fact that HLA is
> only a ridiculous and awfuly written Pre-Parser, not talking
> of the real Randall motivations, and so on...).
However perfect or imperfect my understanding, I come to the conclusions
I come to. Thirty-five years ago, a lot of people wondered why "an
intelligent guy like me" couldn't figure out that the Vietnam war was a
good thing, and that the government wouldn't lie to us (seems incredible
now, but that was the argument...) I reject now, as I rejected then, the
notion that "a guy like me" ought to come to different conclusions than
I do.
Best,
Frank
sinewave
> The "Beth Attitude". Unfortunately, that does not work: Assembly is
> not a fruit, and, _yes_, you _have_ to choose: Being both *pro* and
> *anti* is nothing but incoherency. Good is good. Bad is bad.
Hutch is best known for MASM32. Randy is best known for HLA. you're best
known for a make-believe "war on assembly"... this is really pathetic Rene!
promote RosAsm... forget about your dumb war!
regards,
half-a-nobody
Ed Beroset
> Ed Beroset wrote:
>
>>> Right. I hate to see beginners being taught to use "PROC" everywhere,
>>> whether it's needed or not. I don't *think* it actually generates any
>>> code if there are no parameters, does it?
>>
>>
>> You're right that it doesn't generate anything if there are no
>> parameters, but I think you're wrong about what to teach beginners.
>> Beginners *should* be taught to use PROC everywhere and then to be
>> told about the very few instances where it be better not to use it.
>
>
> Well... I guess all I can say is that I disagree. Teaching beginners to
> use a macro that may or may not generate additional code, or alter the
> code I wrote, seems like a bad idea to me.
Are you going to tell beginners not to use jnc? Perhaps you should,
since, depending on the distance to the target, a number of different
encodings could be used. Better, I think, than to just avoid mentioning
these things, is to simply explain them and to give the beginner a tool
(the listing file) by which he or she might be able to explore both
these and many other things, including looking at assembly generated by
HLLs. Approached that way, the user learns not simply about one
particular assembler but about how to learn ANY new assembler. I'm
quite certain that the latter is far more valuable and interesting to learn.
> Obviously, it's a minority opinion.
Minority or majority don't matter much to me. The majority is often wrong.
[code snipped]
>> Which do you think is smaller?
> A question of fact - doesn't matter what I think.
It does in that if you're using the numeric form because you think it's
smaller. It's not really so a much a question about the particular code
sizes but about perceptions. It's a little like one of those "guess how
many gumballs in this jar" contests -- it too is a question of fact and
not opinion, but one can learn from the process by attempting to guess
and then matching the guess to the actual number.
>> Which do you think would be easier to modify without error?
>
> Now *that's* a matter of opinion. It's fairly obvious in the "non-macro"
> version that if I do "mov ebp, [width]", kaboom!
That's true, but the kaboom would occur with a nice neat assembler
message saying:
**Error** foo.asm(10) Undefine symbol:WIDTH
It tells you exactly what and where the problem is.
On the other hand, what happens if you accidentally typed [esp+18+20h]
instead of [esp+16+20h]? It would assemble and link just fine, and
you'd have no indication of a problem until you actually try to run the
code. Even then, you'd have no indication about where the problem is,
or where to start debugging. As interested as I am in making machines
run as fast as they're potentially capable of going, I'm also interested
in allowing programmers to go as fast as they're potentially capable of
going.
> Whether this is obvious
> in the "proc" case depends on how well I understand what "proc" does, I
> guess.
Also true. So why would you not want to understand it well? ;-)
>> Which is easier to read and understand?
>
> Again, "in the eye of the beholder". As someone who learned on an
> assembler that doesn't do "proc", and having to translate examples that
> use "proc" I can state as a fact that *I* find the "explicit" version
> much easier to understand. YMMV.
I think you'll find that it's about the same for tiny programs but gets
to be a very big difference for bigger programs. All of those "magic
numbers" lying around get to be a pain even earlier.
>> Maybe, but apparently not as well as the assembler. Note that the
>> third mov instruction above actually uses esp instead of ebp. Since
>> there's a one-byte penalty for using the esp-referenced version, and
>> esp and ebp are equal here, I'd conclude that this was simply an error
>> on the part of the programmer -- an error that would not have occurred
>> had he used the PROC style I demonstrated.
>
> Ya got us dead to rights on this one. Good catch! Avoiding typos like
> this (I assume it was unintentional) is a point in favor of using
> macros, no question.
Technical note -- only in NASM is "PROC" a macro. Most other assemblers
have it as a keyword since there are things one simply can't do with a
macro.
> I still feel I'd rather see the code "right in
> front of my face", but that's just my opinion (and there are cases where
> I *would* prefer a macro).
That's what a listing file is for. Once you've got the macro debugged
and working, you can simply use it and not have to worry about it. One
of the first things an apprentice blacksmith makes is some of his own
tools that he can then use. Programmers would do well to emulate that,
IMHO. How many times have you seen newbie post code asking "what's
wrong with this program?" only to learn that they were calling int 21
instead of int 21h? IMHO, beyond the first time, making that particular
error ceases to be instructive.
> Thanks for looking at that code, Ed. I always learn something from you,
> even when we disagree! :)
And I learn things from you, as well. That's the way usenet is supposed
to work, IMHO!
Ed
Alan Connor
Well, I searched a lot of posts to find an actual intelligent critique of the
Art of Assembly Language (in English :-)
Want to pick up C (coming from a pretty good shell-scripting background)
but It seems like the best place to start is here. For all I know its
the the place to stay too.
So I will delete "the Art of..." and need to ask what primer is available to
take its place?
I run Linux with an 8086 processor and have as86 installed for the C compiler
and could easily install NASM.
It seems obvious that it is the TASM faq that that should be used for NASM,
and MASM for as86 (the manpage emphasizes it's M$ leanings.)
Is that right?
--
Alan C this post ends with w
q
Randall Hyde
"Betov" <be...@free.fr> wrote in message
>
> The fact that Master Pdf is not that much rejected from a List
> like this one, but, instead admited as a full-right member, only
> shows the competency level of most participants.
You're probably right about this. A good number of the participants
around here achieved their level of competency by reading those PDFs :-)
> Given the actual catastrophic state of Assembly such incoherent
> attitudes will have an heavy cost, as the significative number
> of beginners that will be lost by HLA (added to the ones lost
> by MASM) will have to be substracted from the Assembly Rebirth.
And the sad part is, none of those beginners will really care.
While you go on whining about what is and isn't an assembler, they'll
be too busy writing assembly code, in HLA, to care about your
diatribes.
> Being "Pro-HLA", or even saying that HLA is an Assembler _is_
> working _against_ Assembly.
As defined by you, of course.
>
> I am a bit estonished, that a guy like you, who seems to
> perfectely understand the interresting details of Assembly
> programming, does not seem to understand in what manner the
> programming methods pushed by HLA and master Pdf are nothing
> but Anti-Asm (not talking of the demential syntax -which is
> only a detail problem- not talking of the fact that HLA is
> only a ridiculous and awfuly written Pre-Parser, not talking
> of the real Randall motivations, and so on...).
Most people are astonished that you keep on this anti-HLA,
anti-MASM, anti-not-RosAsm tirade. At some point some
of us are hoping you'll figure out that all your ranting is doing
a lot more damage to this "Assembly Rebirth" you keep talking
about than anything HLA or MASM could ever do.
Cheers, and God Bless,
Randy Hyde
Alan Connor
>
>
>
> "Betov" <be...@free.fr> wrote in message
>
> anti-MASM, anti-not-RosAsm tirade. At some point some
> of us are hoping you'll figure out that all your ranting is doing
> a lot more damage to this "Assembly Rebirth" you keep talking
> about than anything HLA or MASM could ever do.
>
> Cheers, and God Bless,
> Randy Hyde
>
>
The book "The Art of Assembly Languange" is enough to scare anyone away.
"HIgh-Level-Assembler" is an oxymoron.
All things M$ suck.
So what's your problem? :-)
Betov
@newsread2.news.atl.earthlink.net:
> Technical note -- only in NASM is "PROC" a macro. Most other assemblers
> have it as a keyword since there are things one simply can't do with a
> macro.
>
__________________________________________________________
RosAsm Macros:
__________________________________________________________
[Proc | &1=0 | &2=0 | &3= | #1 | push ebp | mov ebp esp]
[ExitP | jmp P9>>]
[Arguments | {#1 Arg#x} | #+1 | &1=SizeOf#x]
[Argument | {#1 Arg#x} | #+1 | &1=SizeOf#x]
[Local | {#1 Local#x} | #+1 | sub esp SizeOf#x | &2=SizeOf#x]
[StrucPtrs | {#3 ebp+#2+#F} | #+2]
[Structure | {#1 ebp-&2-4} | sub esp #2+4 | mov D$#1 esp | StrucPtrs 0-&2-#
2-4 #L>3]
[Uses | push #1>L | &3=pop #L>1]
[EndP | P9: | &3 | mov esp ebp | pop ebp | ret &1]
[Arg1 ebp+8 Arg2 ebp+12 Arg3 ebp+16 Arg4 ebp+20 Arg5 ebp+24
Arg6 ebp+28 Arg7 ebp+32 Arg8 ebp+36 Arg9 ebp+40 Arg10 ebp+44]
[Local1 ebp-4 Local2 ebp-8 Local3 ebp-12 Local4 ebp-16 Local5
ebp-20
Local6 ebp-24 Local7 ebp-28 Local8 ebp-32 Local9 ebp-36 Local10
ebp-40]
[SizeOf1 4 SizeOf2 8 SizeOf3 12 SizeOf4 16 SizeOf5 20
SizeOf6 24 SizeOf7 28 SizeOf8 32 SizeOf9 36 SizeOf10 40]
______________________________________________________________________
; Usage:
Proc MyProc:
Arguments @Param1, @Param2, @Param3...
Local @X, @Y, ...
Structure @ABC 12, abcADis 0, abcBDis 4, abcCDis 8
Uses esi, edi, ...
; Do this
; ....
; .... | ... ExitP
; ...
; Do that
EndP
______________________________________________________________________
Nothing but the difference between an Assembler and a Compiler.
Most guys do not seem to understand what interest, with this.
In fact, i have nothing really against Compilers and against HLL.
Just, in Assembly, this kind of HLL-Like implementations _must_
be under the programmer control. If not this is no more Assembly.
For example, it is much likely that, one day, someone (may be me...)
will write a RosAsm Pre-Parser for enabling all of this stuff
directely trough a statement like:
> PREPARSE HllLike
... in the same way it actually may run the 'Equal' PreParser.
The important point is with saying that, at this point, this is
_not_ Assembly. When a RosAsm user actually writes:
> PREPARSE Equal
>
> ; ...
>
> R$FpuValue = (13.333+5*R$MyReal/((-1.24+F$MyFloat*W$MyWord)/3-(2+D
$MyDWord)))
... it _must_ be evident to him that this is enabled by an HLL
Pre-Parser _HE_ selected, and not at all a default feature of
the _ASSEMBLER_.
When RosAsm will include some 'Basic' Pre-Parser', for example,
the guys runing it will be programming _Basic_ + Asm. Not
Assembly.
Considering beginners, also, having this definition point
declared in full words is very important. Once you know that
MASM users may as well write Asm for one year without making
up their mind that "Invoke" is not a Mnemonic (example known),
how do you think, for example, that the HLA users will ever
know what a Mnemonic is?... Reading AoA32 blabla for a couple
of years?...
Betov.
< http://betov.free.fr/RosAsm >
Ed Beroset
> Ed Beroset <ber...@mindspring.com> wrote in news:NBEpb.4753$9M3.1679
> @newsread2.news.atl.earthlink.net:
>
>
>>Technical note -- only in NASM is "PROC" a macro. Most other assemblers
>>have it as a keyword since there are things one simply can't do with a
>>macro.
> [Proc | &1=0 | &2=0 | &3= | #1 | push ebp | mov ebp esp]
>
> [ExitP | jmp P9>>]
>
> [Local | {#1 Local#x} | #+1 | sub esp SizeOf#x | &2=SizeOf#x]
>
> [Uses | push #1>L | &3=pop #L>1]
>
> [EndP | P9: | &3 | mov esp ebp | pop ebp | ret &1]
>
> [Arg1 ebp+8 Arg2 ebp+12 Arg3 ebp+16 Arg4 ebp+20 Arg5 ebp+24
> Arg6 ebp+28 Arg7 ebp+32 Arg8 ebp+36 Arg9 ebp+40 Arg10 ebp+44]
[...]
> Nothing but the difference between an Assembler and a Compiler.
>
> Most guys do not seem to understand what interest, with this.
Here's what I understand about your macros. They do not:
1. make any symbol table differentiation between a label and a proc
2. handle 16-bit code
3. handle 16-bit args
4. interface with languages other than C
5. allow for the omission of a stack frame when no args are passed
Also, it appears that with a hardcoded label P9: in the EndP macro,
you'd either have to contend with duplicate labels somehow or to use a
different macro for each procedure. Neither makes any technical sense,
however, so perhaps you've got some kind of auto-incrementer for that
label that is not shown. Perhaps you're unaware of how MASM, for
instance, handles PROC and didn't know about these differences, just as
I don't know how your assembler handles P9.
> In fact, i have nothing really against Compilers and against HLL.
> Just, in Assembly, this kind of HLL-Like implementations _must_
> be under the programmer control.
When I use an assembler, I have complete control because I understand
how it works. I *know* what code is generated when I invoke one of my
macros or use the PROC keyword, just as you *know* that your EndP macro
always inserts a mov esp ebp, pop ebp, ret xx.
> Considering beginners, also, having this definition point
> declared in full words is very important. Once you know that
> MASM users may as well write Asm for one year without making
> up their mind that "Invoke" is not a Mnemonic (example known),
If that's the case, they certainly can't have read the documentation
that comes with the assembler, and so it's not particularly surprising
that there would be some areas they'd not know. What is more
interesting to me, in this instance, is that such a beginner could
apparently sucessfully write assembly code for a year without having
read any of the documentation! It's an amazing success.
> how do you think, for example, that the HLA users will ever
> know what a Mnemonic is?... Reading AoA32 blabla for a couple
> of years?...
I think that instead of worrying over what HLA users will and will not
learn, you might better concentrate on what you learn and what you can
teach others. Posting code as illustration and making technical
comments on other people's posted code would be a better way to do that
than to perpetually whine about other people's work. But that's just
my opinion.
Ed
Alan Connor
>
>
>
> In alt.lang.asm, Msg ID: <3HHpb.6833$qh2...@newsread4.news.pas.earthlink.net>
> Alan Connor <zzz...@xxx.yyy>, wrote:
>
>
>>The book "The Art of Assembly Languange" is enough to scare anyone away.
>
> (IBM/M$oft circa 1984)
> Which explains in pretty good detail the STRUC pseudo op.
Whatever THAT is ....
>
>>"HIgh-Level-Assembler" is an oxymoron.
>>
>>All things M$ suck.
>>
>>So what's your problem? :-)
> Sounds like dejavu all over again. :)
> --
> Ray
<chuckles>
Betov
> [...]
> Here's what I understand about your macros. They do not:
> 1. make any symbol table differentiation between a label and a proc
> 2. handle 16-bit code
> 3. handle 16-bit args
> 4. interface with languages other than C
> 5. allow for the omission of a stack frame when no args are passed
I suspect more and more that you are better unhonest than stupid,
but, just in case you would really not know,
* RosAsm is a PE Assembler and PEs are 32 Bits.
* In 32 Bits Mode, the Stack must remain 4 Bytes aligned.
* I don't work to serve the soupe for C, or anything else, and
the only purpose of RosAsm is to output Applications.
* Asm Programmers are supposed to know, or to learn, when
to make use of such Macros and when to make use of a regular
Labelled Routine.
> Also, it appears that with a hardcoded label P9: in the EndP macro,
> you'd either have to contend with duplicate labels somehow or to use a
> different macro for each procedure. Neither makes any technical sense,
> however, so perhaps you've got some kind of auto-incrementer for that
> label that is not shown [...]
Simply A86-like Local Labels. If this does not "make any technical
sense" for you, and if you realy don't understand, you just have to
count how many 'EndP's in RosAsm Source... and yes, "P9:" is "P9:".
>> In fact, i have nothing really against Compilers and against HLL.
>> Just, in Assembly, this kind of HLL-Like implementations _must_
>> be under the programmer control.
>
> When I use an assembler, I have complete control because I understand
> how it works. I *know* what code is generated when I invoke one of my
> macros or use the PROC keyword, just as you *know* that your EndP macro
> always inserts a mov esp ebp, pop ebp, ret xx.
_You_... Maybe. Though, if i remember, this was you, one day i
wrote that MASM does not output what you write... who asked me
for an example... (at the same time, when i wrote that MASM was,
at least, 20 times slower than the actual Assemblers, you asked
me to prove it...).
>> Considering beginners, also, having this definition point
>> declared in full words is very important. Once you know that
>> MASM users may as well write Asm for one year without making
>> up their mind that "Invoke" is not a Mnemonic (example known),
>
> If that's the case, they certainly can't have read the documentation
> that comes with the assembler, and so it's not particularly surprising
> that there would be some areas they'd not know. What is more
> interesting to me, in this instance, is that such a beginner could
> apparently sucessfully write assembly code for a year without having
> read any of the documentation! It's an amazing success.
Absurde logic. Not even funny.
>> how do you think, for example, that the HLA users will ever
>> know what a Mnemonic is?... Reading AoA32 blabla for a couple
>> of years?...
>
> I think that instead of worrying over what HLA users will and will not
> learn, you might better concentrate on what you learn and what you can
> teach others. Posting code as illustration and making technical
> comments on other people's posted code would be a better way to do that
> than to perpetually whine about other people's work. But that's just
> my opinion.
I have posted 2 Megas of not so badly working Source Code (RosAsm):
< http://betov.free.fr/RosAsm.html >
... where anyone can also download a 3 megas help file (B_U_Asm.zip)
including an Asm32 Tutorial.
Doing what you suggest would be completely stupid, and surely,
a ridicoulous waste of time. There is no thechnical discussion
possible with unhonest persons.
Betov.
sinewave
> Nothing but the difference between an Assembler and a Compiler.
OPTION PROLOGUE:None
OPTION PROLOGUE:macroname
OPTION EPILOGUE:None
OPTION EPILOGUE:macroname
> MASM users may as well write Asm for one year without making
> up their mind that "Invoke" is not a Mnemonic
RosAsm users may as well write asm for one year without making up their
mind that "...If" is not a mnemonic! what a sad day for Assembly. RosAsm is
no more Assembly and in the futur we will kick RosAsm out on their nazi
azzes. Rene is a swindler and a sh*t seller! see how ridiculous you sound?
sinewave
> I suspect more and more that you are better unhonest than stupid,
Ed is neither dishonest nor stupid.
>> When I use an assembler, I have complete control because I
>> understand how it works. I *know* what code is generated
exactly.
>> Posting code as illustration and making technical comments on other
>> people's posted code would be a better way to
>> do that than to perpetually whine about other people's work.
LOL.
> Doing what you suggest would be completely stupid, and surely,
> a ridicoulous waste of time. There is no thechnical discussion
> possible with unhonest persons.
TRANSLATION: Ed is too smart to argue with so i'll just insult him, tuck
tail, and run.
hutch--
I have pretty straight forward ideas about using the PROC capacity of
assemblers like MASM and TASM and it has to do with the
differentiation of the type of code being written. Particularly in
Windows there is a lot of "hack" code to get up and going that
interacts with the operating system that cannot be classed as worth
much more effort than getting it going reliably.
Manually coding a stack frame is one of those things that most people
can do but rarely ever bother as it is slow and unreliable,
particularly when dealing with high level code like Windows API
function calls. I am yet to see the point of saving a nanosecond or
two manually coding the fastest MessageBox on the planet when its
performance simply does not matter.
High level emulation is a very useful thing in assembler coding as it
removes much of the time taken to write non critical code and it is
here where macros, library modules and the intrinsic capacity built
into the assembler make this style of coding possible. I am just
finishing off a set of library modules and macros that interact with
MASM's invoke and other high level emulation to write code that looks
and runs much like standard basic.
mov str1, lcase$(left$(lpString),8))
invoke SetWindowText, hWnd, str1
Being able to do the junky stuff quickly means that a lot more time
can be spent on time critical code, algorithm design and better
architecture, all of thiose things that make software smaller, faster
and more reliable.
Regards,
hutch at movsd dot com
Frank Kotler
>> Well... I guess all I can say is that I disagree. Teaching beginners
>> to use a macro that may or may not generate additional code, or alter
>> the code I wrote, seems like a bad idea to me.
>
> Are you going to tell beginners not to use jnc? Perhaps you should,
> since, depending on the distance to the target, a number of different
> encodings could be used.
Well, if these beginners are using Nasm, I'd have to explain to 'em that
if they want the near form, they'll have to specify "near"... or use the
"-O" switch (which I might *not* show 'em, just yet). Nasm defaults to
"short" on conditional jumps - kind of a PITA, I suppose, but at least
they learn that there *are* two forms... (it's the signed and unsigned
forms that seem tough to "get")
This seems like a different level of "behind-your-back-ism" than what
the PROC "keyword" will do... or not do... depending on whether there
are parameters or locals, and what ".model" is specified.
> Better, I think, than to just avoid mentioning
> these things, is to simply explain them and to give the beginner a tool
> (the listing file) by which he or she might be able to explore both
> these and many other things, including looking at assembly generated by
> HLLs. Approached that way, the user learns not simply about one
> particular assembler but about how to learn ANY new assembler. I'm
> quite certain that the latter is far more valuable and interesting to
> learn.
Well learning "how to learn any new assembler" is certainly a good idea!
I've never been that impressed with listing files, and I just figured
out *why*. It's *because* I tend not to use macros or "keywords" - the
source part of the listing file just duplicates what I wrote. And
because I mostly work with .com files, they're easy to disassemble, if I
want to "count gumballs" or otherwise see what's being generated. I can
see that if the assembler isn't producing what's showing in the source,
either because of error, or because I'm using "constructs that generate
more code than is showing" ("macros" or "keywords"), then a listing file
would become much more valuable.
>> Obviously, it's a minority opinion.
>
> Minority or majority don't matter much to me. The majority is often wrong.
Yeah, but when you and Randy are in that majority, the odds decrease :)
> [code snipped]
>
>>> Which do you think is smaller?
>
>> A question of fact - doesn't matter what I think.
>
> It does in that if you're using the numeric form because you think it's
> smaller.
Well, no. The snipped code used a stackframe (but without using PROC) -
in this case, using "named parameters" would be the same size. Since
Guillermito arguably put the "pusha" in the "wrong place", the magic
numbers are weird, so I don't think PROC would work unless that were
changed, but they could be defined or "equ"ed in some way, and probably
should have been. The case where he really doesn't want the stack frame
is his wndproc - he indexes off esp (twice, so it *is* smaller, I
think), and he does the "trick" of popping the return address (into a
static variable) so he can call "DefWindowProcA" without having to
reload the stack with what's already on it. (something I wouldn't show a
beginner either, except of an example of a "dirty trick")
> It's not really so a much a question about the particular code
> sizes but about perceptions.
Well, I'll admit that I'm a little surprised to see how quickly those
one byte penalties "catch up" to a full stack frame...
> It's a little like one of those "guess how
> many gumballs in this jar" contests -- it too is a question of fact and
> not opinion, but one can learn from the process by attempting to guess
> and then matching the guess to the actual number.
I never was any good at that :)
>>> Which do you think would be easier to modify without error?
>>
>> Now *that's* a matter of opinion. It's fairly obvious in the
>> "non-macro" version that if I do "mov ebp, [width]", kaboom!
>
> That's true, but the kaboom would occur with a nice neat assembler
> message saying:
>
> **Error** foo.asm(10) Undefine symbol:WIDTH
>
> It tells you exactly what and where the problem is.
Well, that wasn't the error I had in mind. I was a little confused
between something Beth did in some HLA code she posted, and what
Guillermito was doing. I was thinking that he passed parameters on the
stack, but indexed 'em off esp rather than a stack frame in order to
free up ebp to be used for "width" (which he does do, but in a different
place). What I meant to get across was that "PROC" doesn't put the fact
that you don't want to alter ebp "in front of your face". "enter" and
"leave" don't mention ebp, either, of course. I'd start off by walking a
beginner through "push ebp"/"mov ebp, esp" explicitly, I think, rather
than hiding why you don't want to touch ebp.
> On the other hand, what happens if you accidentally typed [esp+18+20h]
> instead of [esp+16+20h]?
You don't have to do the shift to convert for the fixed-point? No,
seriously, we're screwed by a typo like that...
...
> As interested as I am in making machines
> run as fast as they're potentially capable of going, I'm also interested
> in allowing programmers to go as fast as they're potentially capable of
> going.
Really good point! If we accept that "development in asm is horribly
slow", it will be true. An asm programmer needs to use PROC and other
macros/keywords - and no doubt some home-made tools (some perhaps made
special for this program) - when writing "production code". Beginners
need to learn to walk before they run so fast, IMO. Now some people feel
that providing macros, keywords, or library routines is the way to help
beginners "walk" (in classroom settings where time is limited, it may be
neccessary). I'd rather start 'em off with the "raw" code, so they know
what PROC is *doing* before they start using it.
>> Whether this is obvious in the "proc" case depends on how well I
>> understand what "proc" does, I guess.
>
> Also true. So why would you not want to understand it well? ;-)
Because I want to see what my code is doing in the source file, without
having to open a listing file? :)
>>> Which is easier to read and understand?
>>
>> Again, "in the eye of the beholder". As someone who learned on an
>> assembler that doesn't do "proc", and having to translate examples
>> that use "proc" I can state as a fact that *I* find the "explicit"
>> version much easier to understand. YMMV.
>
> I think you'll find that it's about the same for tiny programs but gets
> to be a very big difference for bigger programs.
Well, I see two issues here. "Understanding it once" and "keeping track
of what "ebp + 20h" actually *means* in each instance. In bigger
programs, I agree completely that PROC is appropriate.
> All of those "magic
> numbers" lying around get to be a pain even earlier.
Right. I'd show a beginner an example with the magic numbers in place,
explain why that can get to be a problem (if it isn't obvious), show 'em
"%define firstparam ebp + 8" (could include the square brackets here
too, if you want the access to look more like M/Tasm syntax - "mov eax,
firstparam" - I prefer "mov eax, [firstparam]" - more "Nasmesque"), and
*then* explain that PROC will do that for them automatically, and how to
use it. (in the case of Nasm, which file to include has to be part of it
- the "flexibility" this allows has its price)
...
> Technical note -- only in NASM is "PROC" a macro. Most other assemblers
> have it as a keyword since there are things one simply can't do with a
> macro.
Okay (I'm not sure about "only", or even "most", but for Masm/Tasm).
It's not an "instruction", in any case. It's a "construct that generates
more code than I wrote" (and does more than just generate code - keeps
some assemble-time variables for us). I understand that it *does* make a
difference whether it's implemented "built in" or as an external macro
like Nasm. Nasm - as a design decision by the Original Authors -
foregoes the advantages of the "built in" approach. This offers
flexibility - I got got into this discussion mentioning a macro that
"auto-generated" the magic numbers and allowed us to use named
parameters and locals *and* index off esp (frees up ebp, even if it
isn't any smaller) - but this has a down-side, too - it matters *which*
"proc" you're using. (now that I look closer, this macro wouldn't help
either Beth or Guillermito... never mind...)
>> I still feel I'd rather see the code "right in front of my face", but
>> that's just my opinion (and there are cases where I *would* prefer a
>> macro).
>
> That's what a listing file is for.
Why not write it that way in the source file? Understand I'm talking
about small "example" files - you wouldn't do it in "production code",
or even a "serious project".
> Once you've got the macro debugged
> and working, you can simply use it and not have to worry about it. One
> of the first things an apprentice blacksmith makes is some of his own
> tools that he can then use. Programmers would do well to emulate that,
> IMHO.
Oh, were we talking about having the beginner *build* his/her own PROC?
I'll go along with that! Using the "pre-built" tool is what I'm saying
the beginner shouldn't do until until he/she understands what the tool
*is* (by building one, or some other way).
> How many times have you seen newbie post code asking "what's
> wrong with this program?" only to learn that they were calling int 21
> instead of int 21h? IMHO, beyond the first time, making that particular
> error ceases to be instructive.
Okay, ya got me on that one. Maybe if I make the error *enough* times
it'll instruct me to actually *use* "dos_int". I agree on this one, but
I *still* prefer to see the "int 21h" (right there where I wrote it!)
>> Thanks for looking at that code, Ed. I always learn something from
>> you, even when we disagree! :)
>
> And I learn things from you, as well. That's the way usenet is supposed
> to work, IMHO!
As Mahatma Ghandi said when asked his opinion of Western Civilization:
"I think it would be a good idea!" :)
Best,
Frank
The Half A Wannabee
"sinewave" <no...@nowhere.com> wrote in message
news:oprx4w9q...@10.0.0.1...
>
> > Nothing but the difference between an Assembler and a Compiler.
>
> OPTION PROLOGUE:None
> OPTION PROLOGUE:macroname
> OPTION EPILOGUE:None
> OPTION EPILOGUE:macroname
>
> > MASM users may as well write Asm for one year without making
> > up their mind that "Invoke" is not a Mnemonic
>
> RosAsm users may as well write asm for one year without making up their
> mind that "...If" is not a mnemonic!
But I read about it in the manual on the first two hours. I was writing my
first assembler only app after reading the documentation :
I read the SpasmHelp file and Iczellion tutorials. 2 - 3 hours. And after
that I was ready to program a simple window app. It was very exiting and
maybe a litle embarissment to me that it was really that easy. Heck Delphi
code is sometimes more of a clutter to write than Spasm is. And even after
years you never really know what you are doing (exactly). Tasm was a monster
in comparison to Spasm. It had (a) manual(s) that was increadably long, and
the way it was written makes it boring, a pain really to read. Whatever you
say about Spasm, its easy to get started with, and the code is easy to
understand. Also its all there. Putting related asm instructions on the same
line is readable to a much higher extent than HLA code I have seen. Doesnt
seems like such a genious stunt, its so simple isnt it, but it works and is
in fact a litle genious after all. Spasm is in itself a very strong document
on assembly for a beginner, and some of the example code that follows it is
brilliantly easy to follow. Like the DirectX tuts. I do not much care about
what Betov says about C. They can take it. Its just humour I think. Just
like some of you excellent remarks in here earlier. And if you subract the
faul language, it true in every sence. I care about what Spasm has become
and for what it may become in the future. For a beginner it is very good.
And thats the point. THAT IS THE POINT. To flood an assembler language with
any or all the programming consepts available, is not good for beginners. It
makes it look like a monsterous accomplishment to know it. You feel beaten
before you ever get to start with it.
The only reason I put Spasm on hold, is that I have yet not completed my
other work in Delphi. I want it OK and completed after a plan. Then I will
not use Delphi anymore, but either Spasm or some other tool that will force
me to think in assembler. Looks to me sofar that Spasm is my best choice.
Cause I WANT to do it all by myself. I dont want to have to be forced to do
it like every other people. I can spot most Delphi apps from how they look.
I see a program and I know, that one is borland RAD product. Delphi has its
good sides, but it is also a language that has no focus. It spread itself
between BASM, Generic window application programming, Point and click RAD
programming, and COM programming. Its very capable, but also a monster.
Spasm is a spesific assembler. More to the point. It teaches assembler. Just
as is its purpose. Not to be the most capable or flooded with features
language there is. The programmer can create thoose features himself if he
needs them. As shown with clear simplistic and excellent examples. I think
at least the philosofy as written in the manuals are true to the task at
hand, learning assembly for a beginner.
Randall Hyde
"The Half A Wannabee" <Shaka...@hotmail.com> wrote in message news:3fa86d38$1...@news.broadpark.no...
>
> But I read about it in the manual on the first two hours.
And you don't read about such things in the MASM manual or
the Art of Assembly?
How about from Chapter One of AoA, before an IF statement is ever
mentioned:
"Before discussing these high level control structures, it's important to
point out that these are not real 80x86 assembly language statements.
HLA compiles these statements into a sequence of one or more real
assembly language statements for you. Later in this text, you'll learn
how HLA compiles the statements and you'll learn how to write pure
assembly language code that doesn't use them. However, you'll need
to learn many new concepts before you get to that point, so we'll stick
with these high level language statements for now since you're probably
already familiar with statements like these from your exposure to high
level languages. "
If, as Rene claims, people go a year without understanding that statements
like "IF" are not real assembly language statements, then their problem is
that they didn't bother to read the very *first* chapter of AoA.
> I was writing my
> first assembler only app after reading the documentation.
Well, you are an assembly God, right up there with Rene.
You should be very proud of yourself. Most people are not capable
of writing assembly "apps" within a few hours of reading the
assembler documentation. Of course, it depends on what you call
an "app", I suppose. Care to post the code for all to see?
> I read the SpasmHelp file and Iczellion tutorials. 2 - 3 hours. And after
> that I was ready to program a simple window app.
Heck, I was *ready* to write a Windows app *before* reading the
tutorials. But being ready and and being able to write decent apps
are two different things. Now if you're claiming you were actually
*writing* Windows apps after reading SpAsm and Iczelion's
documentation for 2-3 hours, then you are *truly* an assembly God.
After writing three books on the subject and having 20 years'
programming experience, I must admit that it took me a bit more
than 2-3 hours study before I was writing anything I'd be willing
to call a Windows app (on my own, as opposed to hacking up
an existing program).
> It was very exiting and
> maybe a litle embarissment to me that it was really that easy.
You are *truly* an assembly God.
What you've got to realize is that the rest of the population simply
doesn't have the genious qualities you seem to possess. For them,
your approach just doesn't work too well.
> Heck Delphi code is sometimes more of a clutter to write than Spasm is.
> And even after years you never really know what you are doing
> (exactly). Tasm was a monster
> in comparison to Spasm. It had (a) manual(s) that was increadably long, and
> the way it was written makes it boring, a pain really to read.
Then again, when you needed to figure something out, it sure was nice to
have those manuals.
> Whatever you
> say about Spasm, its easy to get started with, and the code is easy to
> understand. Also its all there. Putting related asm instructions on the same
> line is readable to a much higher extent than HLA code I have seen.
??????
Putting multiple statements on a line is one of those *big* style violations
that most people learn *not* to do early in their programming careers.
How long did you say you've been programming *professionally* in
Delphi? (E.g., part of a team, where you code gets reviewed by other
team members?). But if you really want to write such ugly code, what
gave you the impression that HLA doesn't allow this?
> Doesnt
> seems like such a genious stunt, its so simple isnt it, but it works and is
> in fact a litle genious after all. Spasm is in itself a very strong document
> on assembly for a beginner, and some of the example code that follows it is
> brilliantly easy to follow.
Except there are no tutorials for SpAsm available, just a disorganized
"help" file written by a non-native English speaker; you can't even print
the thing out and read it off-line. I'm happy you like it so much and it's
great that *some* people out there really like this kind of documentation,
but your experiences are hardly typical.
> Like the DirectX tuts. I do not much care about
> what Betov says about C. They can take it. Its just humour I think. Just
> like some of you excellent remarks in here earlier. And if you subract the
> faul language, it true in every sence. I care about what Spasm has become
> and for what it may become in the future. For a beginner it is very good.
> And thats the point. THAT IS THE POINT. To flood an assembler language with
> any or all the programming consepts available, is not good for beginners. It
> makes it look like a monsterous accomplishment to know it. You feel beaten
> before you ever get to start with it.
????
Yes. I agree 100%. That's why AoA uses the concepts they already know.
Things like IFs, WHILEs, and so on.
"Leverage their existing knowledge" works very well for most people.
> The only reason I put Spasm on hold, is that I have yet not completed my
> other work in Delphi. I want it OK and completed after a plan. Then I will
> not use Delphi anymore, but either Spasm or some other tool that will force
> me to think in assembler. Looks to me sofar that Spasm is my best choice.
> Cause I WANT to do it all by myself. I dont want to have to be forced to do
> it like every other people. I can spot most Delphi apps from how they look.
> I see a program and I know, that one is borland RAD product. Delphi has its
> good sides, but it is also a language that has no focus. It spread itself
> between BASM, Generic window application programming, Point and click RAD
> programming, and COM programming. Its very capable, but also a monster.
> Spasm is a spesific assembler. More to the point. It teaches assembler. Just
> as is its purpose. Not to be the most capable or flooded with features
> language there is. The programmer can create thoose features himself if he
> needs them. As shown with clear simplistic and excellent examples. I think
> at least the philosofy as written in the manuals are true to the task at
> hand, learning assembly for a beginner.
Well, I'm looking forward to all the great Delphi and SpAsm applications
you're going to produce for us. I think it's wonderful that the world now
has another certified "assembly God" who will be cranking out killer applications
using assembly language.
I must admit though, your posts sound more like troll-bait and it will be
interesting to see if you ever really *will* produce anything with RosAsm/SpAsm.
You would gain a lot more credibility, quite frankly, if you were to list the
serious Delphi applications you've created and discuss how you're going to
write such apps in assembly. No offense, but the boasts you're making are
quite empty; you've provided no backing for them whatsoever at all.
You spout the same nonsense that Rene does; Rene, however, has actually
written a *real* application, can you make the same claim?
Cheers,
Randy Hyde
Randall Hyde
"Betov" <be...@free.fr> wrote in message news:Xns9429DD5BCD...@213.228.0.136...
> Ed Beroset <ber...@mindspring.com> wrote in
> news:3oMpb.7345$Oo4....@newsread1.news.atl.earthlink.net:
>
>
> > [...]
> > Here's what I understand about your macros. They do not:
> > 1. make any symbol table differentiation between a label and a proc
> > 2. handle 16-bit code
> > 3. handle 16-bit args
> > 4. interface with languages other than C
> > 5. allow for the omission of a stack frame when no args are passed
>
> I suspect more and more that you are better unhonest than stupid,
> but, just in case you would really not know,
>
> * RosAsm is a PE Assembler and PEs are 32 Bits.
>
> * In 32 Bits Mode, the Stack must remain 4 Bytes aligned.
Strictly speaking, this is not true.
If you make in Win32 calls the stack must be dword aligned,
but in between those points I haven't had any difficulties with
having the stack word-aligned on a temporary basis, e.g.,
pushw( 0 ); // Stack is now word-aligned.
push( ax ); // Back to dword aligned.
Who knows, maybe I've just been lucky. But the system
doesn't fault when you do this.
>
> * I don't work to serve the soupe for C, or anything else, and
> the only purpose of RosAsm is to output Applications.
That call C code (e.g., the Win32 API).
> * Asm Programmers are supposed to know, or to learn, when
> to make use of such Macros and when to make use of a regular
> Labelled Routine.
Asm Programmers are supposed to know when to use PROC and
when to use labelled subroutines. They're supposed to know what
INVOKE does. And they're supposed to know the difference
between "IF" (in any form) and CMP/Jcc.
What was your point again?
>
> _You_... Maybe. Though, if i remember, this was you, one day i
> wrote that MASM does not output what you write... who asked me
> for an example... (at the same time, when i wrote that MASM was,
> at least, 20 times slower than the actual Assemblers, you asked
> me to prove it...).
And we're still waiting. Not for you to find *one* example where
MASM is 20 times slower than these other assemblers, but for you
to show us that *on the average* MASM is 20 times slower.
As you've seen already, I can show that MASM is *much* faster
than all these other assemblers if you want to talk special cases.
>
>
> >> how do you think, for example, that the HLA users will ever
> >> know what a Mnemonic is?... Reading AoA32 blabla for a couple
> >> of years?...
> >
> > I think that instead of worrying over what HLA users will and will not
> > learn, you might better concentrate on what you learn and what you can
> > teach others. Posting code as illustration and making technical
> > comments on other people's posted code would be a better way to do that
> > than to perpetually whine about other people's work. But that's just
> > my opinion.
>
> I have posted 2 Megas of not so badly working Source Code (RosAsm):
Although in earlier posts you claim that you don't bother fixing a lot of
defects in RosAsm because they're not that important. Some people
would claim that you've posted 2 Megas of badly working Source Code
based on your previous posts :-)
> Doing what you suggest would be completely stupid, and surely,
> a ridicoulous waste of time. There is no thechnical discussion
> possible with unhonest persons.
cop-out :-)
Cheers,
Randy Hyde
Randall Hyde
"Alan Connor" <zzz...@xxx.yyy> wrote in message news:3HHpb.6833> The book "The Art of Assembly Languange" is enough to scare
anyone away.
>
> "HIgh-Level-Assembler" is an oxymoron.
>
> All things M$ suck.
>
> So what's your problem? :-)
Ah yes, another troll enters the fray.
And, might I ask, what are *your* qualifications
for making such a far-reaching statement?
Cheers,
Randy Hyde
sinewave
IMO RosAsm has great syntax and is fast! Rene should talk about this
instead of glorifying his [pseudo] "enemies" by talking about them
incessently. FWIW take a look at FASM.
regards,
phil
Alan Connor
None. I am just qualified in these circumstances to be a wise ass.
Do you always call someone a "troll" after one post on a subject, when
you know nothing about them?
That's the sort of behavior I usually associate with trolls.
Or someone who doesn't want his position on something debated/examined.
What you have just given me is one more reason to look skeptically at HLA.
NASM is looking like the likely choice at this point.
--
Alan C
190181561530510167504851001120157141576325239965082176698065256566179322
373456081065818179209174628160962909841841937313789496217513296272010217
209392475825562305791988383018411010612843283632898619292370726287156631
The Half A Wannabee
The Half A Wannabee
"Randall Hyde" <rand...@earthlink.net> wrote in message
news:PD_pb.230$Z25...@newsread4.news.pas.earthlink.net...
>
> "The Half A Wannabee" <Shaka...@hotmail.com> wrote in message
news:3fa86d38$1...@news.broadpark.no...
> >
> > But I read about it in the manual on the first two hours.
>
> And you don't read about such things in the MASM manual or
> the Art of Assembly?
Oh its you again ? This was not an attack, not on the person I replied to,
and not on you or on your HLA.
I thought you wore tired of me ? Let me be more spesific.
I have got nothing againts HLA. Unlike Rene. I have no problem at all with
it. I dont know it. Even if I did I might like it. I dont know.
About the only code I ever saw from HLA was "mov (sourceregister,
destinationregister)". A bit confusing, since I learned it the other way
around. But I am sure you have your well defined reasons for doing so.
(Thats not giong to ensure that everyone likes it, even if theese reasons
are well founded). Pluss the bits you posted in a thread some time not so
long ago. I thought it looked terribly difficult. But thats me. I am a
beginner, so I cannot imidiatly have my brain wrapped around functions in
functions in functions in parantesis and espesially not in asm. My head just
tilted. I am stupid, so be it. So I made some smart remarks about it. Sorry.
The AoA is a great book. I have read it before, parts of it, and I will
surely be reading it again. Wonderful work the parts I read. The history
part was espesially joyful to read, with lots of info I never seen
elsewhere. Enjoyable. The parts about dos interrupts etc that I read in
there explained lots of stuff I only which I knew about many years before,
when I used Norton commander on a 286. But its perhaps removed from the
later work ? I have so many things on my shedule. But I will get around to
it, once I get tired from hanging out talking in this forums, and exploring
the internet with my 2mbit only a month old new toy. I am doing a catchup
from 5 years of only part time internet connection. I am a hungry usenet
junkie. I got to get myself some starting kicks first.
>
> How about from Chapter One of AoA, before an IF statement is ever
> mentioned:
> "Before discussing these high level control structures, it's important to
> point out that these are not real 80x86 assembly language statements.
> HLA compiles these statements into a sequence of one or more real
> assembly language statements for you. Later in this text, you'll learn
> how HLA compiles the statements and you'll learn how to write pure
> assembly language code that doesn't use them. However, you'll need
> to learn many new concepts before you get to that point, so we'll stick
> with these high level language statements for now since you're probably
> already familiar with statements like these from your exposure to high
> level languages. "
Yes. Bottom down. Its works as well only much slower (for me). I am an
example to the proof of that.
Now I am not sure I got energy left in me to learn the real stuff.
>
> If, as Rene claims, people go a year without understanding that statements
> like "IF" are not real assembly language statements, then their problem is
> that they didn't bother to read the very *first* chapter of AoA.
> > I was writing my
> > first assembler only app after reading the documentation.
>
> Well, you are an assembly God, right up there with Rene.
> You should be very proud of yourself. Most people are not capable
> of writing assembly "apps" within a few hours of reading the
> assembler documentation. Of course, it depends on what you call
> an "app", I suppose. Care to post the code for all to see?
>
I dont really KNOW Spasm/RosAsm either. I only gave my impressions of it.
And from a asm beginners standpoint it made sense to me.
Thats about all I tried to say. In too many words perhaps. But that was it.
I looked at the source code, amoung the things I looked at was the
implementation of the memory allocations, back then allmost two, maybe 3
years ago(?). I found a small bug in the ask macro. It has since then been
corrected. Totally rewritten the last time I (peeked would be more
accurate). Spasm is still in development (RosAsm) and its not completed
yet(LTIC). My simple program tested for the bug by allocating a huge amount
of memory in the initialization code, and free it in the
OnRightMouseButtonClick (to speak Delphi). Not much of a program, true. This
I did to test if the memory wore freed correctly by code while the app was
running, and not only freed on exit (by the OS itself). As far as my test
went, it seemed to me to be a bug. Which is not a big thing, after all in a
huge work like that its rare to find that all code is bugfree by the hands
of one single man. totally forgivable. And its has since then been
rewritten. My point is, it was not even hard to find this bug, cause the
code is absolutely readable, even for a beginner in assembly.
> > I read the SpasmHelp file and Iczellion tutorials. 2 - 3 hours. And
after
> > that I was ready to program a simple window app.
>
> Heck, I was *ready* to write a Windows app *before* reading the
> tutorials. But being ready and and being able to write decent apps
> are two different things. Now if you're claiming you were actually
> *writing* Windows apps after reading SpAsm and Iczelion's
> documentation for 2-3 hours, then you are *truly* an assembly God.
No I am not. But remember I come from windows programming for 10 years. The
transition to Spasm was easy since the API I allready know a little about.
> After writing three books on the subject and having 20 years'
> programming experience, I must admit that it took me a bit more
> than 2-3 hours study before I was writing anything I'd be willing
> to call a Windows app (on my own, as opposed to hacking up
> an existing program).
>
That was in fact what I did. A window messageloop I have written so many
times, that I didnt need the exercise, and the spasm messageloop make much
more sense then C code doing the same thing. I would say about 10 times as
much sense.
>
> > It was very exiting and
> > maybe a litle embarissment to me that it was really that easy.
>
> You are *truly* an assembly God.
> What you've got to realize is that the rest of the population simply
> doesn't have the genious qualities you seem to possess. For them,
> your approach just doesn't work too well.
>
I can tell you right now, that I am no assembler anything. I have (as stated
earlier) only been flirting with it on occations. It never got to be second
nature to me in any sence. I intend however to change things around a bit.
Since now spasm makes fulllblown application assembler writing that much
easier than I thought.
> > Heck Delphi code is sometimes more of a clutter to write than Spasm is.
>
> > And even after years you never really know what you are doing
> > (exactly). Tasm was a monster
> > in comparison to Spasm. It had (a) manual(s) that was increadably long,
and
> > the way it was written makes it boring, a pain really to read.
>
> Then again, when you needed to figure something out, it sure was nice to
> have those manuals.
Yes, perhaps. But they teach you a lot of keywords and ways to create
segments and stuff thats just boring to a beginner eager to get up and
running. Its surely (I suspect) lots of tools there for sesoned assembler
programmers working on huge projects, but for a beginner still having to
look up certain asm memonics, its just to much to take in all at once. The
Tasm manual I got from my brother, now allmost 10 years ago, had pages of
pages of references to material I didnt have a clue what ment. And that I
never saw again ever, either in Spasm or in Basm.
>
> > Whatever you
> > say about Spasm, its easy to get started with, and the code is easy to
> > understand. Also its all there. Putting related asm instructions on the
same
> > line is readable to a much higher extent than HLA code I have seen.
>
> ??????
> Putting multiple statements on a line is one of those *big* style
violations
> that most people learn *not* to do early in their programming careers.
> How long did you say you've been programming *professionally* in
> Delphi? (E.g., part of a team, where you code gets reviewed by other
> team members?). But if you really want to write such ugly code, what
> gave you the impression that HLA doesn't allow this?
FYI. I never been a professional. And I dont even like the word. But I have
the ability to look at my code from diffrent angles, so
in a certain (a bit wierd maybe) sense, I am a miniteam ;-)
Also when I delivered my first OP code to my pascal teacher, I could see he
was at a loss. When I asked him what
it was worth he told me it would be grade 1, which is the best grade they
have. Now in afterlight, I can see he was wrong.
The code I gave to him was nothing. I quit school later in the semester. I
needed to code. I needed to explore the topic myself.
I code because I love it, because it fits my profile. I am a geek. I
understand that I have to produse something, so that I can
carry my own weight, and that is why, if ever, I will become a
proffessional. Other than that it really carry no significans to me.
I worked alongside with professional IBM, database programmers in 96. Theese
people couldnt even configure or setup the PC they worked on.
But I am steering in all directions here. The Spasm style : Yes to me it
looks very good. push push call, push push call. Heck it even got rythm.
Like music. "And all that jazz".
>
> > Doesnt
> > seems like such a genious stunt, its so simple isnt it, but it works and
is
> > in fact a litle genious after all. Spasm is in itself a very strong
document
> > on assembly for a beginner, and some of the example code that follows it
is
> > brilliantly easy to follow.
>
> Except there are no tutorials for SpAsm available, just a disorganized
> "help" file written by a non-native English speaker; you can't even print
> the thing out and read it off-line. I'm happy you like it so much and it's
> great that *some* people out there really like this kind of documentation,
> but your experiences are hardly typical.
>
Well perhaps your right about that. Only reason I have needed to print out
documentaion was if it was really really hard to follow. Then I need to lie
on my tummy in bed or something and try to penetrate it. But Spasm
documentation is so easy to follow, I never saw a need for it. Besides,
doesnt it come as RTF also now, so you could actually print it if you wanted
to? And if you really wanted to print it you can just hit the print screen
key and load paint and then print it. Or you could hook the canvas with
GetDC and print it out from one of you own applications. Its not that it
cant be done.
>
> > Like the DirectX tuts. I do not much care about
> > what Betov says about C. They can take it. Its just humour I think. Just
> > like some of you excellent remarks in here earlier. And if you subract
the
> > faul language, it true in every sence. I care about what Spasm has
become
> > and for what it may become in the future. For a beginner it is very
good.
> > And thats the point. THAT IS THE POINT. To flood an assembler language
with
> > any or all the programming consepts available, is not good for
beginners. It
> > makes it look like a monsterous accomplishment to know it. You feel
beaten
> > before you ever get to start with it.
>
> ????
> Yes. I agree 100%. That's why AoA uses the concepts they already know.
> Things like IFs, WHILEs, and so on.
> "Leverage their existing knowledge" works very well for most people.
>
Maybe. For me it created an abstraction. A pillow to put my head on. This
pillow was soft and seemed good for a while.
But after some years I incremently understood that programming isnt as
simple as that. Theres is no RAD in programming in the field I like to
flurish. I understood slowly that I had to stop beeing lazy if I would ever
to get anywhere close to my goal, to understand more closely what was going
on, how to write fast code, how to create my own UI etc. Seems to me I would
have spent my energy better in studying the
hard stuff from the beginning, then It wouldnt have been so hard for me to
do it now. then I would use my younger energy to learn assembler
and I could lay my head on a pillow I knew all about in my "older" age.
Hmm. I guess I must have offended you before. It wasnt really my intention.
Maybe I come out to strong ?
You seem angry. I am not. I am having a great time. Maybe its the language.
I am norwegian.
> I must admit though, your posts sound more like troll-bait and it will be
> interesting to see if you ever really *will* produce anything with
RosAsm/SpAsm.
> You would gain a lot more credibility, quite frankly, if you were to list
the
> serious Delphi applications you've created and discuss how you're going to
> write such apps in assembly. No offense, but the boasts you're making are
> quite empty; you've provided no backing for them whatsoever at all.
> You spout the same nonsense that Rene does; Rene, however, has actually
> written a *real* application, can you make the same claim?
> Cheers,
> Randy Hyde
I am working on it as we speak Randy. My page will be uploaded in the next
two to three months and I am NO,
absolutely no genious or anything near as knowledgeable as you. It will be
available with 130K lines of soucecode for
a GDI/DirectX Skin/Game/RAD tool library. Thats my lastest work. When the
page is ready. 02.2003, ask me again.
hutch--
It seems the highly self acclaimed leading aspiring assembler guru is
again whinging about his failure to shape the world of assembler in
his own image.
==================================================
So nice! The disaster is going on pretty well...
Of course, no need i sing my usual song:
"Where are the Assembly written Applications
the author of this 'Review' ever wrote?"...
Sad days for Assembly.
==================================================
Poor fellow, he must be Greeeeeeeeeeeeeen with envy at the success
that HLA is enjoying, especially with the new book on assembler on the
shelves.
Now members of the forum will probably be familiar with a language
stle that Bertov has been using for some years, CONTRA SPEAK, black is
white, dogs are cats, anarchists are communists and BetovAsm is a
leading assembler. Muhahahaha.
Here is how it works.
"So nice! The disaster is going on pretty well..." really means,
"Damn, HLA is a disaster, its REALLY succeeding..."
"Sad days for Assembly." Really means,
"GREAT day for assembler, someone IS actually supporting it"
Come on Betov, when will you delete that pile of illegal crap and
write a REAL assembler for linux in C ?
Ed Beroset
> Ed Beroset wrote:
>
>>> Well... I guess all I can say is that I disagree. Teaching beginners
>>> to use a macro that may or may not generate additional code, or alter
>>> the code I wrote, seems like a bad idea to me.
>>
>>
>> Are you going to tell beginners not to use jnc? Perhaps you should,
>> since, depending on the distance to the target, a number of different
>> encodings could be used.
>
>
> Well, if these beginners are using Nasm, I'd have to explain to 'em that
> if they want the near form, they'll have to specify "near"... or use the
> "-O" switch (which I might *not* show 'em, just yet). Nasm defaults to
> "short" on conditional jumps - kind of a PITA, I suppose, but at least
> they learn that there *are* two forms...
I think you're on the right track when you say that you'd have to
explain, but maybe not at first. If I were teaching a beginner, I might
just tell them to use the PROC and to just use jnc without fretting just
yet about all of the nuances of their usage. You'd want to start with
basic concepts like conditional versus unconditional jumps and not
clutter things up with jno, jbe, etc. from the beginning.
> (it's the signed and unsigned
> forms that seem tough to "get")
Yes, and signed and unsigned comparisons are another thing that it's
important to teach. You're right that many beginners have trouble with it.
> This seems like a different level of "behind-your-back-ism" than what
> the PROC "keyword" will do... or not do... depending on whether there
> are parameters or locals, and what ".model" is specified.
It's funny that you characterize it as "behind your back" when I'd say
"before your eyes." Maybe you should turn your chair around! ;-)
Seriously, though, maybe it would help to think of PROC as a "smart"
synonym for the ENTER instruction which only generates code bytes if
it's needed. It seems to me like just the sort of thing that would
appeal to an assembly language programmer.
>> Better, I think, than to just avoid mentioning these things, is to
>> simply explain them and to give the beginner a tool (the listing file)
[...]
>
> Well learning "how to learn any new assembler" is certainly a good idea!
> I've never been that impressed with listing files, and I just figured
> out *why*. It's *because* I tend not to use macros or "keywords" - the
> source part of the listing file just duplicates what I wrote. And
> because I mostly work with .com files, they're easy to disassemble, if I
> want to "count gumballs" or otherwise see what's being generated. I can
> see that if the assembler isn't producing what's showing in the source,
> either because of error, or because I'm using "constructs that generate
> more code than is showing" ("macros" or "keywords"), then a listing file
> would become much more valuable.
It's still useful even if you don't ever use a single macro. For
instance, you'd have been able to spot that ESP+20h reference very
easily had you looked at the listing. Also, most assemblers clearly
mark relative addresses, which beginners tend to have a hard time
understanding when they try to write code that will be relocated (a boot
loader being the most common example).
>>> Obviously, it's a minority opinion.
>>
>> Minority or majority don't matter much to me. The majority is often
>> wrong.
>
> Yeah, but when you and Randy are in that majority, the odds decrease :)
You're too kind!
>> [code snipped]
>>
>>>> Which do you think is smaller?
>>
>>> A question of fact - doesn't matter what I think.
>>
>> It does in that if you're using the numeric form because you think
>> it's smaller.
>
> Well, no. The snipped code used a stackframe (but without using PROC) -
> in this case, using "named parameters" would be the same size. Since
> Guillermito arguably put the "pusha" in the "wrong place", the magic
> numbers are weird, so I don't think PROC would work unless that were
> changed, but they could be defined or "equ"ed in some way, and probably
> should have been. The case where he really doesn't want the stack frame
> is his wndproc - he indexes off esp (twice, so it *is* smaller, I
> think), and he does the "trick" of popping the return address (into a
> static variable) so he can call "DefWindowProcA" without having to
> reload the stack with what's already on it. (something I wouldn't show a
> beginner either, except of an example of a "dirty trick")
If you're rolling your own anyway, there are other "dirty tricks" that
could be used. For example, the "pusha" isn't necessarily in the "wrong
place" if you have it there for a reason. Consider a possible
optimization of the original code:
dlgproc:
pusha
; why push EBP again? omit this --> push ebp
mov ebp, esp
mov ebx, [ebp+8+20h]
mov eax, [ebp+12+20h]
mov edx, [ebp+16+20h] ; changed to ebp to save a byte
Now it's three bytes shorter. At the tail end (which would have been a
lot easier to find had it been a PROC by the way)
end_dlgproc_return_0:
; leave -> not needed
popa
xor eax,eax
ret 16
end_dlgproc_return_1:
; leave -> omit this too
popa
xor eax,eax
inc eax
ret 16
...and there are another two bytes and a couple of cycles saved. If
you're going to roll your own, it only makes sense if you do it better
than the assembler does. In order to know if you are doing it better
than the assembler can, you have to know what the assembler can do, and
this means, IMHO, reading the whole manual and having a pretty thorough
understanding of the keywords. If you've already mastered the
instruction set (which is huge!) it's very little additional work for a
pretty large payoff.
>> It's not really so a much a question about the particular code sizes
>> but about perceptions.
>
> Well, I'll admit that I'm a little surprised to see how quickly those
> one byte penalties "catch up" to a full stack frame...
If you decide to investigate it further, let me know if I can help.
>>>> Which do you think would be easier to modify without error?
>>>
>>> Now *that's* a matter of opinion. It's fairly obvious in the
>>> "non-macro" version that if I do "mov ebp, [width]", kaboom!
>>
>> That's true, but the kaboom would occur with a nice neat assembler
>> message saying:
>>
>> **Error** foo.asm(10) Undefine symbol:WIDTH
>>
>> It tells you exactly what and where the problem is.
>
> Well, that wasn't the error I had in mind. I was a little confused
> between something Beth did in some HLA code she posted, and what
> Guillermito was doing. I was thinking that he passed parameters on the
> stack, but indexed 'em off esp rather than a stack frame in order to
> free up ebp to be used for "width" (which he does do, but in a different
> place). What I meant to get across was that "PROC" doesn't put the fact
> that you don't want to alter ebp "in front of your face". "enter" and
> "leave" don't mention ebp, either, of course. I'd start off by walking a
> beginner through "push ebp"/"mov ebp, esp" explicitly, I think, rather
> than hiding why you don't want to touch ebp.
A beginner could just be told not to use either ebp or esp until the
stack mechanism was fully understood. My tendency is to want to
understand *everything* and I suspect most people who undertake assembly
language programming are that way. However, there is a bandwidth
problem when trying to understand everything at once. Sequencing the
learning is important, and I think it helps to cover general topics
(e.g. subroutines and register usage) before specific ones (e.g. stack
frame mechanisms and idioms of register usage).
>> On the other hand, what happens if you accidentally typed [esp+18+20h]
>> instead of [esp+16+20h]?
>
> You don't have to do the shift to convert for the fixed-point? No,
> seriously, we're screwed by a typo like that...
Maybe having made enough of those has scorched into my neurons why I
DON'T want to use "magic numbers" everywhere. Also, consider if
Guillermito decides to use the optimizations I suggested above. Can you
see why those suggestions are incomplete as is? Do you see why it's a
pain to change it the way it's currently written?
>> As interested as I am in making machines run as fast as they're
>> potentially capable of going, I'm also interested in allowing
>> programmers to go as fast as they're potentially capable of going.
>
> Really good point! If we accept that "development in asm is horribly
> slow", it will be true. An asm programmer needs to use PROC and other
> macros/keywords - and no doubt some home-made tools (some perhaps made
> special for this program) - when writing "production code". Beginners
> need to learn to walk before they run so fast, IMO. Now some people feel
> that providing macros, keywords, or library routines is the way to help
> beginners "walk" (in classroom settings where time is limited, it may be
> neccessary). I'd rather start 'em off with the "raw" code, so they know
> what PROC is *doing* before they start using it.
I haven't taught assembly language programming in a classroom setting,
so I can only tell you what I've read, but I think that while what you
say has some merit, I think that the real experiences of beginners tends
to argue for the "teach 'em PROC first" point of view. I'm not an
expert on pedagogy by any means, but a survey of the literature produced
by those who are seems to support that notion. Search portal.acm.org
for "teaching assembly language" and read some of the articles if you
can find them. (Easiest way, BTW, is to be a member of the ACM and read
them online.) And of course Randy Hyde has experience there, too, and
you already know his views on that topic.
>>> Whether this is obvious in the "proc" case depends on how well I
>>> understand what "proc" does, I guess.
>>
>> Also true. So why would you not want to understand it well? ;-)
>
> Because I want to see what my code is doing in the source file, without
> having to open a listing file? :)
When people first learn to drive a car with a manual transmission, they
tend to have to very deliberately remind themselves to push in the
clutch pedal, remember where the next gear is, adjust the throttle, and
then to release the clutch pedal. After a while, that whole action
becomes almost unconscious. It's the same thing with some aspects of
programming. You'd have to look at the listing file the first couple of
times, but with a little practice, you know what to expect there. It's
still good to check, but with practice, you know what *should* be there
and that's how you easily spot errors.
>> All of those "magic numbers" lying around get to be a pain even earlier.
>
> Right. I'd show a beginner an example with the magic numbers in place,
> explain why that can get to be a problem (if it isn't obvious), show 'em
> "%define firstparam ebp + 8" (could include the square brackets here
> too, if you want the access to look more like M/Tasm syntax - "mov eax,
> firstparam" - I prefer "mov eax, [firstparam]" - more "Nasmesque"), and
> *then* explain that PROC will do that for them automatically, and how to
> use it. (in the case of Nasm, which file to include has to be part of it
> - the "flexibility" this allows has its price)
That's not an unworkable approach, and I'm sure a number of people have
actually learned it that way. I even suspect that that approach might
be optimal for some, but apparently not most if I can believe what I read.
>> Technical note -- only in NASM is "PROC" a macro. Most other
>> assemblers have it as a keyword since there are things one simply
>> can't do with a macro.
>
> Okay (I'm not sure about "only", or even "most", but for Masm/Tasm).
> It's not an "instruction", in any case. It's a "construct that generates
> more code than I wrote" (and does more than just generate code - keeps
> some assemble-time variables for us).
It also doesn't necessarily generate any code.
> I understand that it *does* make a
> difference whether it's implemented "built in" or as an external macro
> like Nasm. Nasm - as a design decision by the Original Authors -
> foregoes the advantages of the "built in" approach. This offers
> flexibility - I got got into this discussion mentioning a macro that
> "auto-generated" the magic numbers and allowed us to use named
> parameters and locals *and* index off esp (frees up ebp, even if it
> isn't any smaller) - but this has a down-side, too - it matters *which*
> "proc" you're using. (now that I look closer, this macro wouldn't help
> either Beth or Guillermito... never mind...)
Also, apparently Betov has implemented this notion as macros in his
assembler, too, but it also has some limitations. I agree, though, that
it has limitations either way. Another method might be to have
*everything* be a macro (including processor instructions) but make it
so that all macros may have access to internal functions like the symbol
table. Such an approach would make for an extremely powerful assembler,
but also one that might be completely impossible to use!
>>> I still feel I'd rather see the code "right in front of my face", but
>>> that's just my opinion (and there are cases where I *would* prefer a
>>> macro).
>>
>> That's what a listing file is for.
>
> Why not write it that way in the source file? Understand I'm talking
> about small "example" files - you wouldn't do it in "production code",
> or even a "serious project".
My view is that the habits one uses for small projects tend also to be
used for large ones, and I've seen enough crappy assembly source code in
my life (some of which I've written, BTW!) that I'd really like to do
whatever I can to help other people avoid some of the mistakes I've made
or have seen other people make.
>> Once you've got the macro debugged and working, you can simply use it
>> and not have to worry about it. One of the first things an apprentice
>> blacksmith makes is some of his own tools that he can then use.
>> Programmers would do well to emulate that, IMHO.
>
> Oh, were we talking about having the beginner *build* his/her own PROC?
> I'll go along with that! Using the "pre-built" tool is what I'm saying
> the beginner shouldn't do until until he/she understands what the tool
> *is* (by building one, or some other way).
Not exactly what I meant. What I meant was that there are some macros
which a user MIGHT reasonably write. PROC wasn't one of them. In C++,
the typical beginner thing used to be building a string class. In
assembly, this might include things like setting up an interrupt call
(if you're doing DOS or Linux programming) or setting up certain kinds
of OS calls (e.g. a generic CreateDialog under Windows). They can be
primitive at first, and then refined as the beginner becomes an expert.
>> How many times have you seen newbie post code asking "what's wrong
>> with this program?" only to learn that they were calling int 21
>> instead of int 21h? IMHO, beyond the first time, making that
>> particular error ceases to be instructive.
>
> Okay, ya got me on that one. Maybe if I make the error *enough* times
> it'll instruct me to actually *use* "dos_int". I agree on this one, but
> I *still* prefer to see the "int 21h" (right there where I wrote it!)
I suspect your refridgerator has two unusual features: a switch and an
window. The switch is for you to manually turn off the light, rather
than trusting the door closing to actually do that, and the window is
for you to verify that the light is really off when the door closed. ;-)
>>> Thanks for looking at that code, Ed. I always learn something from
>>> you, even when we disagree! :)
>>
>> And I learn things from you, as well. That's the way usenet is
>> supposed to work, IMHO!
>
> As Mahatma Ghandi said when asked his opinion of Western Civilization:
> "I think it would be a good idea!" :)
I couldn't agree more. (Which, if you think about it, is a phrase which
has its own charming ambiguity.)
Ed
Betov
news:af910ce4.03110...@posting.google.com:
Happy to see that the fucky one who re-distributes a MicroSoft
Product, who claims each time he may, that TASM was a Tool for
writing viruses, who tries to explain to beginners that GPLed
Assemblers will force them to GPL the Applications they will
write, and that M$ EULA is there to ensure their freedom, who
writes his poor thingies in Power Basic, who became friend with
Master Pdf in order to share a bit of his shame glory, who
distributes his poor thingies closed Sources and encrypted, in
order to save himself from even more shame, ... and so on...
seems to become completely crazy.
Have a nice death.
Betov.
< http://betov.free.fr/RosAsm.html >
Alan Connor
>
>
> hmmmm,
>
> It seems the highly self acclaimed leading aspiring assembler guru is
> again whinging about his failure to shape the world of assembler in
I pay attention to men who are attacked by nasty children.
The nasty children I killfile.
Good-bye for 90 days.
Frank Kotler
> I suspect your refridgerator has two unusual features: a switch and an
> window. The switch is for you to manually turn off the light, rather
> than trusting the door closing to actually do that, and the window is
> for you to verify that the light is really off when the door closed. ;-)
Well, my refrigerator doesn't have those features, but I'd like it if it
did. You've got me pegged! And that probably summarizes my viewpoint as
well as anything could...
Best,
Frank
hutch--
putting his foot back in his mouth again.
> seems to become completely crazy.
I have always been crazy and in my old age I am senile as well, thats
why I write assembler, the instructions are short enough to remember.
Where the problem lies with the very few who have been conned into
using BetovAsm is that they end up wasting their time on a toothless
pile of crap that is not powerful enough to write viable useful
Windows application.
Professional assembler are able to emulate high level languages well
and with an integrated combination of library modules and macros, the
code throughput is starting to rival some of the higher level
languages yet when you decompile the output, it is very small and fast
pure assembler code.
The whole range of capacity with true industrial tools is what makes
high level emulation possible, libraries, macros, structures,
procedures, parameter checking and standardised Intel style syntax. An
assembler that cannot do all of these things is a TOY that just wastes
the time of its user.
With Betov committed to the DEATH of assembler in the desperate hope
that he still can become the leading guru who will shape the assembler
world in his own image with what is left, learners are well advised
not to waste their life and time with garbage like BetovAsm and start
learning a REAL professional programming tool like MASM or HLA. Either
way they will learn something useful that they can use in the future.
CONTRA SPEAK
> Have a nice death.
This really means "Have a long life and prosper".
Have a nice death.
sinewave
>
>
> Betov.
you've said it all before Betov.
hutch--
beginners need to start on the lowest level possible to learn
assembler. This piece of popular folklore is probably the greatest
single reason why so many people did not persevere with learning
assembler after being fed bullshit like this.
This much I have learned from thousands of learners on IRC and later
in assembler forums is that being able to get something up and going
first is a LOT more important than understanding segment arithmetic
and being able to use at least some high level constructions greatly
simplifies the task. What generally happens is that after the learner
can reliably get a program up and going they tend to learn the lower
level stuff later at a gradual level.
There has been a lot of HOO HAH in the past about uasing .IF syntax or
prebuilt LOOP syntax in the large professional assemblers but everyone
and their dog already knows that you only use this stuff for hack code
like WndProc procedures where you have a long and large tree sructures
for message processing that is not even vaguely speed critical.
I know rationale is lost on an old fool like Betov who has to try and
cover up the many inadequacies of his work with a barrage of bullsh*t
but for people who actually want to WRITE assembler rather than be in
a position of ever learning it need and want high level style
consructions to get their code up and running fast.
It is the people who SUCCEED in getting assembler programs up and
running that come back later with highly optimised hand written
assembler procedures, not the ones struggling to make the minimum
sense out of a crap heap like BetovAsm that still does not handle
structures properly, cannot build libraries, cannot handle large
assembler files without crashing, cannot produce convenient high level
constructions, the list goes on and on and Betov will not do the basic
work necessary to fix it. He just keeps flogging the same barrage of
bullsh*t to try and cover it up.
Programmers who are interested in actually writing assembler are well
served by using the large professional ones that can do it all rather
than a crippled concept like BetovAsm that is a subset of Betov's very
limited knowledge of software engineering and coding capacity. Why
should a young person waste their life and time with a pile of crap
that does not perform when they can spend it learning a professioal
tool and get software up and running far faster than with a disaster
like BetovAsm ?
Performance is yet another area that Betov is not willing to try and
compete in. In terms of size, power and code speed, MASM is very hard
to beat and the proof is in the 1.5k working window in the MASM32
example code. The equivalent under 32 bit TASM was 8k. Can Betov's
disaster improve on the 1.5k working window ?
When a younger programmer comes to assembler, they don't need to be
fed bullsh*t about the purity of Betov's crackpot political theory and
how they should waste their life and time using something that is
supposed to prop up this nonsense, they need REAL industrial
programming power to get the job done complete with decent
documentation and example code.
Regards,
hutch at movsd dot com
www.masm32.com <<< Get a real 32 bit assembler here for FREE :)
sinewave
> Can Betov's disaster improve on the 1.5k working window ?
RosAsm does not merge import (.idata), resource (.rsrc), data (.data), and
code (.text) segments.
regards,
phil
Alan Connor
>
>
> On Wed, 05 Nov 2003 18:59:27 GMT, Alan Connor <zzz...@xxx.yyy> wrote:
>
>
> You ever wonder, particularly when you've *just* arrived, if an "attack"
> is actually a defense?
>
That was a nasty bit of work, and I am sick of garbage like that.
If I see the same behavior on the part of the other party, they go down
too.
Fair enough?
Beth
> Frank Kotler wrote:
> > Anonymous Guy Schrieben:
> >> Rene Tournois ????:
> >> > Chez moi, sous 2000, ta Demo tourne bien.
> >> >
> >> > C'est écrit sous TASM??? Si oui, je suis un peu étonné:...
> >>
> >> Alors, Rene! En Anglais, s'il vous plait.
> >> C'est un newsgroup d'Anglais!
> >
> > Oui! Nous ne parlons pas Francais ici!
> >
> > Meilleur,
> > Francois
>
> 1) It was on purpose, in order to irritate a little
> bit all of the fucky US Nazis flying around here.
Was über Leute, wer nicht "US Nazin" sind, die nicht französisch gut
lesen können?
[ Which for the benefit of _one third_ of human beings on Earth, reads
as:
???????"??????????Nazis? ]
> 2) As Herbert Kleebauer, said in another thread,
> there is no reason why various national languages
> should or could not be used here.
Depends on context; I see no objection to the use of other languages
in passing on occasion for particular purposes...I have myself
answered a few the Germans around here with the odd paragraph in
German...
But English is the stated and agreed "Lingua Franca" on the
group...this should be adhered to in most instances for the benefit of
the majority of the group...which is NOT a "Nazi" thing
whatsoever...because I look in on a German language ASM group and
there the policy is that posts should be German language and even if
most people there can read an English post, that is NOT the "done
thing" there...and I support this 100% in its attitude...in fact,
there was a post I did make there in English but only in reply to
someone who'd posted to the German language group in English
themselves...and the reply they'd got was in German so I did
temporarily break the rules merely to post an English explanation of
why they were only getting German replies (that "de" means "Deutsche"
;) and to post to CLAX or here instead...
Although, I'd draw the line at any "political" use of language...to
not speak English simply to "piss off US Nazis" or whatever...because
you'll end up annoying a far larger set that just that...this group
uses English as a "Lingua Franca" and there's a lot of different
nationalities...there are also national language ASM groups, such as
the German one I subscribe to, so the choice to come to _this_
particular group may be motivated exclusively on language preference
alone (after all, I subscribe to the German group not because I'm
German or "nationalistic" or anything such thing...but because it
gives me an opportunity to read things in German which keeps what
little I do know about the language refreshed, now that I'm no longer
there and no longer exposed regularly to German stuff...hence, I
_specifically_ choose to subscribe to and sometimes read that group
_solely_ on the basis of its language alone...someone else could also
be delibrately choosing alt.lang.asm to help with their English skills
whilst also being in a technical environment...perhaps slightly _more
likely_ with English because there tends to be an English bias in
computing fields that they may specifically want to improve _technical
English_ skills, as the use of language formally in technical
situations is often quite different to informal stuff...well, you only
have to look at the "informal" nonsense I spit out to see something of
that...
To use a language in such an abusive "political" frame of mind is an
insult to that tongue...it is also in danger of suggesting an implicit
link between the speakers of that language and some misdeed...
For example, you yourself are presuming that all English speakers 1.
American 2. Adore Bush and support his lies and the wars based on
those lies 3. That we're all trying to avoid learning and using other
languages, etc., etc., etc....this would be an _INACCURATE_
presumption to be making...short of yourself and to a degree that
_exceeds_ what you've said, I've repeatedly voiced my opposition with
the Neo-con agenda...an English English-speaker, no less...but,
_again_, do NOT jump to any easy conclusions...as I emphasised in a
post before when I defended someone throwing "Nazi" insults just
because the poster was German, German does NOT mean "Nazi" and,
equally, American does NOT mean "neo-con" or other _philosophical_
group that may be based primarily in a particular country but is NOT a
implicit prerequisite of being of a particular nationality...as I
stressed _big-time_ in that "German does not mean Nazi" post, it's not
only _FALSE_ to be doing so, it could also be _incredibly dangerous_
to characterise nationalities in such a monochrome fashion...as was my
example there, Germans were a highly civilised, cutting-edge,
_democratic_ nation when the Nazis took control...Bush's grand-daddy
and many others outside Germany were "sympathetic" to the Nazi
cause...neo-Nazis plague _ALL_ nations, unfortunately, in various
guises (e.g. Zimbabwe's Mugabe sporting a Hitler moustache, comparing
himself to Hitler and praising Hitler, as he tried to cleanse whites
out of his country...oh, yes, even people who Hitler would have
despised for being black are even taking up his cause at least in the
"spirit" of its blind, quite illogical hatred)...
Don't misuse _any_ language in such a context or characterise _any_
nationality on the strength of disagreeing with a handful of
people...if anything, _language_ is our most important tool in any
struggle...by language, you may communicate the injustice...by
language, you may convey to others that these issues are far more
complicated than merely nationalistic battles (it's like the Northern
Ireland affair, at its root, was NEVER about religion
whatsoever...but, coincidentally, those on one side were Catholic and
those on the other were Protestant and those became the "badges" - the
"colours" of their "flags" - and things were fought on those
lines...but, in fact, there actually isn't any actual religious
dimension to those conflicts whatsoever...they are not blowing up
people because they disagree with the concept of confession or that
the communion wine is or isn't the actual blood of Christ...or any
other religious difference between these Christian groups...yet,
amazingly, it is _always_ characterised as "Catholics vs. Protestants"
when this is actually a _secondary_ - heck, even teritary or more -
aspect of the true reasons for the conflict...which is actually really
about land and the freedom of people to be governed as they will by
who they want...it is better characterised, in fact, by the terms
"Unionist vs. Republican" (Unionist being those who want to be British
and part of the "Union" of the United Kingdom...Republican wanting to
be part of the Irish Republic)...
Humans terribly, terribly misunderstand each other...and these
misunderstandings often lead to injustices and conflicts...in this
regard, _language_ is our first, last and only line of defence from
our own stupidities...it would be a grave, grave mistake to misuse or
adandon language on an issue like this...because, short of someone
being physically transplanted into someone else's shoes (some sort of
sci-fi "body swap" between Ariel Sharon and Yassar Arafat, for
example...wonder how that would massively change _both_ of their
opinions in a blink of an eye to live in the other's
shoes)..._language_ is all we have to do an actually relatively "poor
man's version" of transplanting ourselves into another
situation...yes, it's not always the best but IT'S ALL WE HAVE...and,
thus, that sole means of salvation is worth the
world...literally...please do not abuse or mistreat language for cheap
"political" point scoring...you potentially ruin its capacity to be
used for good and for change to these bad situations...
> At that time, i
> answered to him the same remarks you are answering
> to me to day, because, i was as well a bit irritated,
> as i need the help of a dictionary for many words
> in german. Since then, he convinced me and i changed
> my mind. After all, a good occasion, for me, for
> improving my poor knowledge of the german language.
Well, wanting to improve your language skills is great and
admirable...
But I stand by what _I_ said in reply to Herbert on that issue...he
specifically chose to write his comments in German in his program, as
some sort of means to "punish" because he does not agree to the Iraq
war and other Neo-con adventures...
And I stand by what I said then...that is, in fact, the most foolhardy
and dangerous position you could ever take...here's why:
1. This means of "punishment" is not particularly selective...for
instance, many English speakers who have nothing to do with this or
don't in any way share the Neo-con agenda with the "Axis of Evil" wars
are also "punished" by such actions...for instance, in my particular
case, I'm probably one of the _most vocal_ opponents of this Bush
administration's "PNAC" adventures and their often criminally
simplistic characterisation...
Few, I notice, go as far as I do in calling Guantamo a "concentration
camp", even though it's a camp - housing children, employing known
"sensory depravation" torture techniques, is housing people without
charge, without chance of fair trial, without representation, without
rights, without recognition of the Geneva Convention, without
recognition of the Universal Declaration of Human Rights, without
recognition of the spirit of the American Constitution (it is, in
fact, delibrately situated in Cuba to avoid any "issues" with state
laws...every step has been taken to _AVOID_ any and all laws which
specifically _PROHIBIT_ the construction of just this sort of
concentration camp)...blah-blah-blah...
2. Non-English speakers are also "punished" unnecessarily; English is
often used as a "Lingua Franca" - as it is used in this group between
people of many nationalities and languages - and, therefore, using
German for comments rather than English may be excluding a far wider
range of people than it is intended to do...granted, in my particular
case, German comments would pose few problems...and French ones I
could usually decipher...but Spanish? Norwegian? Russian? Hebrew?
Japanese? Can you, Rene, read Japanese? Or Herbert for that matter?
Wouldn't Japanese comments thus actually conspire to "punish" you two
by not using the "Lingua Franca" of English which you can comprehend
(as we're using right now to communicate)?
3. If you voice your "protest" in a language that the people you're
protesting about can't read then how on Earth is that even a
"protest"? They _don't even know_ you've got a problem...they _don't
know_ what that problem is...they _can't hear_ your particular issues
you want to raise about, say, Guantanamo or the Iraq War...
If you're voicing your protest in a language that they can't
understand then, to all intents and purposes, your "protest" is
_COMPLETELY SILENT_ to these people...which leads to point four...
4. In this, America is your greatest ally...yes, you heard right...the
ordinary people of America are good, kind people...they share your
values of freedom and humane treatment...they are NOT stupid people
whatsoever and will perfectly understand what you have to say when you
say it to them in an understandable way...they also have the greatest
power available to stop Neo-cons like Bush and his kind dead in their
tracks...they are able to _vote_ in democratic American
elections...the protests of Americans stopped a nuke being dropped on
Vietnam, Nixon has finally admitted in his autobiography...the
_spirit_ of America - Liberty, freedom, democracy, justice, etc. - is
the very thing that is missing...the spirit that must be re-ignited in
the hearts of Americans to see that all Bush is offering them is
_negative_...note the keywords, "folks": "axis", "evil", "war",
"crusade", etc...he's only offering permanent fear and permanent
conflict...as any right-thinking person knows, you might be able to
defeat particular "terrorists" or particular "terrorist groups" for
periods of time...but Bush has promised _all terrorism_ for _all
time_...this is simply unachievable...and, also, one man's "terrorism"
is another man's "freedom fighting"...the American "colony" took up
arms traitorously against the British monarch in their struggly for
"independence"...Britain could easily have considered these actions
"terrorism"...
5. Sorry, you're not going to actually like this...but this is
_cowardice_...I mean, comments which are incomprehensible to anyone
you wish to oppose in their views (and a whole lot more besides)
stuffed into an ASM program and that's it? _This_ is the great
"protest" against the "injustices of the world"? _This_ is the best
we're going to do in trying to let others see the extents of these
injustices so that we can all start working together for solutions?
What next? Right, I'm right now stacking 20 pence pieces into a stack
and this "symbolises" my "protest" against Chinese human rights abuses
and the slaughter of students in Tianaman Square...great, what a fat
lot of good that'll do to the world...you can't even see the stack of
20p coins, let alone appreciate the significance, let alone for it to
reach you with the imperative of the unjust situations of the world,
let alone fill you with the gravity that - in the words of the Manic
Street Preachers song - "If you tolerate this, then _your children_
will be next" (referring to the Spanish Civil War in this instance but
a more widely applicable point in general...that if you allow
injustice to stand unopposed then they _WILL_ try it again...and
again...and again...they will test just how far they can push their
neo-Naziism before people won't let them do it anymore...and, please
people, do not let things simply carry on unopposed long enough for my
point here to actually be proved...every time the shop-lifter steals
successfully from a store, they are "emboldened" to do it again, try
something more daring, steal more and more...imagine a store that had
a policy of "oh, just let them do whatever they like, they'll get
bored eventually"...they'd be out of business within a week because
the thieves will NOT stop of their own accord...they will take as much
as they are able for as long as their "luck" holds...in fact, if they
sense "soft target" then your store gets hit the most because they've
realised that you'll happily let them get away with it...even if you
fully agree with the Iraq War, then the _LIES_ used to sell it to the
people CANNOT be allowed to go unpunished...what signal does it send
the liars Bush and Blair that they can lie with immunity because even
when the true extents of their lies are exposed, people just let it
pass without redress? If they'll lie to us all on this most important
of subjects - war - then they won't hesitate to use lies to cover up
bad policy, lies to hide hidden agendas, lies to aid corruption of
funds, lies to protect their roles in things like, ooh, say, an
Enron-like scandal, lies, lies and more lies to allow them to do
whatever they like...to cease to have the law - national or
international - apply to them...to give up repesenting the people but
to become their greatest deceivers...lying, lying and then lying some
more to the people...because, hey, the people don't know...even when
they find out, they don't care and they don't do anything about
it...there's absolutely NO negative consequences to their
lying...no-one seems particularly fussed in _forcing_ Bush to answer
the tricky questions on Guantanamo or WMD or anything...why on Earth
shouldn't they lie all the time and do whatever the hell they like? I
mean, if you knew there was a store where the store-keeper always
continually refused to do anything about people stealing from the
store - heck, you can walk right on in and say "I'm going to steal
this" and then can take it with the store-keeper looking on at you
doing it and he _still_ won't do a blessed thing as you walk out the
door with your stolen property - then who _wouldn't_ be stealing from
that store? It would take an incredibly principled person...and, in
truth, if we're honest, then if there was the "store where you can
steal whatever you like" then it would be immediately _flooded_ with
just about everyone emptying that store within five minutes of the
doors opening..._we_ wouldn't stop...so why on Earth should they?
Exactly, they will NOT do so unless there are _reprocussions_ to their
actions...they must be held _accountable_...the _law_ must be
preserved and enforced...that's one of the biggest mistakes here so
far...everyone seems to think that it's only Iraq were there's anarchy
and mass lootings going on...wrong: "all it takes for evil to triumph
is for good people to do nothing"...
> And, at the end, if we had to choose for a new
> international Computing Language, my vote would go
> for the most in use one on earth:
>
> Arabian.
>
> This would help us to understand the interresting
> things Bin Laden may say, on occasion, instead
> of understanding the tons of bullshits Georges
> Bush says everyday.
It's called "Arabic" in English, by the way...
Also, you're clearly talking out of your arse on this...one third of
the world's entire population lives in China, speaking
Chinese...they'd clearly "win" if we were going by "first language"
alone...
http://www.krysstal.com/spoken.html
As you can see, "Arabic" is only fourth in this list and comes _after_
English...Spanish does better than English...but Mandarin Chinese wins
by a majority of - wait for it - 500 million people or so...which is
winning margin that's actually _significantly larger_ than the _total
amount_ of people speaking the second most spoken language in the
world (Spanish at 332 million total)...although, China has one third
of all human beings living in it so this otherwise remarkable
statistic (that there's almost _triple_ the amount of people speaking
Mandarin as there are English by these figures) is easily explained...
[ Note, also, the irony: Bin Laden was educated in the West...he's
fully capable of speaking English himself...the rest of his family are
shareholders in some of the same companies as the Bush family...he was
a rich kid...yes, doubtless he is serious about his Islamic faith -
even if totally misguided in his interpretation of it - but this talk
from a Westernised rich kid who spent his life in luxury that even
some of the richest Westerners will never see in their days (well,
we're talking _oil money_...the family is stupidly rich, as you'd
expect)...educated by American institutions...his terrorist
organisation was _created_, _trained_ and _funded_ by the CIA until it
turned "traitor" and walked off with _$4 billion_ of American tax
payers money, which might have even gone towards the 9/11 attacks? Oh,
come on...though there is a mystery in what could have happened to Bin
Laden or what it was that made him _betray_ his family, _betray_ his
educators, _betray_ his funders, _betray_ his home country (Saudi
Arabia is #2 on his hate list for its co-operation with America),
etc. - that is, what exactly _did_ America ask their "puppet
terrorist" to do that made him switch sides to become their greatest
enemy, claiming to be fighting "satan"? There is a mystery
there...but, otherwise, this image of a "poor", "pure Islamic" prophet
who "knows the hardship of his peoples" is about as trustworthy as
British Intelligence "dossiers" and Bush's praise of these "excellent
documents"...which turned out to be 1% truth, 49% spin and 50% lies on
inspection...the 1% truth being "spun" so much, mind you, that it's
effectively "lies" too because though there might have been the
tiniest grain of truth there, it was spun and exaggerated and
propoganda-ised until it was equivalent to a "lie" for all the factual
content it conveyed for basing serious decisions about war upon... ]
> 3) Hopefully for the US bastards, other countries'
> people are intelligent enough to make the effort
> of learning your barbarian language.
Regardless, though, we can't all learn the languages of every single
other person on planet Earth...there's simply too many of them and
even individual examples are often _very_ complex...like it would take
you slightly longer than a day to learn Mandarin Chinese (which, by
the way, is _the_ most spoken language on Earth so it's more than
reasonable for you to be learning it, right? ;)...
That would be a modern day Tower of Babel; Again, no "bias",
really...because I _do_ try to make the effort to learn other
languages where possible...I'm working my way through a "teach
yourself Japanese" website that I WGET'd from the 'net the other day,
just because I like that whole Japanese culture thing and am
interested (but I don't envisage being able to master it within weeks
or anything...not at all...it's for "curiosity" only so I don't really
care how long it takes...I'll pick up more as I slowly go along, I
reckon...get some basic appreciation to start to be able to learn more
by actually looking more and more into all the stuff that's out there
bit by bit :)...
And, anyway, how does simply writing comments in French or German make
some great "protest" against Americans (note, as always, I'm still
confused as to why all Americans get this treatment, anyway...I mean,
do we all call you "bastard" and treat you like crap, if Chirac says
something we don't like? Even if you are _equally as pissed off_ at
Chirac as everyone else for saying it? A peoples are NOT their
leader...oh, trust me, "our Tony" is NOT anyone's favourite at the
moment for his repeated ignorance of the wishes of the people...you
know, Tony's on-record with this...he's only interested in making his
name into the history books somehow...looking for his "place in
history"...he doesn't actually give a crap, really...he just dives in
as some "I'm a great peace-maker" because he thinks that'll look good
in the history books...although, of course, history's very hard to
fool and chances are actually highest on him going down as "the fool
who ran around like a headless chicken...made all the wrong 'pacts'
with all the wrong causes...made everything ten times worse...before
his own party had to eject him, because the once 'golden boy who could
do no wrong' has become a liability"...already, the Liberal Democrats
(the third - usually insignificant - party) are picking up all the
votes while the main two - Labour and the Tories - are losing votes
like there's no tomorrow because they both have (had) leaders who are
liabilities losing them votes...
> 4) When China will be the world leader in the
> Computers and computing areas, you will have
> a bigger problem than with reading my couple of
> french sentences.
Nah, I'll just go use wolfgang's OS and go live in his little "bubble
world", detached from the "fashions" of pointless HLLisms
everywhere...there's much to be said for that idea at times in this
mad, crazy, insane world of ours ;)
Anyway, on the subject of China, what's the current odds on that
likely Microsoft source code leak coming from China, once MS hand over
some of the source code to please the Chinese government paranoid of
CIA "spying" software inside Windows? One of the technicians is bound
to be thinking: "now, here I have in my hands source code that many
people will pay an awful lot of money for...in fact, they'll happily
pay _more_, the _worse_ the source code actually is because it'll
confirm what everyone's suspected about MS all this time"...if you
were that Chinese technician...well, it's a big temptation, right? ;)
????????????????
?????????????????????
??????????????????????
Beth ;)
Beth
> Best,
> Baron Von Kotler, the flying Nazi
"The Flying Nazi"? Please tell me this has nothing to do with "the
Flying Nun"...the concept of that entire show was taxing enough on my
few remaining sane brain cells without the even more surreal concept
of a TV show about a Nazi officer who could pull out some "flaps" from
the sides of his pointy German helmet (Kaiser-style, of course, for
added comedy value ;) and then would rescue nuns who'd accidentally
fallen over cliffs or something...
Now there's a pitch to take to a TV executive:
TV Exec: "So, what's this show of yours all about then?"
Beth: "Well, it's a cross between 'the Flying Nun', 'Skippy the Bush
Kangaroo' and 'Schindler's List'...featuring a guy dressed in the
traditional 'Kaiser' German military uniform, despite being completely
historically inaccurate...also, half way through the show, a series of
women in kinky underwear and nurses costumes will be chased by a bald
man in a speeded up sequences with lots of comedy music...plus, it'll
all be filmed in 'real-time' over a 24-hour period with that whole
'Andromeda Strain' split-screen nonsense...I'm thinking that ABC's
Scott Jennings or whatever his name is could take the starring role of
'the Flying Nazi'...what do you think?"
The ultimate "hybrid" TV show...oh, yes, a chimera of every single
good, bad and ugly TV show I've ever seen during my misspent life in
front of a TV set, all put together with Frankenstein-like cosmetic
seamlessness...
*cue manic "evil genius" laughter echoing into the distance*
Beth :)
Beth
multilingual characters...oh well...not that it was at all interesting
or anything, anyway...not exactly missing much ;) ]
Beth :)
hutch--
> I pay attention to men who are attacked by nasty children.
>
> The nasty children I killfile.
When you want to balance the response to the conduct of Betov over
years with Betov's conduct, you will have something to say. Perhaps
you deserve each other. :)
> Good-bye for 90 days.
Good riddance.
Beth
> Betov wrote:
> >>"Different strokes for different folks" - surely there's a similar
> >>saying in French...
> >
> > The "Beth Attitude".
>
> I hope Beth is pleased to have the attitude named after her, but I
hope
> she and I aren't the *only* ones who can keep an open mind!
Yeah...an attitude of keeping an open mind, examining all the options
in a fair minded way, looking for the "win/win" solution when
possible, etc.? I'm not just pleased to have this named after me, I'm
ecstatically happy about it...there could hardly be a higher
compliment or better honour to award someone...
> > Unfortunately, that does not work: Assembly is
> > not a fruit, and, _yes_, you _have_ to choose:
>
> What will happen if I *refuse* to choose? Lets find out...
Absolutely nothing, as I've been refusing to do so sufficiently that
the entire attitude is now named after me...the worst thing that
occurs is that Rene gets annoyed with you and might say "Frank Nazi
Conservative Nazi Bastard" or something...
But, as you may have noticed, Rene says these sorts of things about
_anyone_ who does not fall 100% into line with his extreme
ideals...thus, most likely, you are already "Frank Nazi
Conservative..." etc. at the moment with Rene or something, that it'll
make not a blind bit of difference to anything for Rene to get more
upset with you for refusing to choose because it'll be hard to
distinguish this type of "upset with not choosing which non-fruit to
idolise" (and people call me mad...yet this is what Rene insists upon:
that you must devote your entire life to _one_ and _only one_
"non-fruit" because, umm, it isn't a fruit...or something like
this...not exactly 100% sure because he doesn't bother much with
_reasons_, only "decrees" of what can and cannot be "assembly" ;) from
his "general upset with a person because they aren't agreeing 100%
with my extreme ideas"...
> > Being both *pro* and
> > *anti* is nothing but incoherency.
>
> Agreed. What's wrong with being "pro" and "pro"?
Or how about:
* Being "indifferent" and "indifferent"...
* Being "anti" and "anti" (after all, it's quite possible for
_everything_ to be crap at the same time...and you're forced to make a
choice of the "lesser of two evils"...the "least crap" thing that
you're least "anti" against...this hardly makes your choice something
you necessarily want, you'd just rather not have the other thing...
So, that's _three_ possibilities only looking at situations where you
feel equally about both options...now, if you're not feeling equal
about two things then we can come up with a fuller list: "anti" and
"anti", "anti" and "indifferent", "anti" and "pro", "indifferent" and
"anti", "indifferent" and "indifferent", "indifferent" and "pro",
"pro" and "anti", "pro" and "indifferent" plus, finally, "pro" and
"pro"...which is the three possibilities - minus, zero and positive -
applied to both things under comparison...leading to three to the
power two, which is nine possibilities...
And that's before we enter into the concept of "degrees and
measures"...for instance, yes, someone could be "pro" one thing and
"anti" the other, just like you've said, Rene...but this could be a
"not quite so impressed pro" and a "I'd rather not have but could
suffer it anti"...that is, yes...they are "pro" one and "anti" the
other but there's not a sufficient "gap" between them that they must
immediately devote their entire existence to the "struggle against the
anti by blinding worshipping the pro"...
In truth, we actually have an _infinity_ of possible combinations
here...which, lo and behold, is _exactly_ what we find in everyone
having a slightly different opinion on anything and everything...this
is no coincidence...it's a manifestation of an implicit _fact_ about
such things: There are so many choices available - an effective
infinity - that there's absolutely no chance that two people - even in
a population of billions - _exactly_ 100% correspond in their opinions
on anything...there will _always_ be "degrees and measures" and "give
and take" and so forth...
We're actually faced with "an infinite range of colours" to choose
from, that simple "black and white" thinking is completely, wholly,
entirely and totally inappropriate as a "model" of what we're looking
at...
Yes, humans would "like" for the world to be divided up into nice,
neat "black and white" categories because then life would be so much
easier and clear and so forth...but this is NOT the case...things
AREN'T like that in reality...so "get over it!" that they aren't like
that and learn to deal with how things really are, rather than some
imagined "dream place" inside your brain that bears no relation to
reality...
Reality is exceedingly "messy" in its organisation...things are all
over the place...there are "exceptions" everywhere...one thing seems
one way but turns out to be the other...you could, I suppose, attempt
to try to force some "order" on this "chaos" but, implicitly, you'd be
fighting a losing battle...reality would literally reject your
attempts to categorise it so easily...you could "attempt" this...but
that's _exactly_ all that it would amount to: an _attempt_...you are
guaranteed not to succeed with "black and white" thinking because it
simply does NOT match reality's inherent nature whatsoever...think
this way and, if you like, you're an _automatic_ "loser" because it's
something you can _never_ succeed in "winning"...
Variety and difference is NOT in the slightest bit "wrong"...every
snowflake is unique...every fingerprint is unique...every person -
even otherwise "identical" twins - are completely different...you can
write the letter "A" on a piece of paper repeatedly for your entire
life and you'll _never_ be able to reproduce two letters that are 100%
identical in shape down to the atomic level...you couldn't take a
glass of water and pour it into the ocean and then try to pull back
each atom from the ocean and perfectly "restore" the glass of water
you had atom for atom exactly as it was before you poured it away...
"Uniqueness" and "difference" are hardly dieases...quite, quite the
contrary...this is the _true_ fabric of our universe...it loathes and
_rejects_ "same" everywhere without exception...you can think in
"black and white" terms, sure...but this simply means you have NO
relation to actual reality in your thinking...you are inherently
_wrong_ to be thinking in those terms or to think that "difference" is
a problem, when it is actually the very fabric and inherent nature of
the entire universe (even string theorists are seriously postulating
the possibility that even the laws of physics we know are merely "one
set" amongst an infinity out there...so, nope, not even the things
we'd be "sure" of as "constants" actually turn out to be so...light
speed changes...the laws of physics _can_ be different in "other
places", even if it might actually be impossible for us to ever visit
these "other places" to experience it ourselves)...
Time to wake up to the facts..."absolutism" - and, thus, "extremeism"
as its extreme version - is completely and utterly doomed to failure
and being entirely wrong from the very start because it's ignoring the
basic fabric and inherent nature of our reality in doing so...yes,
life would be so much easier if this were not the case...but it is the
case so, unfortunately, life is NOT going to be easy on these
things...that's fact...we simply have to "deal with it", as there are
no other alternatives offered to us by reality...
"Intertwingularity is not generally acknowledged --
People keep pretending they can make things deeply hierarchical,
categorizable and sequential...when they CAN'T.
Everything is deeply intertwingled."
[ Ted Nelson ]
> > Good is good. Bad is bad.
>
> So is a rainstorm good or bad?
Exactly, Mr.Kotler, exactly...things aren't actually so easily divided
as some would like them to be to suit their "black and white"
thinking...
> > Since the oncoming of the first versions of Windows, that kicked
> > Assembly out for many years, the oncoming of HLA is the next
> > important attempt to kick Assembly back to the grave-yard again.
>
> Perhaps because I only got into computers around the first versions
of
> Windows, I may not fully appreciate the "first reign" of assembly.
It
> seemed more interesting to me than HLLs - I never noticed it was in
a
> graveyard.
Of course, life is inherently deeply ironic throughout...so, while
everyone argues about "ASM vs. HLL", you know what'll probably happen?
Just when everyone's come finally to a decision on the matter, that'll
coincidentally and ironically be the very same morning when the
hardware people release a 100% reliable self-programming AI to replace
all human programmers completely...Murphy's law and all that...you
just _know_ that that's what'll happen...the instant a "conclusion" is
reached, the universe will mockingly make the "conclusion" that was
reached completely bloody useless that very same morning that "the
impossible" was achieved in getting universal agreement...
Although, that said, the universe also insists on being completely
unpredictable too...so, in fact, it's probably more likely that a
large asteroid will collide with Earth and obliterate us all
completely were any sort of "world peace" or "universal consensus"
ever achieved, rendering the whole thing quite pointless...except, of
course, there _is_ an inherent mechanism in "Murphy's law"...now that
I've said "an asteroid will strike" that possibility will NOT
occur...it'll be a plague or something instead...except that now I've
said that, it won't be...so, it'll be run-away nanotechnology,
maybe...except that too is now not going to happen, as I would have
predicted it and that's not possible...but, better yet, as I've said
"it's unpredictable" then it's actually predictable - just to fulfill
the "you can never be right" law - and it will be one of these
things...except I've now just said that, so it's all reversed around
yet again...
> > The fact that Master Pdf is not that much rejected from a List
> > like this one, but, instead admited as a full-right member, only
> > shows the competency level of most participants.
>
> Well, ignoring the fact that no one is "admitted" or "rejected"
to/from
> this newsgroup, what *does* that tell us? Many of the "regulars"
> actually *don't* like HLA that much. Does the degree of their
dislike
> for HLA predict their competence? I hadn't noticed much correlation.
And, anyway, were there this mythical "correlation", by what rationale
would a lack of competence imply about newsgroup inclusion? That is,
where is there a "you must be competent to post here" sign written
above the door? In fact, wouldn't there sort of be _the reverse_ sign
hanging above the door: "if you're in doubt about something, then come
on in and ask someone who just might happen to know the answer"?
I think it speaks volumes and volumes about our "revolutioneer" Rene
when he implicitly and explicitly suggests some sort of "exclusion"
policy...remember, people, if you're not "competent" then you should
report for being stoned to death by Rene's "thought police"
immediately...he really, really doesn't seem to be able to tolerate
this sort of thing at all...
No wonder he has no Love at all for "beginners"...they are merely
"incompetence animals" to be shot to "put them out of their misery" or
something similar...
Yes, there will inevitably be people who are "incompetent" or, almost
certainly applying to _everyone_: "lacking competence in various
areas"...this is not essentially a problem nor is it any grounds
whatsoever for people not to partake in a newsgroup...I mean, if it
were, then we could _all_ be "kicked off"...as, at some point, we've
_ALL_ accidentally put a bug or two into a program...which is, of
course, a purely human "incompetence" that everyone will suffer at
some point, as we're not robots...and I'd suggest that we should NOT
even want to be robots either...let the robots be the robots...I mean,
they're guaranteed to always get it right and be 100% "competent" in
being a robot...
> > I am a bit estonished, that a guy like you, who seems to
> > perfectely understand the interresting details of Assembly
> > programming, does not seem to understand in what manner the
> > programming methods pushed by HLA and master Pdf are nothing
> > but Anti-Asm (not talking of the demential syntax -which is
> > only a detail problem- not talking of the fact that HLA is
> > only a ridiculous and awfuly written Pre-Parser, not talking
> > of the real Randall motivations, and so on...).
>
> However perfect or imperfect my understanding, I come to the
conclusions
> I come to. Thirty-five years ago, a lot of people wondered why "an
> intelligent guy like me" couldn't figure out that the Vietnam war
was a
> good thing, and that the government wouldn't lie to us (seems
incredible
> now, but that was the argument...) I reject now, as I rejected then,
the
> notion that "a guy like me" ought to come to different conclusions
than
> I do.
Yup, I know that particular one well, Frank...anyone who has
independent thought probably knows this one...as it's the quite
predictable first course of action that's employed to try to change
your mind and "seek your approval"...a basic "reward and punish"
system..._IF_ you agree with them, then you are deemed "intelligent"
and showered with compliments and praises..._IF_ you don't, then the
"implicit threat" is carried out and they try to suggest that you're
as dumb as a post...the next "phase" involves them trying to explain
away your otherwise "intelligent" comments...umm, then, if not "dumb",
then you must be "insane"...regardless, whatever pathetic device is
employed, the basic idea is simple: You _MUST_ comply or _any_ and
_all_ steps _will be_ taken to silence, ridicule or exclude...by
casting doubts on intelligence or sanity...by exclusionary policies
like Rene's "those I deem 'incompetent' may not post to an
unrestricted, free newsgroup (even if this policy completely
contradicts my supposed principles of "freedom" that I use the GPL and
talk about "leftism" to promote)"...
Whatever...
"To disagree with three-fourths of the British public is one of the
first
requisites of sanity."
[ Oscar Wilde ]
Beth ;)