What do I do with Art Of Assembly?
Lucas de Paiva Pirolla
I started to read the Art Of Assembly book, eletronic version.
But in the book everything is in HLA language.
My question is: when i finish reading it, will I be able to do
_everything_ I do with HLA using pure assembly language? (I know, not
including those IF statemantes and so). Or with this book I'm just going
to learn the concepts of assembly language and then I'll need to read a
pure ASM language book??
[]'z
Lucas Pirolla
drhowarddrfinedrhoward
Those who know nothing about low level programming and come from a HLL
language might do well with HLA but I have no experience with that.
wolfgang kern
Hi Lucas,
HLA, GCC, AT&T, ..
use a certain syntax I cant read or interpret easy
(opposite view and too many useless 'double-define'-characters),
but many folks are familiar with this "{%eax%,%ecx%;(&;%$);==};"
Pure ASM means the IA-xx syntax found in the Intel/AMD books,
much easier to learn and '?almost' self-explaining.
The AoA-book may contain many hints how to make working code,
but in a (for me and many others) not very transparent language.
Learn both to become a translator once :)
__
wolfgang
Beth
> Hi
Hi :)
> I started to read the Art Of Assembly book, eletronic version.
>
> But in the book everything is in HLA language.
>
> My question is: when i finish reading it, will I be able to do
> _everything_ I do with HLA using pure assembly language? (I know,
not
> including those IF statemantes and so).
Yes; Actually, _INCLUDING_ those "IF" statements...MASM (from
Microsoft) and TASM (from Borland) also include their own ".IF"
statements, which are, in fact, _MORE_ high-level then HLA's "IF"
statements (which are delibrately simplified)...also, MASM and TASM
include "high-level" control structures like "for" and
"while"...again, HLA's implementations of these are, in fact, if
anything, _MORE_ limited than these assemblers (MASM will happily
start using registers "behind your back" in some of its control
structures, while HLA - other than for OOP (but that's to do with how
OOP works, not because HLA is trying to go back on its own
principles) - guarantees that no register contents will be
touched)...though MASM does not include native OOP support, Borland's
TASM (now unsupported by Borland) does...
So, regards the "high-level" control structures, HLA does NOT, in
fact, exceed what any of the other assemblers out there provide...what
is unusual about HLA is that it provides all of the facilities in one
assembler (e.g. MASM doesn't have OOP but TASM does...TASM structure
member names must be globally unique, they are "local" in MASM...if
you combine the "leading edge" of all these assembler "HLL"
facilities, then _that_ is what's different about HLA's implementation
to these other assemblers...it has all their facilities - though,
often, despite the criticisms, not always to the same degree - in the
one place rather some here, some there and that kind of thing :)...
Of course, we are NOT interested in those "IF" statements, anyway, are
we? Perhaps handy while learning the basics...perhaps useful when you
need to get code done quicker and don't mind a little "inefficiency"
here and there in unimportant code, just to help speed you
along...It's nice to know it's there should the need arise and that
they are, in fact, matched by many of the facilities in the currently
most popular Windows assembler, MASM...
But, in the end, we're not particularly interested in that, are we?
You want to know about the situation _after_ you've got to grips with
using ASM and none of this "HLL" nonsense...and the answer to your
question is still a firm "yes"...you _will_ be able to do _everything_
that you'll learn to do with HLA using another - though more
"traditional" - assembly language? And the reason for that is also why
I did NOT refer to HLA as not being an assembly language
itself...because it _is_...it's a new assembly language with a
radically different syntactical approach but, in the end, that does
NOT disqualify it from being "true ASM", whatever you may have heard
elsewhere...
If you're able to "read" both syntaxes and be able to "translate" then
you won't discover any difficulty...now, there are some who have their
own assemblers and own ideas about what tools people should use who
will probably try to say this is inaccurate...but, these people
haven't _tried_ HLA and are talking out of prejudice and their own
imaginations...I'm still in the process of getting totally to grips
with HLA syntax, indeed, already knowing how to write very much "to
the wire" raw ASM code...in making the "transition" to HLA, the only
problems I've encountered were due to my still learning HLA syntax and
misunderstanding things...but after posting to Randy, I saw the error
of my ways and it was corrected...
There have been no problems about "inability" at all...there was one
or two problems that I reported to Randy about "ugly syntax" (namely,
allowing "pointer to procedures" types for convenience - which has
been part of HLA for a while now - and a thing about writing to code
labels (which, according to Microsoft and Intel advice, you really
shouldn't actually be doing, as the code section should remain
unwriteable for "safety / security" reason...but, heck, like I'm going
to listen to Microsoft ;) - which Randy will have fixed by the next
version (in fact, it is _already_ fixed and he sent me this newest
version of HLA with the fix in it by Email...when HLA is updated
again, it'll be included...not that probably anyone on the face of
planet Earth but me would have noticed and / or missed this pretty
"obscure" thing being in HLA in the first place...but, regardless,
it'll be there by the very next download and you'll never know there
was an "ugliness" problem in that department at all)...but, I stress,
these had NOTHING to do with "inability" (the first is a "HLLism" and
simply ignoring the "HLLisms" and doing it in a more traditional "ASM"
way will cure that...and the second could be cured by using "readonly"
sections but, as I say, that won't strictly be necessary when the fix
goes up...in both cases, HLA was _entirely able_...these were merely
"polishing up the syntax" issues...well, HLA's a big language and
written by one guy...the odd "oh, I didn't think of that" can turn up
(although, I'd stress that this is "not very often" because my coding
style means I'm really putting it through the mangle in places and it
comes through with flying colours ;)...but my "fresh pair of eyes"
helped to locate "issues" so that they won't be around anymore...and,
just for good measure, as I know Rene won't be able to hear this
unless I ram it home: These weren't problems with anything being
"impossible" in HLA, they were simply "polishing up the syntax"
issues...well, HLA v1.x is a "prototype" exactly designed so that any
"issues" arising can be _found_ (_actual use_ is the best way to throw
up problems that you might not have realised with some "on paper" or
"I'm holding it all in my mind" language design ;) and smoothed
out...to be honest, I'm _only_ really mentioning this "fine-tuning"
part, just so you can be sure that I'm NOT just saying "HLA is perfect
and has no issues at all" but that, in use, I've not run into any
"impossibility" (except Herbert's "DB" method...which is NOT possible
with _any_ assembler which goes via object code and a linker...that's
not a HLA failing, that's a case of a style of assembler use - and we
could be talking about _any_ assembler: MASM, TASM, NASM (not in "flat
binary" mode) and so on and so forth - and the practice of using
"object code" and letting the linker fill in the headers automatically
is "incompatible" with Herbert's "write _everything_ yourself using
raw hex codes" style of programming...again, not a criticism of HLA in
particular but a "clash of interests" between a style of tool use and
Herbert's "who needs tools?" manual methods...in fact, this applies to
HLA only because it _uses_ MASM, which can't do this...HLA v2.0 won't
have this problem and, though I've not attempted it, there's a
possibility that using FASM output and "nasty hacks" it might even be
completely possible with HLA now, just you'd have to "hack" it out of
HLA, it doesn't yet come naturally ;) or anything at all...
Your actual problem - because, in this world, there are always
problems and "cures" merely replace one problem with a different one -
is whether you'd _WANT_ to use more traditional ASM after using
HLA...that might sound daft initially...but you would be "downgrading"
to tools with usually much less features, which provide almost
_nothing_ that HLA couldn't also do, anyway, that would require you to
go through a whole "translation" process but that's only to learn how
to write _exactly the same thing_ in a different way...
The only needs currently for other assemblers are: 16-bit code (HLA
does not support 16-bit DOS code...but, then again, neither do other
32-bit assemblers like RosAsm, GoAsm and so forth), _native_ SSE
support (Randy hasn't added these directly yet...note, that's a
practical problem in origin...he didn't have a machine capable of
testing it on until recently...and note the stress on "native"
there...you _can_ - like any other assembler - create your own
"macros" for the unsupported instructions which output the raw hex
codes into the code stream...what's missing is direct support for the
instructions - which is useful, of course - not that it couldn't be
done by an enterprising ASM coders ;), "flat binary output" (but, then
again, until NASM pioneered the idea, none of them much had this
ability...FASM also can do this...HLA v2.0 will have it because I'll
either nag Randy to death until he adds it with continuous comments
like these or, as HLA v2.0 will be completely "extendible" with "back
ends" then adding a "flat binary" output can be done that way by a
"third party"...namely me, if Randy doesn't do it himself ;)...
Plus, of course, being able to _READ_ and _UNDERSTAND_ code written in
the more traditional syntax...but then, once you've got to grips with
assembly language (any one of them) then this mere "translation"
process really is terribly, terribly trivial...you'll pick it up
easily...like "mov (eax, ebx)" -> "mov ebx, eax"...yup, take away the
brackets and swap the operands around...hardly "rocket science",
despite all the attempts to make it sound like a "really serious
issue" by those with a vested interest in killing off HLA to promote
their own assembler...
> Or with this book I'm just going
> to learn the concepts of assembly language and then I'll need to
read a
> pure ASM language book??
This is what comes of naughty people like Rene spreading "myths"! And
he dares to talk about misleading newbies with "swindles"! Think about
it, if you "learn the concepts of assembly language" then, surely,
you've learnt assembly language? All you require is a knowledge of the
_syntax_ of each of the assemblers after that (learning how each
assembler chooses to write the same instruction in an entirely
different way...and, note, they _ALL_ do that...it's nothing
particular to HLA...there's just no standards in ASM)...that isn't
particularly difficult to get to grips with at all, really...you'll
note many of us having our own "assembler prejudices" but when someone
posts up HLA or MASM or NASM code, few people actually have problems
"translating" (so long as they actually give it a go...Rene would, no
doubt, _refuse_ to learn HLA syntax because of his bizarre
ideas...but, Frank Kotler who's the resident "car mechanic" on posted
code around here seemed to pick up HLA syntax and give that Paul
fellow useful advice without needing to blow a bloodvessel as Rene
would insist on doing...sure, he's a self-confessed "NASM bigot" but
"translating" isn't difficult to master, if you're willing to learn
;)...
You _may_ want to read those more "traditional" ASM books in order to
become familiar with more MASM-like syntax...or NASM, as there are
also texts using NASM these days...for other assemblers, there aren't
that many books dealing with their syntaxes, anyway, that you'll be
learning that from the "documentation" that comes with them, no
different to HLA...but, then again, that's only so you can _read_
non-HLA code...if you've no particular need to look at code for other
assemblers or want to translate something from MASM to HLA, then even
this isn't strictly necessary...
In short, you shouldn't find there to be any great difficulties
whatsoever by proceeding with HLA than you'd have starting with any
other assembler and then "moving over" later (presuming you even will
"move over" later...if you really do carry on with HLA and _go right
to the end_ - that is, learning how to do things yourself "manually"
without "HLLisms" or libraries or whatever (which is _perfectly_
possible under HLA because I _never_ write anything differently...I
used the "standard library" for a code example I posted up here before
because that was what the poster was using and it needed that
"compiles to both Windows and Linux" stuff with it...and, yeah, I
typed out the "hello, world!" to test out HLA itself, as the book
advisese...beyond that, I went straight to the _reference manual_ (not
AoA) and read the "how to take complete control of HLA" article on
Webster and then write exactly the kind of code that some wrongly deem
"impossible" (it can't be! I'm doing it ;) and doesn't use the
"HLLisms" - quite honestly, for all I know, the "IF" statement in HLA
might have problems with it or something...I can't tell, I never used
it beyond one small bit of example code I posted ages
back...therefore, in a sense, I've started - thanks to already knowing
ASM and low-level coding before coming to HLA (that I could use that
knowledge just to immediately dive into the "deep end" of the pool
;) - roughly where AoA should eventually take a coder (okay, minus the
years of experience at doing it all the time...but, then, the _only_
way to get that is through doing it all the time for years, as should
be blatantly obvious to everyone that it feels silly even mentioning
it...but, well, the way some people invent nonsense about HLA, you
have to "cover all bases" or that's where they'll launch some silly,
silly "attack")...
Hence, I'm "trial running" that part of HLA...and, well, the point is
that I'm coming _from_ other assemblers _to_ HLA because it _does_
represent a better way of doing things (trying to use structures -
which Windows _and_ Linux _and_ OpenGL _and_ X-Windows -
_and_..._and_..._and_...and practically everything else you'll ever
interface with, to cut the list mercifully short - themselves use, by
the way...that, for a 32-bit assembler, crap support isn't some
"philosophical statement" at all...it's just a _FAILING_, pure and
simple (I otherwise like NASM - and note plenty of discussion about
properly improving structure support on the mailing list - that I
won't pick on it as harshly as the others, who've got some mad idea
that they are making a "philosophical statement", when it's more like
just making a fool of yourself...with small applications in DOS hacked
together, this stuff wasn't particularly relevent, true...but trying
to go for very long without it in modern OSes, is like trying to walk
without legs...okay, they might insist that "hey, you can still move
around without legs!!", which is _technically_ true...but would you
want to line up in a queue to have your legs hacked off any time soon?
;) - on any other assembler - except MASM, to be fair - and is simply
so feature-packed that even the _commercial_ stuff often looks like a
"toy" in comparison...
If we take it as being that I'm where you would want to eventually be,
so to speak, then, amusingly, the only "HLA problem" I have is having
to constantly correct "myths" about what it supposedly can't do but,
in fact, does perfectly well (better yet, often _does better_ than
anything else ;)...having to correct this idea that HLA is "not pure
ASM", "not real ASM" and such...it's a different syntax, granted (but
aren't they all in their own ways? HLA _ain't_ anywhere near the
"radical departure" of AT&T syntax...I _still_ have problems reading
that...especially when part of a GCC "asm" statement which adds on
another mountain of confusing things...HLA is _NOWHERE_ near that
bad..."brackets and swapping operands around" really does mostly cover
the difference for all but a few exceptions)...HLA _is_ assembly
language...it's a _new_ syntax, trying out a _new_ way of writing
these things (basically, "borrowing" HLL _syntax style_ a little so
that it can be written and formatted mostly in the same way...and even
the "pure" ASM coders can be heard talking about "okay, so ASM is
harder to read" that HLA should be considered _good_ for having the
guts to be the one who makes those first steps in actually _really_
doing something to solve the problem...I'm sorry, Rene, but as useful
as "right-click" is, it doesn't actually make it _read_ any easier on
the monitor screen...this is like trying to "cure" traffic jams by
suggesting "hey, what if we paint all the vehicles in different
colours to colour-code what kind of vehicle they are...red for a bus,
blue for a car and such?"...it's a "cure" that seems not to even
understand what the original problem actually was)...
Regardless, _learn ASM_...don't learn someone's prejudices, don't
learn someone's "philosophy", don't learn about all that stuff...learn
ASM of any description...whatever way you find easiest without these
other things confusing you for no good reason...then, when armed with
_knowledge_, make up your own mind...note that many here had no
"formal" plan or education and simply "pieced it together as they
went"...so, it _can_ be done in many different ways...perseverence
makes it inevitable...the thing to consider, though, is that there
_are_ "formal" ways and good books and tools available these days to
make things quicker and easier...
Truth is, the stuff about HLA above is merely _only_ to correct the
"myths" circulating about it...I am not really telling you to use HLA
or not use HLA...I'm just posting to make sure that if you've heard
"rumours" about this and that, to make sure that _facts_ replace those
"rumours" instead...I've given most of the assemblers a go and they
all have their own "charm" and "character"...and, in the end, if you
learn about ASM and the tool lets you put instructions in a sequence
and spit it out into an EXE file then, with ASM coding, it's _your_
knowledge that's most relevent...tools are tools...they just assist
you in doing that...it really _ISN'T_ as big an issue as people often
make out...but, well, it's one of those "religious" things - people
with their own likes and dislikes - and gives people something to talk
about (when not simply totally off-topic ;) while we wait for some
actual code to be posted or for a proper, reasonable question (just
like yours here, in fact ;) to appear on the group...
Beth :)
Randall Hyde
"Lucas de Paiva Pirolla" <pir...@ime.usp.br> wrote in message
news:Pine.LNX.4.44.040115...@kevlar.ime.usp.br...
> Hi
>
> I started to read the Art Of Assembly book, eletronic version.
>
> But in the book everything is in HLA language.
for good reason :-)
You'll find it easier to learn than standard assembly.
>
> My question is: when i finish reading it, will I be able to do
> _everything_ I do with HLA using pure assembly language? (I know, not
> including those IF statemantes and so). Or with this book I'm just going
> to learn the concepts of assembly language and then I'll need to read a
> pure ASM language book??
No. AoA starts out using those HLL control structures to leverage your
existing knowledge and then shifts to the low-level control structures
(i.e., pure assembly) at a graduated pace. By the time you finish
chapter seven (in the published edition) or the third volume (in the
on-line edition) you'll pretty much know the low-level instruction
set and how to emulate all those HLL-like control structures yourself.
Will you need to read a "pure ASM language book?" Of course not.
AoA is far more comprehensive than any other book on the language
out there. The most you would learn from another book is the syntax
of some particular assembler (probably MASM or NASM) and that
you can pick up from their reference manuals if you need that info.
Although there are *syntactical* differences between HLA and other
assemblers, the *semantics* are the same. That is, machine level
programming is machine-level programming no matter what assembler
you're using. Assembler syntax doesn't change that one bit.
As for when you reach a certain level of competency with HLA -
it will be quite easy to pick up the syntax for a different assembler
should that need arise. You'll probably discover, though, that HLA
has a lot of features you won't find in other assemblers. Most people
who learn assembly language with HLA start out like you -- wondering
how hard it will be to learn "real" assembly once they master HLA.
Once they learn HLA and take a look at those other assemblers, they
discover that they can't do anything with those other assemblers that
they can do with HLA, and because HLA's more powerful, they just
stick with HLA.
Cheers,
Randy Hyde
Herbert Kleebauer
> Truth is, the stuff about HLA above is merely _only_ to correct the
> "myths" circulating about it...I am not really telling you to use HLA
> or not use HLA...I'm just posting to make sure that if you've heard
> "rumours" about this and that, to make sure that _facts_ replace those
> "rumours" instead...I've given most of the assemblers a go and they
> all have their own "charm" and "character"...and, in the end, if you
> learn about ASM and the tool lets you put instructions in a sequence
> and spit it out into an EXE file then, with ASM coding, it's _your_
> knowledge that's most relevent...tools are tools...they just assist
> you in doing that...it really _ISN'T_ as big an issue as people often
> make out...but, well, it's one of those "religious" things - people
> with their own likes and dislikes - and gives people something to talk
> about (when not simply totally off-topic ;) while we wait for some
> actual code to be posted or for a proper, reasonable question (just
> like yours here, in fact ;) to appear on the group...
Please give us your definition of an assembler (in a few
sentences and not in hundred of pages). Then we can first
discuss this definition an then, using this definition, prove
whether HLA is an assembler or not.
Betov
news:Pine.LNX.4.44.040115...@kevlar.ime.usp.br:
If you live long enough for reading AoA and to become
an "HLA expert" you will yet know nothing about Assembly.
If you mean to learn Assembly, you first need an Assembler.
The actual Assemblers are:
NASM: < http://sourceforge.net/projects/nasm >
RosAsm: < http://betov.free.fr/RosAsm.html >
FASM: < http://flatassembler.net/ >
GoAsm: < http://www.godevtool.com/index.html >
Then, you need some Documentation. There are some, around
each Assembler. Not always as "impressive" as AoA, but,
any case, they have the huge advantage of being Assembly
Documentations. See, for example, B_U_Asm, available from
RosAsm Pages.
Hope this might help. Betov.
Auric__
*****
On 16 Jan 2004 09:28:00 GMT, Betov wrote:
>If you mean to learn Assembly, you first need an Assembler.
>
>The actual Assemblers are:
>
>NASM: < http://sourceforge.net/projects/nasm >
>
>RosAsm: < http://betov.free.fr/RosAsm.html >
>
>FASM: < http://flatassembler.net/ >
>
>GoAsm: < http://www.godevtool.com/index.html >
What about TASM? MASM? AS? A86? Or one of the lesser-known assemblers?
--
auric "underscore" "underscore" "at" hotmail "dot" com
*****
Virginity can be cured.
Odyssey
news:XnF94726DFFB7...@213.228.0.133...
> Lucas de Paiva Pirolla <pir...@ime.usp.br> écrivait
> news:Pine.LNX.4.44.040115...@kevlar.ime.usp.br:
>
> > Hi
> >
> > I started to read the Art Of Assembly book, eletronic version.
> >
> > But in the book everything is in HLA language.
> >
> > My question is: when i finish reading it, will I be able to do
> > _everything_ I do with HLA using pure assembly language? (I know, not
> > including those IF statemantes and so). Or with this book I'm just
> going
> > to learn the concepts of assembly language and then I'll need to read a
> > pure ASM language book??
>
>
> If you live long enough for reading AoA and to become
> an "HLA expert" you will yet know nothing about Assembly.
To be more precise you will no nothing of Betov's own
version of assembly. :) I don't think Randy could get away
calling a book the art of assembly language and have it published
if it was not about assembly language. Come on Betov, you
know better. You accuse Randy of lying and being a swindler.
What do you think you're doing here?
> If you mean to learn Assembly, you first need an Assembler.
> The actual Assemblers are:
>
> NASM: < http://sourceforge.net/projects/nasm >
>
> RosAsm: < http://betov.free.fr/RosAsm.html >
>
> FASM: < http://flatassembler.net/ >
>
> GoAsm: < http://www.godevtool.com/index.html >
>
> Then, you need some Documentation. There are some, around
> each Assembler. Not always as "impressive" as AoA, but,
> any case, they have the huge advantage of being Assembly
> Documentations. See, for example, B_U_Asm, available from
> RosAsm Pages.
You can use any of the other assemblers that Betov suggested but the
problem is that you won't find much or any tutorials with them. Most
of them assume that you already know assembly so their documentation
just explains how to use the assembler. AOA is still the best option
for learning assembly because you can switch to any other assembler
when you're done with it.
> Hope this might help. Betov.
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
Betov
news:hvhf0099i6hg09850...@4ax.com:
> What about TASM? MASM? AS? A86? Or one of the lesser-known assemblers?
>
Well, TASM and MASM are commercial products.
TASM is no longer supported since ages.
MASM technically can not be recommended.
Both TASM and MASM are "Assembly Compilers"
(not Assemblers).
For AS, i never gave it a try. So, i cannot
talk about an Assembler i don't really know.
A86 was my prefered Assembler in the good old
Dos days, But,... what use nowadays? Also,
though perfectely useable, A86 syntax is not
completely perfect.
Betov.
Betov
@unibwm.de:
> Please give us your definition of an assembler (in a few
> sentences and not in hundred of pages). Then we can first
> discuss this definition an then, using this definition, prove
> whether HLA is an assembler or not.
>
KaïKaïKaïKaïKaïKaïKaïKaï!!!!!.......... Herbert!
:)) :)) :))
Beth already made the full demonstration that HLA
is a ... banana, you know...
"No line can be drawn in the sand", and the like.
KaïKaïKaïKaïKaïKaïKaïKaï!!!!!..........
She even wrote an HLA Demo to "prove that HLA was
_Assembly_able_". I am yet waiting for her Demo
showing that Power Basic is "_Assembly_able_", but
she does not seem to mean to do this. I wonder why.
As Hutch said recently,... Power Basic is a much
better Assembler than... RosAsm... So,... Why not?
KaïKaïKaïKaïKaïKaïKaïKaï!!!!!..........
Betov.
Herbert Kleebauer
> You can use any of the other assemblers that Betov suggested but the
> problem is that you won't find much or any tutorials with them. Most
> of them assume that you already know assembly so their documentation
> just explains how to use the assembler.
That's the only documentation which belongs to an assembler. There
is also no tutorial "How to write great novels" shipped with WORD.
If you want to learn the language of the processor, never use
second level literature like AOA or other assembler books. For Intel
processors use:
http://developer.intel.com/design/pentium4/manuals/245471.htm
http://developer.intel.com/design/itanium/manuals/iiasdmanual.htm
If you want to learn the operating system interface use the
original documentation for your OS. For WINDOWS e.g.:
> AOA is still the best option
> for learning assembly because you can switch to any other assembler
> when you're done with it.
What does this sentence mean? Maybe you wanted to say:
If you have read AOA you have to switch to any other assembler
when you want to learn assembly programming.
Randall Hyde
"Herbert Kleebauer" <kl...@unibwm.de> wrote in message
news:4007ACD1...@unibwm.de...
> Beth wrote:
>
>
> Please give us your definition of an assembler (in a few
> sentences and not in hundred of pages). Then we can first
> discuss this definition an then, using this definition, prove
> whether HLA is an assembler or not.
Oh yes, here we go again.
try
http://webster.cs.ucr.edu/Page_hla/HLADoc/HTMLDoc/HLARef.html#pgfId-1035157
and
http://webster.cs.ucr.edu/Page_hla/HLADoc/HTMLDoc/HLARef.html#pgfId-1035246
and
http://webster.cs.ucr.edu/Page_hla/HLADoc/HTMLDoc/HLARef.html#pgfId-1016580
Cheers,
Randy Hyde
Randall Hyde
> Odyssey wrote:
>
>
> That's the only documentation which belongs to an assembler. There
> is also no tutorial "How to write great novels" shipped with WORD.
Just because you feel that approach works for you doesn't mean it
works for anyone else.
As I recall, you also feel that someone should write their own
assembler in order to learn assembly language, right?
Of course, to learn x86 assembly *after you already knew
68K assembly* you wrote an x86 assembler that uses 68K
mnemonics. What a great way to learn assembly! Everyone should
do that :-) (i.e., learn 68K first in order to learn x86 and then
write an x86 assembler using 68K mnemonics). Yep. That's
much better than finding a book that explains how this is done.
Randy Hyde
Rally
news:Pine.LNX.4.44.040115...@kevlar.ime.usp.br...
I haven't actually read "Art of Assembly" but I looked it over some time
ago. I also have no experience with HLA, although I've looked it it some,
too.
I think the answer to your question is that AoA and HLA will teach you asm.
And, as Randall has said, there probably is no more comprehensive book on
assembly programming. It is in fact a very impressive book.
However, I don't think it offers the best approach to learning asm. My
feeling is that learning from the ground up, learning the basics of the CPU
first, and learning how asm builds on those basics, is the best way to learn
asm.
Fortunately you can use the 16 bit version of AoA to learn asm the usual way
with a standard assembler and still have a very comprehensive book, while
learning in a dos environment, which is a much simpler programming
environment. I think this is the best way to learn asm programming.
Barry
Betov
news:4007E9CD...@unibwm.de:
Well said, Herbert.
Thanks for helping recalling that Assembly is the Language
of the Processor, at times it is lesser and lesser evident
for someones.
Betov.
< http://betov.free.fr/RosAsm.html >
Herbert Kleebauer
> > That's the only documentation which belongs to an assembler. There
> > is also no tutorial "How to write great novels" shipped with WORD.
>
> Just because you feel that approach works for you doesn't mean it
> works for anyone else.
>
> As I recall, you also feel that someone should write their own
> assembler in order to learn assembly language, right?
Yes. If you do it the right way and read the processor manual
before writing the first line of assembler code, then it is no
big deal to write a simple assembler. If you ignore FPU/MMX/SSE
instructions and don't implement macro support, this can be
done in a few weeks (using a HLL). The big advantage is, that
you can use what ever syntax you prefer.
> Of course, to learn x86 assembly *after you already knew
> 68K assembly* you wrote an x86 assembler that uses 68K
> mnemonics.
If you are used to move/eor/bsr instead of mov/xor/call why not
use it, it doesn't matter at all. To combine the operand size
with the operator and not with the operand (as done in a HLL)
and to use "opcode src,dest" has nothing to do with the 68k
but is simple the logical way to do it (as I already said,
the Intel syntax was made by sadists for masochists).
> What a great way to learn assembly! Everyone should
> do that :-) (i.e., learn 68K first in order to learn x86 and then
> write an x86 assembler using 68K mnemonics). Yep.
Yes, everyone who really wants to learn assembly programming
should do it. Not learn 68k first, but look at the different
syntax used for all the existing processor architectures
and then write his own assembler using the syntax he prefers.
> That's much better than finding a book that explains how this is done.
A book that explains what? The language of the processor is
explained in the processor manual, the interface to WINDOWS
is explained in the documentation from Microsoft and the
usage of the assembler is explained in it's readme file.
Odyssey
What I mean is when you learn assembly by reading AOA you can
use any assembler you want. :) The instructions in HLA do the same thing
as the instructions in masm and other assemblers. So if someone understands
how the mov instruction works in HLA its not going to cause them a lot
of problems to figure out how it works in masm too.
Anyway what's your definition of an assembler and how does HLA
not qualify as an assembly language?
Beth
Okay, here's a "first shot" at that:
Assembly language is an augmented human-readable notation for
formatting data more easily for _direct_ presentation to the CPU...
Note what I have and haven't said in the above...
It's an "augmented" notation because we're NOT only concern with
"machine instructions"...this you should know better than most, in
fact, as your favourite _directive_ is "DB"...that's NOT a "machine
instruction", it's an assembler directive...other examples would be
"BITS 16/32" in NASM or would be implied in RosAsm's "[ Variable: D$
? ]" (merely a syntactical variant of "DD" there)...there are, of
course, further "augmentations" in various assemblers to the "machine
instructions" such as macros, section declarations, MASM's "HLLisms"
like "invoke" and others...but those first examples I've given: "DB",
"BITS 32" and "[ Variable: D$ ? ]" have been selected _specifically_
to show that _NO_ x86 assembler is able to live without at least
_SOME_ "assembler directives"...even DEBUG understands "DB" and "DW"
in its assembly mode...NASM would be _completely unable_ to work out
the encodings between 16-bit and 32-bit mode without the "BITS"
directive (because the correct encoding to be used entirely depends on
the "mode" the CPU is in...this _could_ be set via a command line
option but that would stop mixed 16-bit / 32-bit coding, such as a DOS
program that goes into protected mode)...
Further, note that I've said "formatting data"...this is because, of
course, CPU instructions are _also_ "data"...they are just "numbers"
in memory locations...what turns them into "code" is that the CPU
fetches them as part of the code stream and interprets them, according
to its encoding rules, as particular instructions...this is another
important distinction for things like placing "DB" directives into a
code stream to "emulate" a machine instruction that's not natively
supported by the assembler...
And this distinction is further of importance because it calls into
question what is specifically meant by "instruction", anyway...ask
wolfgang and he'll tell you that his special hex-encoder-assembler
(much lower-level than most of what we use ;) has the ability to
specify whether a particular "MOV" instruction is a "load" or "store"
version of that instruction...because, indeed, on the x86, it's
possible to encode even this most basic (and other most basic)
instructions in _more than one way_...we can also look to other
commonly used instructions and question them on this facet..."MOVS" is
NOT a real machine instruction...there is a "MOVSB" encoding and then
there's a "MOVSW/D" encoding (the actual size - 16 or 32 bit - being
selected by the segement "mode", the presence or absence of prefixes
and so forth)...this is why, on some assemblers, the "MOVS"
instruction requires a "dummy" operand to specify the desired size
(the opcode itself has NO operands at all, this is part of the
"directive" nature of "MOVS" in many assemblers)...
Hence, "MOV" is a _directive_..."MOVS" is a _directive_...and then,
seeing as we've had a discussion about the "JMP" / "Jxx" instructions
and the issue of "jump size", then we can also see that this is a
_directive_ too on a lot of assemblers...again, there is a short
encoding, a near encoding and a far encoding (for the uncoditional
"JMP")...furthermore, "JMP", like CALL, is capable of _direct or
indirect_ operands (e.g. there's an encoding that uses an immediate in
the instruction and an encoding which jumps indirectly via a memory
address)...
Hence, in total, there are - wait for it - _5_ different encodings of
"JMP" (ignoring prefixes), which is a total of _9_ different actual
forms of "JMP" as 4 of the encodings may take a size prefix to select
16/32 bit, depending on the current CPU "bitage")...does your
assembler provide 9 different "JMP" mnemonics? If not, then where's
our precious "1:1" requirement? Note, also, that any x86 assembler is
going to find "1:1" incredibly difficult because of Intel's own
encodings...some opcodes "double up" and may be 16 or 32 bit,
depending on _both_ the prefix and the current CPU mode...worse, the
meaning of the prefix reverses (toggles) in the different
"modes"...so, that, simply, due to Intel's own encodings, it is
_impossible_ to determine, from looking at the opcodes alone, what we
actually have...it's NOT possible...you may "presume", of course, from
knowing that it's Windows code (got to be 32-bit due to the OS rules
and the prefixes must, therefore, "flip" to 16-bit mode) or by taking
a 16-bit or 32-bit "perspective" on the matter and seeing which is
"most likely"...but, strictly, no x86 assembler will be able to make
the determination without the use of a "BITS"-like directive or to
supply "ambiguous" mnemonics, leaving the "bitage" determination to a
human being...
You could once have claimed "1:1" and so forth on a different
architecture...but Intel's messy encodings actually mean that this
_cannot_ - when we're pedantic to the facts - be true for any x86
assembler, even when you use "ambiguous" mnemonics (and I've never
seen a _single_ assembler which does use "ambiguous" mnemonics like:
"mov (e)ax, (e)bx" :)...not that it matters because, note, that if
we've got a constant, then the interpretation is _crucial_...is it
"mov ax, 1234h; int 21h" or "mov eax, 123421CDh"? Get it wrong and
you've messed up your disassembly in a major way...not only are the
instructions nothing alike but you've "swallowed" up another
instruction if you wrongly take a 32-bit interpretation...
Not even DEBUG can lay claim to being able to operate without
directives in its assembly mode - it has "DB" and "DW" - and even if
DEBUG was expanded to properly include 32-bit instructions and MMX/SSE
and so forth (apparently, someone has done something like this :), it
would still not be most people's "assembler of choice", exactly
because it's limited...remembering that it doesn't use "labels" and
you have to work out all those addresses yourself...
Hence, we've got a pretty damning set of examples: "MOV" (also, "ADD",
"ADC", "SUB", "SBB", "OR", "AND", etc. by extension of the same
principle :), "MOVS" (also, "LODS", "SCAS", "STOS", "INS", "OUTS" by
extension of the same principle ;), "JMP" (also, "JC", "JNC", "JO",
"JNO", etc. by extension of the same principle...worse, throw in the
"synonyms" too..."JE" is the exact same instruction as "JZ", it's just
a convenient synonym...which makes that most certainly a
"directive")...and there's _MUCH MORE_ than merely this...but, seeing
as we've just covered a massive amount of the basic x86 instruction
set, I think the point's been made, hasn't it?
If your definition of x86 assembly includes "1:1" or "no directives"
then your definition describes an impossibility...the Intel encodings
and suggested mnemonics ("Intel syntax") themselves mean it's not
possible...as I was explaining this point to Frank before, it's
actually amusing because AT&T syntax _better_ fulfills that (but still
can't manage it)...
Plus, our "directives" are pretty powerful, you know...they select the
encoding based on the _operand_ in a large amount of cases..."MOV"
alone can cover a number of encodings..."MOV al," cuts things
down...and "MOV eax," or "MOV ax," are dependent on the "bitage"...as
well as the fact that most of these encodings are "reverseable"...and
movements to segment register (CS, DS, etc.) or system registers
(CR0, etc.) are encoded completely differently and have a much more
limited application (can't write an immediate directly into a segment
register with "MOV", for example)...yet, all these things are being
covered by a _single_ "MOV" mnemonic!! Sounds suspiciously "HLL", in
fact...
Your notion of "purity" is actually a _myth_...the CPU itself and its
encodings do not permit it themselves...
But, you know, as interesting as that is, that _ISN'T_ my defence of
HLA at all...that's just pointing out, before we even start, that
you're trying to argue for something that itself is non-existent...in
short, you've failed before you've started because this "purity" only
exists in people's imaginations...if you really relate _any_
assembly - that you may deem "pure" - to the actual encodings, there's
an awful lot of jiggery-pokery involved..."isn't there?", she says to
all those who've played with the encodings and might have attempted an
assembler of some kind...
What, in fact, does HLA do? How does it differ from what you call
"pure ASM" but I prefer to call "traditional ASM" (in answering this
question, we'll begin to see why I make that distinction and stick by
it)? Let's compare differences, shall we?
Data declarations, under any assembler, are _directives_...there is no
"Intel syntax" for them nor "standards" nor any agreement...the best
we have is "DB", "DW", "DD" and so forth as a loose "de facto"
standard for this...but then again, MASM lets you call these "BYTE",
"WORD", "DWORD"...RosAsm calls them "B$", "W$", "D$"...NASM has a
different set of names for uninitialised and initialised versions
("DB" vs. "RESB", "DW" vs. "RESW", etc. :)...some assemblers support
structures, some don't (plus "unions" too)...and, note, though
"structure support" usually includes some "dot notation" thing, it's
quite possible to simply allow _data_ to be declared in structures
(for the naming and "sizeof" benefits) but insist that instructions
are written in a more "pure" way ("[ ebx + SecondMember ]"), not that
there _is_ any "standard" or Intel ever specify this element of
assembly language at all in their documentation...
None of this relates to "machine instructions"...so, all of these
variant implementations are as good as one another...and,
fundamentally, "data is data is data"...a byte is always a byte, a
dword is always a dword...it matters not what programming language you
use, this is always the case and data declarations are semantically
equivalent...whereas, we couldn't be too sure what the ASM for C's
"VarA++" might equate to (more than one possibility there), we _know_
100% that "char VarA = 3;" _is_ equivalent to "VarA db 3"...whereas
HLLs may "insert" things and we don't know what's happening "behind
the scenes" with the _CODE_, there is no such problem with _data
declarations_...
Hence, HLA recognises this and uses 100% HLL-inspired data
declarations (but also includes ASM-inspired alignment options too,
for precise location of data...note, NO such thing under supposedly
"real" RosAsm...it takes care of all the data and its alignment and so
forth in totally 100% "HLL" way...for example, in one "title", I
finish with a word data declaration and at the start of the "next"
title, I have another word data declaration...these "titles" are all
listed equally so when I say "next", I'm referring to the location of
the "tab" in the control, goodness knows if that actually relates to
its location in the source file...further, this data all gets thrown
into the data section...there is NO method supplied by this "real"
assembler in order to choose where - code or data - nor is a single
thing mentioned about "alignment" or "padding" in the documentation...
So, are my two word-sized data declarations aligned to the byte, word,
dword, paragraph or page? Don't know...because they are less than
32-bits, does RosAsm "pad" these out to dword-sizes for "alignment"
reasons? Don't know...
Hence, we don't actually know with this supposedly "nothing behind the
scenes real assembler" whether it's actually "safe" and "correct" to
grab _both_ word-sized data declarations in one dword-sized operation
(that is, "mov eax, FirstWord" which "picks up" the second word at the
same time because - we Hope though RosAsm does not explain nor
guarantee - that the second word is right next door in the data
section...and we have no choice at all about it being in a data
section, as RosAsm - in a way that's 100% "HLL" to me - deals with
data "behind the scenes"...you can't control what it does, you don't
really know what it's doing (alignment? Padding? No explanation of
that in the documentation)...
Well, sorry, if that's "pure ASM" in demonstration then HLA is far
better...I can put the data wherever I like and I can align it...I
_know_ - both because it's clear from the source and because Randy has
detailed all the issues in his comprehensive reference manual and
AoA - whether it's "safe" to grab two WORD-sized pieces of data with a
single 32-bit instruction...better yet, I can use the "union"
declarations to _specifically write out_ that this data can be
accessed in more than one way, giving me the ability to assign
meaningful symbolic names and make it totally understandable to anyone
else reading that this data gets used as one 32-bit _and_ two 16-bit
values...and there's not an ounce of difference between this "union"
and using "DW" twice, then an "ORG" to "backtrack" and declaring a
"DD" over the top of them...in a sense, all "union" does is give a
much easier to read notation for getting the assembler to do exactly
that...needless to be said, there is NOT the slightest difference
whatsoever in what data actually ends up in the final file, regardless
of syntax..."data is data is data"...
HLA's use of a full and comprehensive "HLL-like" data declarations is
the thing that I found absolutely brilliant...formatting out things
like "tables of table to pointers to tables to procedures", which
_are_ very useful because many of the best algorithms can use very
complex data structures...it's a doddle...you can create a "template"
structure with "data", "previous" and "next" pointers and then declare
your "doubly linked list" (a common enough requirement for many good
algorithms, right? :) with complete ease...doing the same using "DB"
alone is a total fudging nightmare in comparison...
What about HLA's "procedure" assistance? You know, don't ask me too
much about it, as I never use it...I switch them off with a couple of
directives at the start of the source code and then do everything
myself...because, you see, it's entirely true...you can simply
_IGNORE_ these things...they DO NOT in any way "get in your
way"...data typing? Same thing, in fact...HLA can do it but if you
declare things as "BYTE", "WORD" and "DWORD" then the only thing HLA
checks is _size_, just the same as any other assembler...those silly
"IF" statements? Again, wouldn't know...never use them...but I did
once have a go for some example code I posted up here and the HLA "IF"
is much like the MASM one, except that, in fact, it's _more limited_
and guarantees that it _WON'T_ play around with registers, something
MASM does NOT guarantee...
The macro stuff, of course, is all _compile-time_ pre-processing...it
all goes on during compilation and is all done by run-time...these are
merely just methods of helping a programmer to write their code by
wrapping up "common" things in simple macros...HLA macros are more
powerful - that is, they provide more facilities for writing them -
but they don't differ (other than syntax) to the essence of macros on
any other assembler that has such things...
The machine instructions themselves? Well, the operands are reversed
and put into brackets...that's about all we can say there...nothing
else is any different about those at all...oh, fair enough, SSE
instructions aren't currently supported because Randy didn't have a
machine to test that out on at the time...you can, of course, "DB"
your own versions and use a macro so you'd never know the
difference...many assemblers also don't have SSE, simply because those
instructions turned up after the assembler was last updated...and
nothing stops them being included, Randy just didn't have them
originally for _practical_ reasons (no SSE-capable machine, can't test
it so best to leave them out until Randy can get an SSE-capable
machine...in the meantime, if it's needed then use "DB", just as you
would do with any other assembler for non-native instructions)...
You're fighting a phantom; Because you know what's really "HLL" here?
This attitude...things are _ONLY_ "behind the scenes" in your mind
because you've not even downloaded HLA and given it a go to see what
it is...RosAsm's data declarations are pure HLL because only HLLs give
me no choice or explanation of what's happening (heck, _C_ and _C++_
are lower-level in some regards)..."Intel syntax" is HLL...these
notiongs of "purity" demonstrate that you've not really _studied_ the
encodings sufficiently and considered the ramifications of them to
realise that "pure 1:1" is a complete nonsense on Intel CPUs...
I'm a low-level, do-everything-yourself, explicit coder and I use
HLA...and there's NO conflict between the two whatsoever...I know
that's totally NOT what many people want to hear but it's _fact_ and
it would be wrong of me to lie otherwise just to support some "phantom
world" in your own imagination...to massage your ego that you're a
"real" coder, with all the macho superiority nonsense that comes along
with that...unfortunately for you, as you'd like it were I "clueless
newbie" about this, I was not born yesterday about these things and do
know what I'm talking about...I've hand-rolled my own PE files and
it's not particularly difficult or complicated...you might think using
"DB" to do this makes you some "macho" kind of guy but it's not that
impressive...so, you read the PE file format documents? Big bloody
deal...
Because, let's cut to the chase here, this has very little to really
do with ASM - "pure" or otherwise - it all to do with being the
"biggest" in the group...and Randy's sitting at the top in everyone's
perceptions so you gain "kudos" as "guru", if you topple him from his
position...it's an awkward little thing regards the "guru" status that
Randy _has_ read those boring (and they really are boring, aren't
they? ;) "decompiler theory" papers and he took the time to understand
them...because what's a real pain about Randy getting in the way of
this "supreme guru award" is that he takes a _professional_ attitude -
he looks these things up and _makes sure_ he understands them -
whereas you want the title but you don't want the work...you'd like to
be able to "hack" your way to the top, yeah? "I'm a practical coder
and this makes me the best!", right? Except, unlike some of the
teachers you may have met, Randy can walk the walk just as well as he
can talk the talk...one tends to keep quiet about this for
"politeness" reasons but the size and complexity of HLA, the
productivity of spitting that out while producing _professional_
quality documentation _and_ he still has time to help people out and
fight an argument or two on a few groups (hey, I stick to one group
because I couldn't deal with the volume handling CLAX as well...I just
"look-in" from time to time now instead :)...he's in a _totally
different league_ to most of us...different ballpark, sunshine...
And _THAT_ is what this all really about...whereas other assemblers
are rooted in '60s ideas and just try to desparately "extend" that to
modern OSes, HLA just said "sod it!" and looked again at assembly with
a modern perspective...but Randy _has_ stayed true to the roots and it
is a _true assembly language_ at the core...and the "old guard" are
just disturbed that they are "stuck" with the old ways and can't
comprehend the "new"...
This is simply an actual demonstration of the famous saying: "New
ideas never succeed, they simply wait around for the old ideas - and
the keepers of the old ideas - to eventually die off"...
Beth :)
Beth
> Odyssey wrote:
> > AOA is still the best option
> > for learning assembly because you can switch to any other
assembler
> > when you're done with it.
>
> What does this sentence mean? Maybe you wanted to say:
> If you have read AOA you have to switch to any other assembler
> when you want to learn assembly programming.
Completely false; I was using other assemblers and switched _to_ HLA
because, simply, it's the best of the lot of them...
Beth :)
Auric__
*****
>A86 was my prefered Assembler in the good old
>Dos days, But,... what use nowadays? Also,
>though perfectely useable, A86 syntax is not
>completely perfect.
What's wrong with it? (I ask because I've never used it.)
--
auric "underscore" "underscore" "at" hotmail "dot" com
*****
No one tests the depth of a river with both feet.
Beth
> Lucas de Paiva Pirolla wrote:
Ah, this is a personal issue...indeed, some people learn better "top
down" and some learn better "bottom up"...if you _know_ you're a
"bottom up" kind of person, then, indeed, perhaps AoA might not be the
best choice for you...for example, some people around here came to
assembly programming "from below", so to speak...they are electronics
people who dealt with the actual circuit boards and that kind of thing
and then "graduated" up to assembly language (programming their
home-made boards giving them a "taste" for ASM programming that they
liked doing :)...
But, in that regard, AoA is clearly signposted as "previous HLL
experience recommended"...it's targetted at the HLL coder who wishes
to _move down_ to assembly...that's also why Rene's accusation of
"polluting" these people with "HLLisms" is an absurd nonsense...AoA's
target audience _ARE_ HLL coders and the way it progresses gradually
introduces them to lower-level ASM coding as they go...
It's a "top down" approach because this approach _usually_ is best
across a wide range of people...generally in educational
establishments, in fact, this approach is used because, for the
"average" person, this works best...note, though, of course, you may
not personally be an "average" person...OR, as I say, you've got no
HLL experience but some electronics experience and, thus, are
naturally "coming from below" to the topic...
AoA may, indeed, prove awkward to people who're better with "bottom
up" or who are naturally coming from that direction or have no idea
about HLLs to begin with...indeed, AoA may prove more of an obstacle
than a help if you've got to go learn a HLL first in order to
"de-learn" the HLL to learn ASM...that's "against the grain" of what
AoA is presuming about your experience and direction...that's why,
basically, it has the "previous HLL experience recommended" label
stuck on it...
But, of course, the amount of HLL programmers out there makes AoA's
approach the best regards the "average" ASM learner...taking a
programmer interested in learning ASM (bit who doesn't currently know
it at random, then AoA will prove the best approach...
If you feel, though, that you don't fit the bill here then Randy has
always broken the official taboo and mentions Jeff Duntemann with his
"Assembly step-by-step" (which takes the _reverse_ perspective of
"bottom up" assembly :) as a recommended text instead...I've not read
this book, though, so I myself tend not to comment (though, I have
talked to Jeff and he's got a great sense of humour and seems like a
real nice guy too :)...but for "bottom up", I've seen Randy repeatedly
turn to recommending this book instead of his own because AoA is
designed to work a certain way: "top down"...from HLL to ASM...
This is something else you may notice in Rene and Herbert and others
comments about HLA...they themselves, clearly, are "bottom up"
programmers...Rene's assembly text with his RosAsm assembler _is_
called "B_U assembly" (where B_U means "bottom up" :)...Herbert
suggests reading the Intel manuals and then writing your own PE files
and _building up_...
What they seem to fail to appreciate - and that's confirmed with
strange illogical comments like: "No! Randy will pollute these newbies
with HLL pollutions!" when AoA is _designed_ for HLL coders and
"un-learns" HLL to teach ASM...showing that they fail to grasp who the
intended audience is (top down coders) and that they are NOT the same
people they are (bottom up coders) - is this difference in intended
audience...you _can't_ go and "pollute" HLL coders with "HLLisms"
because they've _already_ got them...AoA, in fact, works to slowly
"clean up" those pollutions in a gradual manner, topic by topic...
Hence, the "appropriateness" of AoA to you is, ultimately, a personal
matter...are you a HLL coder already? Do you prefer to learn things
"top down" or "bottom up"?
> Fortunately you can use the 16 bit version of AoA to learn asm the
usual way
> with a standard assembler and still have a very comprehensive book,
while
> learning in a dos environment, which is a much simpler programming
> environment. I think this is the best way to learn asm programming.
Yes, it's an alternative that some people may prefer...but, of course,
if someone intends to write Windows applications then learning DOS is
"going around the houses" to get there...not that that necessarily is
a "bad thing" or anything...just it's fair to point out that if your
destination is Windows coding then going via DOS is "taking the scenic
route to get there", so to speak...it doesn't make it "wrong" or
anything, of course...just it's only fair to warn about that need for
greater patience...one thing about that approach is that you'll get to
grips with more than one OS in doing so (although, DOS is "outdated"
in modern OS architecture designs...again, no insult to DOS because
this fact is often _brilliant_, as you can actually get your hands
dirty with hardware access on DOS without any fuss or bother...but,
again, a warning that you're learning methods that all the other
modern OSes like Windows and Linux have actually "undone")...
Oh, one last nit-pick: What's a "standard assembler", anyhow? Assembly
language has _NO_ "standard" (at least, none that anyone pays any
attention to ;) and no two assemblers are alike (MASM and TASM are the
closest together...but then compare TASM in ideal mode doing OOP to
MASM and realise that even these "close cousins" disagree in big ways
in places...in fact, to an extent, their "disagreement" has fuelled
the variety of diversity we see...I'm sure that it wasn't total
coincidence that NASM's "cleaned up" syntax wasn't at least partly
inspired by TASM's attempt to "clean up" MASM syntax in IDEAL mode
because kick out "offset" and they are almost identical...did Borland
start this avalanche we now see without meaning to? ;)...perhaps
you'll disagree but I think that perhaps "traditional assemblers" is
the best term to differentiate between HLA from the more "Intel
syntax" traditional kind of assembly language...
Beth :)
Randall Hyde
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:Y%%Nb.403$T_6...@newsfep3-gui.server.ntli.net...
> Herbert Kleebauer wrote:
>
> The machine instructions themselves? Well, the operands are reversed
> and put into brackets...that's about all we can say there...nothing
> else is any different about those at all...oh, fair enough, SSE
> instructions aren't currently supported because Randy didn't have a
> machine to test that out on at the time...you can, of course, "DB"
> your own versions and use a macro so you'd never know the
> difference...many assemblers also don't have SSE, simply because those
> instructions turned up after the assembler was last updated...and
> nothing stops them being included, Randy just didn't have them
> originally for _practical_ reasons (no SSE-capable machine, can't test
> it so best to leave them out until Randy can get an SSE-capable
> machine...in the meantime, if it's needed then use "DB", just as you
> would do with any other assembler for non-native instructions)...
Actually, the SSE instructions have been there for a while now (I've got
a PIV machine at work I could run tests on).
Of course, you will need to use an underlying assembler that *also*
handles those instructions. MASM 7 seems to work okay, MASM 6
does not. I think FASM handles them.
Cheers,
Randy Hyde
Randall Hyde
>
>
> Yes. If you do it the right way and read the processor manual
> before writing the first line of assembler code, then it is no
> big deal to write a simple assembler. If you ignore FPU/MMX/SSE
> instructions and don't implement macro support, this can be
> done in a few weeks (using a HLL). The big advantage is, that
> you can use what ever syntax you prefer.
And it really helps if you've learned assembly on another processor first,
as you did.
When you've taught about a thousand students with your method, come
back to me and tell me how well it works.
> > Of course, to learn x86 assembly *after you already knew
> > 68K assembly* you wrote an x86 assembler that uses 68K
> > mnemonics.
>
> If you are used to move/eor/bsr instead of mov/xor/call why not
> use it, it doesn't matter at all. To combine the operand size
> with the operator and not with the operand (as done in a HLL)
> and to use "opcode src,dest" has nothing to do with the 68k
> but is simple the logical way to do it (as I already said,
> the Intel syntax was made by sadists for masochists).
If you already know "IF" and "WHILE", why not use it?
What a great idea you have -- leverage your existing knowledge
to learn something new. I'll have to try that idea out sometime :-)
>
> Yes, everyone who really wants to learn assembly programming
> should do it. Not learn 68k first, but look at the different
> syntax used for all the existing processor architectures
> and then write his own assembler using the syntax he prefers.
And what about those who don't care to write an assembler,
don't have the background to write an assembler, don't even
care about machine instruction encodings, etc.? I.e., the people
who just want to solve their particular problem in assembly
language? While there is *some* benefit to doing what you
suggest, it hardly teaches assembly language *programming*.
There is a *big* difference between knowing how to encode
a MOV instruction and knowing how to use that MOV instruction
to solve a real-world problem. Your pathway to learning assembly
doesn't address that fact.
>
> > That's much better than finding a book that explains how this is done.
>
> A book that explains what? The language of the processor is
> explained in the processor manual, the interface to WINDOWS
> is explained in the documentation from Microsoft and the
> usage of the assembler is explained in it's readme file.
There's a big difference between knowing what a particular
machine instruction does (which is what the processor manuals
teach you) and knowing how to use that machine instruction
to solve a larger problem. You've been blinded by your many
years of programming experience to this issue; let me assure you,
I can teach a student what 30 or 40 machine instructions do within
a few lectures. And they'll really *know* (as measured on a test)
what each instruction does. But they still won't have a clue how to
effectively put those instructions together to solve real problems.
Again, if you think your methods are so effective, sign up to
teach a course at your local college and see how well those
methods work. I think you'll be a little disappointed.
Cheers,
Randy Hyde
Beth
Cool; Then have you updated the documentation about this? I could have
sworn I saw it still say that it was missing...ah, mind you, I've not
updated the HLA documentation quite as regularly as HLA itself...or
maybe I'm just remembering something from an older version that
actually isn't there anymore and I'm just remembering wrong...
Anyway, whatever...cool...hence, that "drawback" isn't even present as
I'd thought...
Beth :)
Beth :)
Betov
6....@newsfep3-gui.server.ntli.net:
> [...]
Here we go again with tons of bullshit about HLA
being an Assembler. Well,... just one thing:
> So, are my two word-sized data declarations aligned to the byte, word,
> dword, paragraph or page? Don't know...because they are less than
> 32-bits, does RosAsm "pad" these out to dword-sizes for "alignment"
> reasons? Don't know...
RosAsm syntax is perfectely clear about this:
For Data Declarations, "[" actually means:
1) Start a new set of Data.
2) Aling32.
If "Align32" _not_ wanted, the syntax is: "[<".
Notice that, in some future (when i will have
time to review this...), the convention will be
slightly modified to the more accurate:
1) Start a new set of Data.
2) Align on the boudary required by the next
coming Size Marker. Example:
"[MyqWord: Q$ 0FFFF564]"
>>> Align64 assumed. Instead of the actually hand made:
"[<64 MyqWord: Q$ 0FFFF564]"
Betov.
Betov
$zj7....@newsread1.news.pas.earthlink.net:
> Of course, you will need to use an underlying assembler that *also*
> handles those instructions.
I hope you don't mean... RosAsm.
What a shame for me, if ever... :))
Betov.
Betov
news:bu9tas$fes3l$1...@ID-213936.news.uni-berlin.de:
> What I mean is when you learn assembly by reading AOA you can
> use any assembler you want. :) The instructions in HLA do the same
> thing as the instructions in masm and other assemblers. So if someone
> understands how the mov instruction works in HLA its not going to
> cause them a lot of problems to figure out how it works in masm too.
>
If, by any fortune, you ever succeed to understand what
_is_ "close to" Assembly in some HLA Source and what is
not Assembly at all.
Second, Master Pdf did his best, here, to make it as
difficult as possible, -in order to not have beginners
switching from his HLL to an Assembler-, by, on design,
and for this only one reason, inverting the usual way
for writing Asm Instructions.
Third, when you learn a Language, your way of thinking
the programming is influenced by this language. The
way of thinking pushed by Master Pdf HLL is radicaly
incompatible with Assembly. That mean, when, even formaly,
a HLA user would switch to an Assembler, he would have
the biggest difficulties to ever access to the 'thinking
Assembly".
Betov.
< http://betov.free.fr/RosAsm.html >
Betov
6....@newsfep3-gui.server.ntli.net:
> Completely false; I was using other assemblers and switched _to_ HLA
> because, simply, it's the best of the lot of them...
>
You have to admit that you are an extreme case.
There are usually exeptions to most rules. Though,
in that particular case, this is exception is really
amaizing.
I simply hope that you as as bad programmer as original,
because, if not, having people writing great Applications
with that packet of shiet would be really a terrific
damage to the future of Assembly.
Betov.
Betov
@newsfep3-gui.server.ntli.net:
> But, in that regard, AoA is clearly signposted as "previous HLL
> experience recommended"...it's targetted at the HLL coder who wishes
> to _move down_ to assembly...that's also why Rene's accusation of
> "polluting" these people with "HLLisms" is an absurd nonsense...AoA's
> target audience _ARE_ HLL coders and the way it progresses gradually
> introduces them to lower-level ASM coding as they go...
>
In other words:
People already knowing much about programming
could eventually learn something with AoA.
For the pure beginners, there'd better read...
B_U_Asm and save themselves from a much slower
access to Assembly...
Do you re-read what you write, from time to
time, Beth?
Betov.
The Half A Wannabee
> "Beth" <BethS...@hotmail.NOSPICEDHAM.com> écrivait news:ta3Ob.3$EI4.0
> @newsfep3-gui.server.ntli.net:
>
> Do you re-read what you write, from time to
> time, Beth?
LOL How would she find time for that ?
>
> Betov.
>
> < http://betov.free.fr/RosAsm.html >
>
>
>
wolfgang kern
"Odyssey" asked:
| What I mean is when you learn assembly by reading AOA you can
| use any assembler you want. :) The instructions in HLA do the
| same thing as the instructions in masm and other assemblers.
| So if someone understands how the mov instruction works in HLA
| its not going to cause them a lot of problems to figure out
| how it works in masm too.
| Anyway what's your definition of an assembler and how does HLA
| not qualify as an assembly language?
I think the main differences in the definition of the term
"assembler" are found in the programmers targets.
And there there are many within this NG.
My point of view is hardware-oriented and my targets are short,
fast, smart and transparent code to achieve best performance
out from a given piece of hardware.
I write mainly KESYS(os),
HW-drivers(modules),
function-blocks(kernel lib)
and not so often: applications (token/parameter-scripts).
So I first learned everthing about the CPUs and all its
capabilities and weak points by reading Intel/AMD/else docs.
Here I became familiar with the 'orignal' syntax
(I find HLA,GCC and similar are almost unreadable).
If I wouldn't have my own tools, I'd use FASM, TASM or Betovs ASM(s).
But many folks got another background, they come from high-school
with some knowledge of C+,VB,etc.
but they know really no details about hardware.
For them it's vital to get in business asap and will find Randy's
HLA convenient to start with.
Fine so far, but HLA-students never will make it to the roots,
they will remain 'user-level' programmers (from my point of view).
__
wolfgang
wolfgang kern
"Auric__" asked about A86:
| What's wrong with it? (I ask because I've never used it.)
It's limited to the 8086/80186 instruction set,
similar to DOS-debug.
__
wolfgang
wolfgang kern
Hi Beth,
| Completely false; I was using other assemblers and switched _to_ HLA
| because, simply, it's the best of the lot of them...
Perhaps I know why you like HLA,
it satisfy your "maniac typing needs"? :) :) :)
For me there are too many key-strokes required by far.
__
wolfgang
Betov
@newsreader1.utanet.at:
....and the distinction between Addresses and Contents
is quite not as pure and clear as it now is with the
new Assemblers, since the oncoming of NASM, which is
to be consider the actual "Standard" on this particular
point.
Unfortunatly for A86 it, was designed to offer some
"compatibilty" with MASM writing conventions. Terrific
error. Hopefully, we are now free of such stupidities
as having Declarations of symbolics evocations used as
Contents References, with all of the downward stupidites
coming with such an incredible design error.
Betov.
< http://betov.free.fr/RosAsm.html >
Betov
@newsreader1.utanet.at:
Oh! I am jalous, i didn't find that one out before you
did, wolfgang. :)) :)) :))
Betov.
< http://betov.free.fr/RosAsm.html >
Herbert Kleebauer
> > Please give us your definition of an assembler (in a few
> > sentences and not in hundred of pages). Then we can first
> > discuss this definition an then, using this definition, prove
> > whether HLA is an assembler or not.
>
> Okay, here's a "first shot" at that:
>
> Assembly language is an augmented human-readable notation for
> formatting data more easily for _direct_ presentation to the CPU...
??????????
>
> Note what I have and haven't said in the above...
Now exactly that happened which I tried to avoid with the words:
(in a few sentences and not in hundred of pages)
I can't answer all this, so I will first give a general
statement and then just a few remarks to your posting.
In an extremely simplified view (ignoring any I/O) a computer
is a combination of a CPU and memory. The memory stores
instructions for the CPU as well as the data for the these
instructions. When a program is started, a part of the
memory is initialized with a sequence of bytes (the
code and data for this program) and the execution is
started by loading the program counter with an address
within this byte sequence. Programming is the generation
of this byte sequence.
The simplest way of programing is to use a hex editor.
If you know all the opcode values for all the different
processor instructions and calculate all operand and
branch address by hand, a hex editor is all you need
to generate this byte sequence, but it is very tiring
for larger programs. As an example we could write the
following program using a hex editor:
a0 07 00 fe c0 eb f9
Because it is very difficult to remember all the
numbers for the opcodes and to calculate all addresses
by hand, we could make life a little bit easier by using
symbolic names for the opcodes and addresses. Replacing
the opcode "a0" by "move.b" and the address "0007" by
"dat" etc. we get an equivalent representation of the
above program which is much easier to write and to
understand:
loop: move.b dat,r0
inc.b r0
br.b loop
dat: dc.b 10
If this program is feed to the assembler, we get the same
byte sequence as above:
00000000: a0 0007 loop: move.b dat,r0
00000003: fe c0 inc.b r0
00000005: eb f9 br.b loop
00000007: 0a dat: dc.b 10
loop........... 00000000 dat............ 00000007
We still have the functionality of the hex editor: the
dc.b, which is the main instruction of any assembler
because it is able to replace any other instruction.
Note that "move.b" also is not a processor instruction
(there are no processor instructions at all in an
assembler program, the processor instructions are
stored in the output file of the assembler) but an
assembler instruction which instructs the assembler to
write the appropriate opcode to the output file.
While the use of an assembler simplifies the generation
of a program it doesn't hide anything. You are using
nothing but the language of the processor (using
symbolic names for opcodes and addresses). After resolving
the symbolic names you can translate any line in the
assembler source to the corresponding byte sequence without
looking at any other line in the source. This makes
the assembler language the ideal language to learn
to understand the working of a CPU, which is the
main reason to learn assembly programming.
Such a "real" assembler surely isn't well suited to write
"real" applications. You can improve it by adding macro
support, but a Macro Assembler isn't an assembler anymore,
like a motor bicycle isn't a bicycle (In German we have to
words: Zweirad for a vehicle with two wheels and Fahrrad
for a Zweirad driven by muscle power. I asked an English
colleague who told me, that in English there is only the
one word bicycle which normally is interpreted as Fahrrad
and not as Zweirad). You can't translate any line of the
source independent from all the other lines anymore
(which is also true if you add branch optimization).
You can also add some HLL features to make programming
still more easier, but the result has nothing to do with
an assembler. Finally you will get a real HLL compiler
with inline assembler support. This inline assembler
mostly is a "real" assembler again.
> It's an "augmented" notation because we're NOT only concern with
> "machine instructions"...this you should know better than most, in
> fact, as your favourite _directive_ is "DB"...that's NOT a "machine
> instruction", it's an assembler directive...other examples would be
> "BITS 16/32" in NASM or would be implied in RosAsm's "[ Variable: D$
> ? ]" (merely a syntactical variant of "DD" there)...there are, of
> course, further "augmentations" in various assemblers to the "machine
> instructions" such as macros, section declarations, MASM's "HLLisms"
> like "invoke" and others...but those first examples I've given: "DB",
> "BITS 32" and "[ Variable: D$ ? ]" have been selected _specifically_
> to show that _NO_ x86 assembler is able to live without at least
> _SOME_ "assembler directives"...even DEBUG understands "DB" and "DW"
There are only assembler instructions and no processor instructions
in an assembler source file. The processor instructions are in the
output file of the assembler.
> in its assembly mode...NASM would be _completely unable_ to work out
> the encodings between 16-bit and 32-bit mode without the "BITS"
> directive (because the correct encoding to be used entirely depends on
> the "mode" the CPU is in...this _could_ be set via a command line
> option but that would stop mixed 16-bit / 32-bit coding, such as a DOS
> program that goes into protected mode)...
What do you want to say here? It is obvious that you have to tell
the assembler for which processor mode the output should be
generated (even my trivial assembler has this instruction:
seg16 / seg32 ).
> Further, note that I've said "formatting data"...this is because, of
> course, CPU instructions are _also_ "data"...they are just "numbers"
> in memory locations...what turns them into "code" is that the CPU
> fetches them as part of the code stream and interprets them, according
> to its encoding rules, as particular instructions...this is another
> important distinction for things like placing "DB" directives into a
> code stream to "emulate" a machine instruction that's not natively
> supported by the assembler...
>
> And this distinction is further of importance because it calls into
> question what is specifically meant by "instruction", anyway...ask
> wolfgang and he'll tell you that his special hex-encoder-assembler
> (much lower-level than most of what we use ;) has the ability to
> specify whether a particular "MOV" instruction is a "load" or "store"
> version of that instruction...because, indeed, on the x86, it's
> possible to encode even this most basic (and other most basic)
> instructions in _more than one way_...we can also look to other
> commonly used instructions and question them on this facet..."MOVS" is
> NOT a real machine instruction...there is a "MOVSB" encoding and then
> there's a "MOVSW/D" encoding (the actual size - 16 or 32 bit - being
> selected by the segement "mode", the presence or absence of prefixes
> and so forth)...this is why, on some assemblers, the "MOVS"
> instruction requires a "dummy" operand to specify the desired size
> (the opcode itself has NO operands at all, this is part of the
> "directive" nature of "MOVS" in many assemblers)...
What has all this to do with the definition of an assembler?
If there are to different opcodes, then either you have
to use two different symbolic names for these instructions
or if you use the same name, then it must be possible to
choose the right opcode by looking at the operands.
> Hence, "MOV" is a _directive_..."MOVS" is a _directive_...and then,
> seeing as we've had a discussion about the "JMP" / "Jxx" instructions
> and the issue of "jump size", then we can also see that this is a
> _directive_ too on a lot of assemblers...again, there is a short
> encoding, a near encoding and a far encoding (for the uncoditional
> "JMP")...furthermore, "JMP", like CALL, is capable of _direct or
> indirect_ operands (e.g. there's an encoding that uses an immediate in
> the instruction and an encoding which jumps indirectly via a memory
> address)...
Same answer as above.
1:1 means, you can convert any line in the source code to
the corresponding output byte sequence (after resolving the
symbolic address) independent of any other line in the source
code. But, as stated above, you have to tell the assembler
for which processor mode (16/32 bit) the output should be
generated.
> Not even DEBUG can lay claim to being able to operate without
> directives in its assembly mode - it has "DB" and "DW" - and even if
> DEBUG was expanded to properly include 32-bit instructions and MMX/SSE
> and so forth (apparently, someone has done something like this :), it
> would still not be most people's "assembler of choice", exactly
> because it's limited...remembering that it doesn't use "labels" and
> you have to work out all those addresses yourself...
>
> Hence, we've got a pretty damning set of examples: "MOV" (also, "ADD",
> "ADC", "SUB", "SBB", "OR", "AND", etc. by extension of the same
> principle :), "MOVS" (also, "LODS", "SCAS", "STOS", "INS", "OUTS" by
> extension of the same principle ;), "JMP" (also, "JC", "JNC", "JO",
> "JNO", etc. by extension of the same principle...worse, throw in the
> "synonyms" too..."JE" is the exact same instruction as "JZ", it's just
> a convenient synonym...which makes that most certainly a
> "directive")...and there's _MUCH MORE_ than merely this...but, seeing
> as we've just covered a massive amount of the basic x86 instruction
> set, I think the point's been made, hasn't it?
Sorry, no point found.
> If your definition of x86 assembly includes "1:1" or "no directives"
> then your definition describes an impossibility...the Intel encodings
> and suggested mnemonics ("Intel syntax") themselves mean it's not
> possible...as I was explaining this point to Frank before, it's
> actually amusing because AT&T syntax _better_ fulfills that (but still
> can't manage it)...
>
> Plus, our "directives" are pretty powerful, you know...they select the
> encoding based on the _operand_ in a large amount of cases..."MOV"
> alone can cover a number of encodings..."MOV al," cuts things
> down...and "MOV eax," or "MOV ax," are dependent on the "bitage"...as
> well as the fact that most of these encodings are "reverseable"...and
> movements to segment register (CS, DS, etc.) or system registers
> (CR0, etc.) are encoded completely differently and have a much more
> limited application (can't write an immediate directly into a segment
> register with "MOV", for example)...yet, all these things are being
> covered by a _single_ "MOV" mnemonic!! Sounds suspiciously "HLL", in
> fact...
As I said above:
What has all this to do with the definition of an assembler?
If there are to different opcodes, then either you have
to use two different symbolic names for these instructions
or if you use the same name, then it must be possible to
choose the right opcode by looking at the operands.
>
> Your notion of "purity" is actually a _myth_...the CPU itself and its
> encodings do not permit it themselves...
>
> But, you know, as interesting as that is, that _ISN'T_ my defence of
> HLA at all...that's just pointing out, before we even start, that
> you're trying to argue for something that itself is non-existent...in
> short, you've failed before you've started because this "purity" only
> exists in people's imaginations...if you really relate _any_
> assembly - that you may deem "pure" - to the actual encodings, there's
> an awful lot of jiggery-pokery involved..."isn't there?", she says to
> all those who've played with the encodings and might have attempted an
> assembler of some kind...
I have failed with what? I think you have failed to understand
what an assembler is.
If you can't determine where the variables are stored in the binary
output of a RosAsm program (by reading only the source code) then
RosAsm also isn't an assembler, but this doesn't make HLA an assembler.
If this is brilliant, why you don't you use C++, C# or java? I never
said, that it isn't easier to write programs with HLA than an
assembler. All I said is, that HLA isn't an assembler an therefore
isn't suited to teach students assembly programming (to help them
to understand the working of the CPU). But if you don't want to
do assembly programming, I don't see any advantage of using HLA.
Use a HLL compiler and if necessary inline assembler or link to
code written in a real assembler.
> What about HLA's "procedure" assistance? You know, don't ask me too
> much about it, as I never use it...I switch them off with a couple of
> directives at the start of the source code and then do everything
> myself...because, you see, it's entirely true...you can simply
> _IGNORE_ these things...they DO NOT in any way "get in your
> way"...data typing? Same thing, in fact...HLA can do it but if you
> declare things as "BYTE", "WORD" and "DWORD" then the only thing HLA
> checks is _size_, just the same as any other assembler...those silly
> "IF" statements? Again, wouldn't know...never use them...but I did
> once have a go for some example code I posted up here and the HLA "IF"
> is much like the MASM one, except that, in fact, it's _more limited_
> and guarantees that it _WON'T_ play around with registers, something
> MASM does NOT guarantee...
If in some points MASM is even worse than HLA, makes this HLA an
assembler?
You have done it, Rene has done it, I have done it and surely also
Randy and many many others have done it. And as you said, it's trivial.
I never said something else. All I said was, that everybody who
learns assembly programming should learn to understand ANY byte in
the generated binary file. Because the DOS com file format is much easier,
I also suggest, that this file format should be used for learning
assembly programming.
> Because, let's cut to the chase here, this has very little to really
> do with ASM - "pure" or otherwise - it all to do with being the
> "biggest" in the group...and Randy's sitting at the top in everyone's
> perceptions so you gain "kudos" as "guru", if you topple him from his
> position...it's an awkward little thing regards the "guru" status that
> Randy _has_ read those boring (and they really are boring, aren't
> they? ;) "decompiler theory" papers and he took the time to understand
> them...because what's a real pain about Randy getting in the way of
> this "supreme guru award" is that he takes a _professional_ attitude -
> he looks these things up and _makes sure_ he understands them -
> whereas you want the title but you don't want the work...you'd like to
> be able to "hack" your way to the top, yeah? "I'm a practical coder
> and this makes me the best!", right? Except, unlike some of the
> teachers you may have met, Randy can walk the walk just as well as he
> can talk the talk...one tends to keep quiet about this for
> "politeness" reasons but the size and complexity of HLA, the
> productivity of spitting that out while producing _professional_
> quality documentation _and_ he still has time to help people out and
> fight an argument or two on a few groups (hey, I stick to one group
> because I couldn't deal with the volume handling CLAX as well...I just
> "look-in" from time to time now instead :)...he's in a _totally
> different league_ to most of us...different ballpark, sunshine...
I never care about persons. If somebody says something, which I
think is wrong, then a say this and it doesn't matter if it is
a carpenter, a professor or somebody who got the nobel price.
> And _THAT_ is what this all really about...whereas other assemblers
> are rooted in '60s ideas and just try to desparately "extend" that to
> modern OSes, HLA just said "sod it!" and looked again at assembly with
> a modern perspective...but Randy _has_ stayed true to the roots and it
> is a _true assembly language_ at the core...and the "old guard" are
> just disturbed that they are "stuck" with the old ways and can't
> comprehend the "new"...
>
> This is simply an actual demonstration of the famous saying: "New
> ideas never succeed, they simply wait around for the old ideas - and
> the keepers of the old ideas - to eventually die off"...
If you invent a motorbike call it motorbike and not bicycle.
Nobody has said HLA is bad (ok, I think a HLL is better),
but HLA isn't an assembler and it shouldn't be called an
assembler and it is a very bad thing (for the students) if
it is used to teach assembly programming.
Randall Hyde
> Beth wrote:
>
> 1:1 means, you can convert any line in the source code to
> the corresponding output byte sequence (after resolving the
> symbolic address) independent of any other line in the source
> code. But, as stated above, you have to tell the assembler
> for which processor mode (16/32 bit) the output should be
> generated.
Herbert, maybe I misunderstand what you're trying to say here,
but it's pretty obvious the 16/32 bit mode directive breaks the
1:1 translation. In particular, a directive like USE16 affects
a large number of the instructions and their corresponding
object code emission. Therefore, the use of those instructions
is not independent of any other line in the source file. In
particular, they are *quite* dependent on directives like
USE16 and USE32.
Even ignoring such issues, your statement still isn't very
correct. After all, the byte sequence emitted for "mov eax, i"
is *completely* dependent upon the definition of "i". If it's
a symbolic constant, then you get one opcode (and the value
of the emitted code depends entirely on the value you associate
with constant "i", making that emitted code dependent upon
i's definition). If it's a memory reference, the opcode emission
depends upon the definition of "i" (i.e., where it appears with
respect to other variable definitions in the file). Again, that's
hardly independent of any other statement in the file.
Then, of course, there are target labels and so on...
>
> As I said above:
> What has all this to do with the definition of an assembler?
> If there are to different opcodes, then either you have
> to use two different symbolic names for these instructions
> or if you use the same name, then it must be possible to
> choose the right opcode by looking at the operands.
I think you confuse the definition of an assembler with the
definition of an "assembly language". If you want to know
what an *assembler* is, then yes, you have to learn all
this stuff about instruction encoding and so on. If you want
to learn to program in assembly language, this information is
*not* necessary. In fact, the whole purpose of developing
an assembler in the first place (back in the days when they
called them "auto-coders") was specifically to spare the
programmer from having to learn all this stuff.
>
> I have failed with what? I think you have failed to understand
> what an assembler is.
That too.
But what you've really failed at is understand what people want
to learn when they say they want to learn assembly language.
Like Rene, you've come up with some, shall we say, "non-mainstream"
pedagogical method that you feel other people should employ when
learning assembly language. Your scheme is great for learning machine
organization (which is related to learning assembly language programming).
It is not an appropriate scheme for teaching programming in assembly,
however. No doubt, some people would benefit from your approach
(it's not the empty set, you claim to be a member of the set of people
who would learn assembly better using this approach), but most people
will not become proficient assembly programmers using that approach.
BTW, it's obvious you *haven't* read AoA, as it *does* teach a lot
of machine organization prior to getting into the heavy assembly language
coding. This includes teaching them how to encode various machine
instructions in binary, memory organization, I/O organization, and
stuff like that. Take a look at volume two of the on-line edition sometime.
About the only thing it doesn't teach them that you're talking about is
how to write their own assembler (which requires far more prerequisites
than most people have when they get around to learning assembly language).
And one need only take a look at RosAsm to see the kind of
"assembler" someone will write if they don't have the proper
prerequisites for the task prior to writing it. And then they go through
life thinking that their definition of assembly language is the only one
that matters -- based more on their lack of knowledge of how an
assembler should be written more than anything else. I suspect your
x86/68K assembler has placed the same blinders on you -- you're
defining assembly language based on the code *you* were able to
write rather than on anything else.
>
> If you can't determine where the variables are stored in the binary
> output of a RosAsm program (by reading only the source code) then
> RosAsm also isn't an assembler, but this doesn't make HLA an assembler.
My previous statement hit the nail right on the head.
Much like Rene, you define the term "assembly language" based on your
limited experience with the assembler that *you* have written. If some
other product offers more features than yours, it is simply "not an
assembler."
If it does things differently than yours, it is "not an assembler."
Do you honestly expect such a self-serving claim to have much
respectibility?
You're free to define assembly language any way you want, but if you
expect other people to go along with your definition, you're going to have
to be a little more reasonable that this.
>
> If this is brilliant, why you don't you use C++, C# or java? I never
> said, that it isn't easier to write programs with HLA than an
> assembler. All I said is, that HLA isn't an assembler an therefore
> isn't suited to teach students assembly programming (to help them
> to understand the working of the CPU). But if you don't want to
> do assembly programming, I don't see any advantage of using HLA.
> Use a HLL compiler and if necessary inline assembler or link to
> code written in a real assembler.
Exactly how does the use of the term "byte" vs. "db" make one product
an assembler or not an assembler?
Again, we're back to the good old story of "if it's not done exactly the
way *I* did it with *my* assembler, then it's not an assembler."
Just like Rene, all that you achieve with your definition is to exclude
every other product on the planet from being called an "assembler."
That's not a very credible definition. The bottom line is that no matter
what *you* think (or Rene thinks), the world pretty much accepts
MASM as an assembler and it violates a large number of the things
you're claiming an assembler must do, mustn't do, must have, or
must not have. And just like Rene's arguments, no one's buying
your definition. Must make you feel awfully lonely.
>
> If in some points MASM is even worse than HLA, makes this HLA an
> assembler?
If in some points HLA is better than MASM does this make HLA not
an assembler? If you accept the fact that MASM is an assembler, then
you have to accept the same thing about HLA. If you refuse to accept
that definition for MASM, then you're just out of step with the rest of
the world and you can go join Rene in his tiny little "MASM is not an
assembler"
corner of the world.
>
> You have done it, Rene has done it, I have done it and surely also
> Randy and many many others have done it. And as you said, it's trivial.
> I never said something else. All I said was, that everybody who
> learns assembly programming should learn to understand ANY byte in
> the generated binary file. Because the DOS com file format is much easier,
> I also suggest, that this file format should be used for learning
> assembly programming.
This isn't learning assembly language. It's compiler construction.
Some machine organization. Some Operating Systems theory.
It's not assembly language programming.
You're a bit confused concerning the taxonomy of subjects in
computer science, I'm afraid.
Certainly it doesn't *hurt* to know these subjects prior to learning
assembly langauge programming. It's hardly necessary, though.
>
> I never care about persons. If somebody says something, which I
> think is wrong, then a say this and it doesn't matter if it is
> a carpenter, a professor or somebody who got the nobel price.
Of course, it never occurs to you that what you *think* might be
wrong, right? I'd think that the fact that you're scheme doesn't
appear to be in use in *any* major college or university for teaching
assembly language programming would be a clue that it's not an
effective way to teach assembly. I *have* seen your scheme in
use in classes teaching machine organization or computer architecture
(even to the point of writing a trivial assembler), but never in an
assembly programming class. Not to say that it's never been tried;
but the fact is, it that scheme worked you'd see it used in a lot
of classes.
So what you're really saying here is that you don't care that others
have a proven scheme that works. You'll stick with your unproven
idea (or, at least, only "proven" on you) and it doesn't matter what
the rest of the world thinks or does.
However, if you really think that people ought to use your
pedagogy for teaching assembly, I suggest that you demonstrate
that it works - go teach a class using your methods. Prove they
work. Prove they are effective. Demonstrate that students leaving
the course can actually write small assembly language programs
(rather than swearing off assembly for the rest of their lives, as
I suspect your approach would cause them to do).
>
> If you invent a motorbike call it motorbike and not bicycle.
> Nobody has said HLA is bad (ok, I think a HLL is better),
> but HLA isn't an assembler and it shouldn't be called an
> assembler and it is a very bad thing (for the students) if
> it is used to teach assembly programming.
Here's the same challenge to you that I give to Rene when
he spouts this nonsense - feel free to write an assembly
program with *your* assembler and MASM (a real-world
assembler) that cannot be written in HLA. Then'll you'll
have earned the right to call HLA "not an assembler".
Until then, like Rene, you're trying to boost your own
capital at the expense of other products. Very lame.
Cheers,
Randy Hyde
Randall Hyde
"wolfgang kern" <now...@nevernet.at> wrote in message
news:bubev3$aiv$4...@newsreader1.utanet.at...
>
> I think the main differences in the definition of the term
> "assembler" are found in the programmers targets.
> And there there are many within this NG.
A target defines whether or not something is an assembler?
Hmmm....
> My point of view is hardware-oriented and my targets are short,
> fast, smart and transparent code to achieve best performance
> out from a given piece of hardware.
So please feel free to demonstrate how HLA cannot be used for this.
>
> I write mainly KESYS(os),
> HW-drivers(modules),
> function-blocks(kernel lib)
> and not so often: applications (token/parameter-scripts).
>
> So I first learned everthing about the CPUs and all its
> capabilities and weak points by reading Intel/AMD/else docs.
> Here I became familiar with the 'orignal' syntax
> (I find HLA,GCC and similar are almost unreadable).
IOW, HLA is not an assembler because you don't know
anything about it.
> For them it's vital to get in business asap and will find Randy's
> HLA convenient to start with.
> Fine so far, but HLA-students never will make it to the roots,
> they will remain 'user-level' programmers (from my point of view).
>
And why is that?
As HLA supports all the same machine level instructions as these
other assemblers you mention, how does HLA prevent those
programmers from doing any low-level stuff?
And while you're at it, please explain how you move beyond
"user-level" stuff in RosAsm?
Cheers,
Randy Hyde
Randall Hyde
> Perhaps I know why you like HLA,
> it satisfy your "maniac typing needs"? :) :) :)
>
> For me there are too many key-strokes required by far.
>
So the truth is, HLA is not an assembler because it's not as terse as other
assemblers?
Hmm....
Note that this is in direct contrast to a previous post of your's where you
said that HLA, like GCC, is unreadable. It's clear why you find HLA
unreadable -- you don't know the language. OTOH, the principles behind
HLA's design are based on 30 year's of programming language design
and one of the things people discovered way back in the 1970's is that
making a source language as terse as possible hurts the readability of
the language. Yes, you can go too far in the other direction too (e.g.,
COBOL), but HLA's design was based on a lot of good research in
the area of readability (e.g., in the design of languages like Ada,
Modula-2, and so on).
You may have *really* learned your own assembler to the point you
feel it's readable. But the definition of readable isn't "we can train
someone to read this code really well." It's "if you take an average
programming with an average amount of training, will they find the
typical program in this source format easy to read?" A sample
of one doesn't cut it when you try to make claims about how
readable a programming language is or is not. It takes a lot of
careful research to determine what works and what doesn't.
Cheers,
Randy Hyde
Betov
@unibwm.de:
> Nobody has said HLA is bad
:)) Oh! _Yes_, i am afraid i did :))
Betov.
Betov
news:zYeOb.14565$zj7....@newsread1.news.pas.earthlink.net:
> Much like Rene, you define the term "assembly language" based on your
> limited experience with the assembler that *you* have written. If some
> other product offers more features than yours, it is simply "not an
> assembler."
Long before writting RosAsm, i had two Folders on my Disk:
One for [assemblers] and one for [HLLs]. I have around 25
Assemblers in the [Assemblers] one.
Guess in which one HLA is ??? ;)
> ... And just like Rene's arguments, no one's
> buying your definition. Must make you feel awfully lonely.
I afraid i am feeling less and less lonely, these days,
master Pdf. If my rude way of saying true things might
have help others to open their mouths, i will not have
lost my time.
> If in some points HLA is better than MASM does this make HLA not
> an assembler?
Want spectacles? He said that one some points, MASM is
_worst_ than HLA, not that one some points HLA was
_better_ than MASM. "Better", first implies "good".
> However, if you really think that people ought to use your
> pedagogy for teaching assembly, I suggest that you demonstrate
> that it works - go teach a class using your methods. Prove they
> work. Prove they are effective. Demonstrate that students leaving
> the course can actually write small assembly language programs
> (rather than swearing off assembly for the rest of their lives, as
> I suspect your approach would cause them to do).
:)) :)) :)) Where are _your_ proves Master Pdf?
When was it, the last time you saw a studient?
How many of the unfortuned studients you got in
the past are now writing one line of Asm? How
many of them were interrested with something else
than having some "grade"?
> ... feel free to write an assembly
> program with *your* assembler and MASM (a real-world
> assembler) that cannot be written in HLA.
Feel free to write an HLA real life program that
cannot be written with a Basic. And when you will
have succeed, you wil not have done any demonstration
that your HLL-VHLL written HLL Pre-Parser is an
Assembler.
Unfortunately for you, there are yet some guys who
know what Assemblers are and what Assembly Language
is. And, as long as you will have to face such guys,
you will have some serious problems at proving them
that an HLL Pre-Parser is an Assembler.
Betov.
< http://betov.free.fr/RosAsm.html >
Annie
On 2004-01-17 be...@free.fr said:
> Unfortunately for you, there are yet some guys who
> know what Assemblers are and what Assembly Language
> is. And, as long as you will have to face such guys,
> you will have some serious problems at proving them
> that an HLL Pre-Parser is an Assembler.
_____
This is getting REALLY silly. ((( `\
The facts are quite clear: _ _`\ )
(^ ) )
HLA translates a text file of ~-( )
semi-proprietary mnemonics, _'((,,,)))
into ANOTHER text file. This ,-' \_/ `\
second text file, which HLA ( , |
generates, contains mnemonics `-.-'`-.-'/|_|
which MA$M can then assemble to \ / | |
binary. =()=: / ,' aa
So while HLA might "assemble" one
text file into another text file, it cannot "assemble"
a text file to binary machine code. HLA requires MA$M
(or some other external program) to do that.
HLA, therefore, is not an "assembler" in the classic
and commonly-accepted sense of the term.
Instead, HLA is a "mnemonics translator." It's a third-
party add-on utility; a "front end" for use with MA$M.
SpAsm/RosAsm, on the other hand, DOES have the native
ability to "assemble" a text file of ASM-like mnemonics
into binary machine code.
SpAsm/RosAsm, therefore, -IS- an "assembler" in the
classic and commonly-accepted sense of the term.
It's all SOOOOO simple, guys.
Now stop wasting bandwidth with all this ridiculous
ax-grinding, and get back to work on improving your
respective products...you slackers. Hehehe!
Love,
Annie
Herbert Kleebauer
> > 1:1 means, you can convert any line in the source code to
> > the corresponding output byte sequence (after resolving the
> > symbolic address) independent of any other line in the source
> > code. But, as stated above, you have to tell the assembler
> > for which processor mode (16/32 bit) the output should be
> > generated.
>
> Herbert, maybe I misunderstand what you're trying to say here,
> but it's pretty obvious the 16/32 bit mode directive breaks the
> 1:1 translation. In particular, a directive like USE16 affects
> a large number of the instructions and their corresponding
> object code emission. Therefore, the use of those instructions
> is not independent of any other line in the source file. In
> particular, they are *quite* dependent on directives like
> USE16 and USE32.
That's the reason why I wrote:
But, as stated above, you have to tell the assembler
for which processor mode (16/32 bit) the output should be
generated.
This "instruction" is more like a command line switch moved
into the source file.
> Even ignoring such issues, your statement still isn't very
> correct. After all, the byte sequence emitted for "mov eax, i"
> is *completely* dependent upon the definition of "i". If it's
> a symbolic constant, then you get one opcode (and the value
> of the emitted code depends entirely on the value you associate
> with constant "i", making that emitted code dependent upon
> i's definition). If it's a memory reference, the opcode emission
> depends upon the definition of "i" (i.e., where it appears with
> respect to other variable definitions in the file). Again, that's
> hardly independent of any other statement in the file.
If you mean, that in the string "mov eax, i" i can either
be an immediate operand or the address of an operand, then
this is code for some sort of a "High Level Assembler". In
a "real" assembler this information is explicit given:
move.l #i,r0
move.l i,r0
If you mean the actual value for the immediate operand i
or the address i depends on other code, then you are
right. That is the reason why I wrote:
(after resolving the symbolic address)
One purpose of an assembler is, to do the address calculating
for you.
> My previous statement hit the nail right on the head.
> Much like Rene, you define the term "assembly language" based on your
> limited experience with the assembler that *you* have written. If some
> other product offers more features than yours, it is simply "not an
> assembler."
I don't understand what's your goal. Do you think, it is
something negative if HLA is not categorized as an assembler?
I again have to use the comparison with a bicycle: If you
design a motorbike, why would you insist on calling it a bicycle?
A motorbike has many advantages over a bicycle. But if the
goal is to explore any inch of your way, then the slow bicycle
is much better than your motorbike. The greatest problem for the
motorbike is, that today we have much better vehicles like
high speed cars. And most of this cars have a bicycle in its
trunk.
> However, if you really think that people ought to use your
> pedagogy for teaching assembly, I suggest that you demonstrate
> that it works - go teach a class using your methods. Prove they
> work. Prove they are effective. Demonstrate that students leaving
> the course can actually write small assembly language programs
> (rather than swearing off assembly for the rest of their lives, as
> I suspect your approach would cause them to do).
I do this since more than 10 years. I don't use an Intel x86
processor but a simple 16 bit processor. All the students get
is a specification of the processor. The first thing they
have to do, is to design the processor using only and/or gates
and Flip Flops and then implement the processor on a FPGA.
After they have built the processor from scratch there never
was any student who had a problem writing the test programs
using a simple assembler written in QBasic. And there never
was a student who didn't enjoy this course (they don't need
to make this course).
> > If you invent a motorbike call it motorbike and not bicycle.
> > Nobody has said HLA is bad (ok, I think a HLL is better),
> > but HLA isn't an assembler and it shouldn't be called an
> > assembler and it is a very bad thing (for the students) if
> > it is used to teach assembly programming.
>
> Here's the same challenge to you that I give to Rene when
> he spouts this nonsense - feel free to write an assembly
> program with *your* assembler and MASM (a real-world
> assembler) that cannot be written in HLA. Then'll you'll
> have earned the right to call HLA "not an assembler".
> Until then, like Rene, you're trying to boost your own
> capital at the expense of other products. Very lame.
What a logic! If I don't find a route which can only be
used by a bicycle and not by a motorbike, then the motorbike
is a bicycle.
The Half A Wannabee
"Annie" <an...@oal.com> wrote in message
news:bucao5$1cfc$1...@news.f.de.plusline.net...
>
> On 2004-01-17 be...@free.fr said:
> Now stop wasting bandwidth with all this ridiculous
> ax-grinding, and get back to work on improving your
> respective products...you slackers. Hehehe!
>
> Love,
> Annie
Hmm...not that it matters...but I must tell you that lately you make more
sense by
each second passing. Im sorry that I seem to have been wrong about you.
Yeah, why the hell not, I am drunk and happy.
Love,
the Wannabee.
Annie
On 2004-01-18 The Wannabee said:
> Hmm...not that it matters...but I must tell you that lately
> you make more sense by each second passing. Im sorry that I
> seem to have been wrong about you.
_____
I -always- make sense, Wannabee. ((( `\
And I don't write book-length _ _`\ )
messages, either. Hehe! (^ ) )
~-( )
Hope you're feeling better this _'((,,,)))
morning, after last night's bout ,-' \_/ `\
with the bottle. Better take two ( , |
aspirin with your lutfisk and `-.-'`-.-'/|_|
lefse. Hehehe! \ / | |
=()=: / ,' aa
Randall Hyde
> Randall Hyde wrote:
>
>
> That's the reason why I wrote:
> But, as stated above, you have to tell the assembler
> for which processor mode (16/32 bit) the output should be
> generated.
>
> This "instruction" is more like a command line switch moved
> into the source file.
Okay, your logic is falling apart. That's okay.
>
> If you mean, that in the string "mov eax, i" i can either
> be an immediate operand or the address of an operand, then
> this is code for some sort of a "High Level Assembler". In
> a "real" assembler this information is explicit given:
>
> move.l #i,r0
> move.l i,r0
Well, you know what? I took your advice and read
the CPU manufacturer's data sheet (Intel's in this case,
not Motorola's) and it gives *me* the impression that
"mov eax, i" could be a move immediate or a move direct,
depending on how "i" is declared. There is no funny syntax
required to differentiate the two in the mov instruction.
So either we can follow your instructions and learn assembly
by reading the manufacturers documentation, or we can
learn assembly by ignoring that documentation and checking
out Herbert's assembler.
Do I detect some inconsistency here?
As I suspected, just like Rene's argument, an assembler
is only a "true assembler" if it is *your assembler*.
Have fun convincing all those MASM and TASM users
out there that they haven't been using an assembler since
the products first appeared (and this was *long* before the
high-level assembly stuff appeared in these assemblers).
Intel specified this syntax for the x86 way back in 1978.
Even before the Motorola 68000 came along :-)
>
> If you mean the actual value for the immediate operand i
> or the address i depends on other code, then you are
> right. That is the reason why I wrote:
> (after resolving the symbolic address)
>
> One purpose of an assembler is, to do the address calculating
> for you.
But that purpose contradicts your earlier statement.
>
> I don't understand what's your goal. Do you think, it is
> something negative if HLA is not categorized as an assembler?
HLA is an assembler. The fact that your assembler is rather
simplistic and doesn't have the features that a modern assembler
like HLA, MASM, and TASM, supports doesn't change the
fact that these are assemblers.
I do think it's *negative* when you try to convince people
that they are not learning assembly language when they use
one of these products. Particularly as you don't even know
much about these products. That's just sheer ignorance.
All you're trying to do is justify the weakness of your own
product by trying to "eliminate the competition" by moving
them out of the "assembler" category. The same strategy
Rene Tournois as been attempting, unsuccessfully, for
four years.
> I again have to use the comparison with a bicycle: If you
> design a motorbike, why would you insist on calling it a bicycle?
> A motorbike has many advantages over a bicycle. But if the
> goal is to explore any inch of your way, then the slow bicycle
> is much better than your motorbike. The greatest problem for the
> motorbike is, that today we have much better vehicles like
> high speed cars. And most of this cars have a bicycle in its
> trunk.
The analogy doesn't work at all. Give it up.
>
> > However, if you really think that people ought to use your
> > pedagogy for teaching assembly, I suggest that you demonstrate
> > that it works - go teach a class using your methods. Prove they
> > work. Prove they are effective. Demonstrate that students leaving
> > the course can actually write small assembly language programs
> > (rather than swearing off assembly for the rest of their lives, as
> > I suspect your approach would cause them to do).
>
> I do this since more than 10 years. I don't use an Intel x86
> processor but a simple 16 bit processor. All the students get
> is a specification of the processor. The first thing they
> have to do, is to design the processor using only and/or gates
> and Flip Flops and then implement the processor on a FPGA.
> After they have built the processor from scratch there never
> was any student who had a problem writing the test programs
> using a simple assembler written in QBasic. And there never
> was a student who didn't enjoy this course (they don't need
> to make this course).
You're teaching CPU/system design, not assembly language
programming. There's a bit of a difference there. If you don't
understand the difference, you have no business teaching.
The fact that some simple assembly language programming
*may* be required along the way to test out the design
doesn't mean that they've learned assembly language programming.
What kind of applications can those student write in assembly
once the course is over --- oh, that's right, you don't believe
applications can be written in assembly and it's easy to see
why now.
> > Here's the same challenge to you that I give to Rene when
> > he spouts this nonsense - feel free to write an assembly
> > program with *your* assembler and MASM (a real-world
> > assembler) that cannot be written in HLA. Then'll you'll
> > have earned the right to call HLA "not an assembler".
> > Until then, like Rene, you're trying to boost your own
> > capital at the expense of other products. Very lame.
>
> What a logic! If I don't find a route which can only be
> used by a bicycle and not by a motorbike, then the motorbike
> is a bicycle.
IOW, you refuse the challenge because you cannot come up
with such a program. So change the subject.
If you really want to use that bicycle analogy, prove that it applies.
That is, match every little feature in an "assembler" to a bike and
every feature in HLA to a motorbike and try again. It just doesn't
stand up. It's a bunch of B.S. constructed to obscure the fact that
you don't really have a good argument for claiming products like
HLA, MASM, and TASM are not assemblers.
Boy, you should hang out on the RosAsm board. You'd find a
lot of kindred souls there.
Cheers,
Randy Hyde
Randall Hyde
> This is getting REALLY silly. ((( `\
> The facts are quite clear: _ _`\ )
> (^ ) )
> HLA translates a text file of ~-( )
> semi-proprietary mnemonics, _'((,,,)))
> into ANOTHER text file. This ,-' \_/ `\
> second text file, which HLA ( , |
> generates, contains mnemonics `-.-'`-.-'/|_|
> which MA$M can then assemble to \ / | |
> binary. =()=: / ,' aa
HLA is a *compiler* for an *assembly langage*.
Of course, had you read the first section of the manual
to *learn* something about HLA, you'd know that.
Now as a lot of assembly hackers cannot differentiate
between a *language* and the *implementation* of a
language (and you seem to be one of these), allow me
to briefly describe the difference:
1. A "language" is a *formal* definition. Typically using
a grammar (usually a context-free grammar) and a
certain set of semantic actions to apply or check when
a given production in that language is matched. A
"program" (or more formally, a "sentence in the language")
is a sequences of items that the context-free grammar could
generate from a given starting symbol (or, in the case of a
compiler, that the equivalent push-down automata could
recognize). Put in simplistic terms, the *language* is the
set of all programs (an infinite set, of course) that abide
by the rules of the syntax for that language.
2. An implementation of a language is a particular translator
that does the translation in a specific fashion. There are
assemblers, compilers, interpreters, preprocessors, and
other entities out there. Note that you can have *two*
different implementations of *exactly* the same language.
In the case of the HLA *language*, HLA v1.x is a "compiler"
implementation of the language. HLA v2.0 is an assembler
implementation of the HLA language. The idea is that they
will be different implementation of *roughly* the same language
(technically, if they are not exactly the same, they are not
the same language, and as HLA v2.0 will have some extensions,
the two languages are not the same; but we'll ignore that for
the time being).
Now imagine the poor user of HLA - how confusing.
They write a source file with HLA v1.x and run it through
the translator. Because it is a "compiler" and not an assembler,
some people are trying to claim that this poor HLA user
is not writing "assembly language". OTOH, they take that same
program and run it through the HLA v2.0 translator, which is
an assembler, and voila - they are automatically assembly
language programmers without having changed one line of
code in their program.
This is exactly the contradiction that occurs when you attempt
to define a language by its implementation rather than by a
formal grammar. And that's why all these arguments about
HLA not being a "true assembler" because it is implemented
as a compiler are just so much malarky.
>
> So while HLA might "assemble" one
> text file into another text file, it cannot "assemble"
> a text file to binary machine code. HLA requires MA$M
> (or some other external program) to do that.
HLA v1.x uses an external program file to translate its intermediate
form to binary machine code.
Most assemblers have their native code generator phase built into
the same executable.
A mere implementation detail.
To the HLA user, they type "hla somefile.hla" from the command
line and the end result is an executable file. That's all that matters.
> HLA, therefore, is not an "assembler" in the classic
> and commonly-accepted sense of the term.
No. It is a compiler for an "assembly language".
>
> Instead, HLA is a "mnemonics translator." It's a third-
> party add-on utility; a "front end" for use with MA$M.
Or maybe MASM is a "back end" for use with HLA?
Actually, HLA is a system consisting of several programs:
1. HLA.EXE is a "shell" that guides the translation process.
2. RC.EXE is a program that compiles resources, and gets called by HLA.EXE.
3. HLAPARSE.EXE is a program that translate HLA source files to an
intermediate form.
4. MASM.EXE, FASM.EXE, TASM.EXE, or GAS are programs that
translate the HLA intermediate files into OBJect files (note that we're
still not talking binary machine code here, a basic flaw in your
discussion
of MASM given earlier).
5. LINK.EXE or LD that combines object modules to product a PE or ELF
executable file (which, technically still isn't a pure binary
executable, but
close enough for our purposes).
>
> SpAsm/RosAsm, on the other hand, DOES have the native
> ability to "assemble" a text file of ASM-like mnemonics
> into binary machine code.
No, it does not. It has the ability to create PE file which is a fancy
data structure containing some binary machine code along with a lot
of other stuff to guide the loader that performs relocation, dynamic
linking, and other things. IOW, PE is just another form of an
intermediate file that needs further processing. Binary machine code,
the stuff that you can actually execute generally exists only in memory
under most OSes.
Even .COM files are not exactly pure binary executable images.
So why is one intermediate format more priviledged than the rest?
>
> SpAsm/RosAsm, therefore, -IS- an "assembler" in the
> classic and commonly-accepted sense of the term.
Yep. Every classical assembler I've seen as a built-in disassembler,
an editor, an ASCII chart, and various code generating wizards.
You have a bizarre idea of what a classical assembler is.
>
> It's all SOOOOO simple, guys.
>
> Now stop wasting bandwidth with all this ridiculous
> ax-grinding, and get back to work on improving your
> respective products...you slackers. Hehehe!
Your post is a great example of this wasted bandwidth.
Just a troll to elicit a response.
cheers,
Randy Hyde
Beth
> Beth wrote:
> > [...]
>
> Here we go again with tons of bullshit about HLA
> being an Assembler. Well,... just one thing:
>
> > So, are my two word-sized data declarations aligned to the byte,
word,
> > dword, paragraph or page? Don't know...because they are less than
> > 32-bits, does RosAsm "pad" these out to dword-sizes for
"alignment"
> > reasons? Don't know...
>
> RosAsm syntax is perfectely clear about this:
>
> For Data Declarations, "[" actually means:
>
> 1) Start a new set of Data.
> 2) Aling32.
>
> If "Align32" _not_ wanted, the syntax is: "[<".
>
> Notice that, in some future (when i will have
> time to review this...), the convention will be
> slightly modified to the more accurate:
>
> 1) Start a new set of Data.
> 2) Align on the boudary required by the next
> coming Size Marker. Example:
>
> "[MyqWord: Q$ 0FFFF564]"
>
> >>> Align64 assumed. Instead of the actually hand made:
>
> "[<64 MyqWord: Q$ 0FFFF564]"
Ah, now, see, _THAT_ is a useful answer...you should make more useful
posts like this...with more of this thing _clarified_ ("clearly
defined" ;) then it's more tempting to at least give RosAsm more of a
"look-see" and "play around" to find its good points...
Anyway, the answer isn't totally complete yet, though...my example was
specifically about having these two 16-bit pieces of data straddle
between "titles"...is it _guaranteed_ - not subject to change or
revision - that the order of the tabs for each "title" is the actual
order of processing the source code?
That is, if one "title" ends in "[<16 VarA: W$ 034 ]" and the next
"title" ("next" according to the tab order in the editor :) has "[<16
VarB: W$ 012 ]" then would a "mov eax D$ VarA" instruction (Hope I've
got your syntax correct here...I'm trying but confess I'm not totally
comfortable using it :) be always _guaranteed_ to produce "1234h" in
EAX?
Or, more generally, as that example is slightly "contrived", what are
the rules about the _order_ of "titles" with respect to the source
code and what are the "scope" (if any) and "forward declaration"
rules? My point being, basically, "titles" are all shown _equally_, so
to speak, in the editor...but as it's merely a "visual" thing and the
source code is actually one monolithic file (just _shown_ by the
editor as separate "modules"...or "titles" in RosAsm terms :)...
For example, QuickBASIC also uses a very similar strategy in that the
editor _shows_ each "SUB" and "FUNCTION" in its own separate editor
window...but, in fact, this is merely a "visual aid" and the file is
still one long monolithic file (as can be proved to one's self by
simply loading up the file in another text editor to see that the
"SUBs" are merely listed one after another and it's simply a "visual
aid" from the editor that it reads "SUB" and then splits them all off
into their own editor windows so that you can do things in a more
"modular" way without actually needing more than one file :)...
But, well, ignoring the point that QuickBASIC does _also_ support
multiple file projects too (has a very simple "makefile" that just
lists out all the filenames so that when you load one, all the others
are loaded together with it :)...QB _does_ use "scope" and "modular"
elements to do this...that is, variables outside a "SUB" are NOT
visible _unless_ you include a statement to make them so...hence, the
"rules" about how the different parts relate to each other is made
clear by the documentation...
With RosAsm, though, I'm wondering what the "rules" may be
there...that is, "titles" don't have "scope" applied at all, right?
It's merely an "aid" to editing things but doesn't alter the usual
"it's all just one big monolithic file" thing at all, right?
Therefore, there needs to be a little bit - just a sentence or two -
that explains how these relate to each other...
For example, one "title" - called "One" for example - defines some
data...can another title - called "Two", for example - simply "reach
in" to title "one" and use that data? Also, as I was saying about the
"order" of these "titles" _in the actual file_, does the fact that
"one" comes before "two" in the tab controls along the top of the
editor _literally mean_ that "one" comes before "two" _in the actual
source file_? I'm thinking about things like "forward references" (or
does your assembler make multiple passes or use some other means to
avoid any problems with "forward reference"?) and about possible
requirements for ordering data (as an example, when I was talking
about "type-time" assembly to another post around here, I mentioned a
"hack" in which you could save memory by only using a _single_ address
pointer in some tables, which _could_ either be another table or an
actual _piece of code_...rather than create an extra field in the
table to define what "type" of pointer this is - is it a pointer to
another table so that we've got another "tree" of tables hanging off
this table...or is the pointer actually a "leaf node" in the tree and
there are no more tables and the address now points to an _actual
procedure_ to call - what could be done is to put all the tables
together in memory...and then we can tell if the address pointer in
the table points to another table by simply checking if it's within
the range of tables...that is, if "p" is our pointer then if "address
of start of first table <= p <= address of end of last table" then we
_know_ simply from the location of the pointer whether it's pointing
to another table (where, obviously, if it isn't then it's got to be an
address of _actual code_ to call instead)...hence, we only need one
field - the address pointer - and don't need to make all these tables
far larger and require an extra memory access to this "type" field to
find out whether the pointer points to another table or to an actual
procedure...this is a very simple "optimisation" that can greatly
improve size (saves one third of the size of the larger tables with
two fields, in fact ;) and even improves speed (because we can
determine everything from _one_ memory access rather than needing two
:)...
BUT for such a "trick" to work, we need to be _sure_ of the order of
our data...rather than an address which points to a subroutine at the
"leaf nodes", it could also - in some other application - also point
to more - but different - data elsewhere in the program...thus, the
_order_ and _range_ of how our data is actually placed in memory is
_crucial_ for this trick to work...if more than one title supplies or
accesses our tables in this way, we really _need_ to know whether the
tab order in the editor _truly_ reflects the order in the source file
itself (and, thus, by extension, the order that will be in memory once
loaded :)...
NOTE carefully that there's NO criticism of RosAsm itself in this...it
obviously works in one way or the other and _once you know_ what that
"order" actually is, then you can _safely_ go ahead and use "tricks"
like this one (which you'd probably approve of in the sense that it's
a "specific assembly" kind of "trick"...rather than make the tables
"generic" with "type" fields, we actually borrow _facts_ about how our
program is _specifically_ ordered in memory so as to save on memory
and speed...put it this way, Randy couldn't really advise such a thing
as "good programming structure" in AoA to beginners, anyway, as it's -
I admit - heading towards "dirty hack" and "unsafe" territory...but,
hey, done right, it saves you a bundle in RAM and even speeds things
up a touch ;)...
What the criticism was really about is that you don't really make
enough of these kinds of issues - which _can_ be very important for
"tricks" like the one above - totally _explicit_ in the documentation
and so forth...
Make these "order" (and "scope", even if that's to simply say "there
is NO scope in RosAsm at all" or "it's just local labels only and
nothing else" or whatever :) issues _clear_ and the "problem" here
vanishes...it's a "there's some things I'd really, really like to know
about RosAsm that's _missing_ from its documentation" criticism...put
some small entries about these technical matters - if you can make
room between all the "philosophy" in there - for such issues and the
"complaint" totally and immediately vanishes...you know, it's just the
thing about "if you're not told how it works then you can't _know_ how
it works" problem that applies to anything...
As you know seem intent to "sell" RosAsm (even if by "terrible
illusion", which has got me very annoyed, actually ;), _pay particular
attention_ to what Randy uses more than anything else to "sell" his
HLA: _the PDF files_...now, of course, you use your own help system
rather than the PDF format...that's not important...but what _is_
important and really helps to "sell" HLA is that Randy puts it all in
there...all the little details about how HLA does this and does
that...because, with this, you're "selling" _knowledge_ and _safety_
and _comfort_...that is, I've run into things I wasn't sure about with
HLA but I could feel confident that most of these _ARE_ 100% covered
in one of Randy's PDF files somewhere...that if I just looked around,
there'd be a paragraph saying "it works like this" and then I could
carry on...
When the documentation is more "minimalist" than that, this actually
means you need to pay _MORE_ attention - not less - to being
absolutely sure that you've covered all the technical issues that a
user could be confused about (yes, _even when they are
"unlikely"_...because even "unlikely" things _DO_ happen from time to
time and, when they happen, we _still_ want to be sure that the
documentation at least gives us _some_ sort of a clue how things works
and what to do to get RosAsm to work in the way we want :)...
Indeed, Randy uses _books_ an awful lot to "sell" his HLA...so, _pay
attention_ that just making your documentation "fuller" (not
necessarily "massive" in size but just that it _is_ "covering all
bases" that a user could ever want to know about, be that "likely" or
"unlikely" :) will be a _great_ "selling" point...more "features"
won't necessarily help at all...in fact, _more features_ means more
potential confusion and questions that users want to know about...it
could actually make this kind of problem _worse_, not
better...because, basically, what users _really like_ is knowing that
they are "safe"...that they can be "comfortable" with a tool...that
when they have a problem, they can look at the documentation or ask a
question and get a speedy, useful and honest reply to that almost
immediately..._THAT_ is what "sells" a whole lot better than "jump
optimisations" because, in fact, I'd bet that very few HLA users ever
cared or noticed (after all, this issue is an issue with _MASM_ or
_FASM_ or _GAS_ - which HLA uses - and not with HLA itself...not least
until v2.0 appears...so they can hardly be greatly worried about it or
the "ambiguity" about whether HLA does it or not - as it's NOT an HLA
"feature" at the moment but a feature of the assembler _underneath_
HLA, that it's not on HLA's "feature list" at all - would have put
them off...
I know, you don't feel confident as being a "literary genius" to write
tons and tons of documentation...it's boring, there's coding to be
done...BUT that, in the end, is what needs to be done...how Randy's
"ratings" are going up (he writes the books and happily answers the
newbie questions :) while your "ratings" are struggling...that's where
Randy's "professionalism" comes into the picture...it _can_ be really
boring and tedious (mind you, also sometimes fun and
enlightening...it's not automatically "torture" but, yes, you'd rather
coding instead ;)...but that's the thing you've _got to_ do, if you
want the most users to think "yeah, this is great...I can pick up this
book and can write specific assembly programs for ReactOS within
days!"...that's the "feeling" of "comfort" and "security" and "this
guy Rene's a good friend helping me" which is actually doing all the
"selling"...the "feature list" is actually next to _USELESS_ on
beginners for a _fact_...they don't know assembly yet, they can't even
read it...they don't understand the jargon...what's a "jump
optimisation"? They just don't know...Hopefully, they _WILL_ know all
about that _AFTER_ reading your documentation and tutorials and
stuff...but that is NOT what "sells" the assembler really, it's the
_CONFIDENCE_ that the users can put in it...that is, Randy is a
long-time teacher of this topic...that gives people _confidence_ that
he knows what he's talking about...Randy creates big books...that
gives people _CONFIDENCE_ that when they have a problem, the big books
will probably answer their questions...Randy comes on here and answers
newbies...that gives people _CONFIDENCE_ that even when the big books
fail, they still can get some kind of "support" for their problems...
Don't you get it? If you'll pardon the French, fuck "features" for
now...get the _CONFIDENCE_ people can have in RosAsm to 100% or
more...because, in the end, the _ONLY_ real thing people want to know
about a tool before "buying" it is: "Will the tool actually be
_useful_ to me and can I _trust_ it?"...
And, I warn you now, very, very seriously...if you use "terrible
illusions" and add on twenty "features" that users aren't specifically
looking for, then this _WILL_ backfire on you...I'm not just saying
this saddened by you going back on your "principles" but also as a
simple statement of _fact_...if you try to win by "cheating" and
"deceiving" and people _find out_ that you're "cheating and
deceiving", then you will _LOSE_ all your "friends" in the blink of an
eye...the entire house of cards can potentially come crumbling down
all in one go..._DON'T_ overlook my warning here as "some more Beth
bullcrap" because I'd _hate_ to see you ignore this and then find
yourself standing in the _ruins_ of the house you'd tried to build...
In fact, there you have it, Rene...you _could_ build a house and, you
know, not properly build the walls...just put the roof on any old way
and who cares if it lasts more than a year? You _COULD_, indeed,
create a "terrible illusion" that this house is well-built, when, in
fact, it's a total deathtrap that will fall to the ground in a couple
of months or end up electrocuting someone because of bad wiring or the
pipes will all burst and the house is flooded because the plumbing
wasn't done correctly...
DON'T...I repeat, DON'T go and build RosAsm as some "house of cards"
that could blow over with the smallest breeze...so, DON'T try to
"cheat" with "terrible illusions" because I _GUARANTEE_ you 100% that
such illusions are only _TEMPORARY_...if one of these badly built
houses was to fall and kill the people living in it, then _NO-ONE_
would ever consider hiring "the Killer Builder" to build their houses
ever again...
I know you don't credit Randy with this...but the truth of the matter
is that he succeeds because you _CAN_ place a very high degree of
trust in him, his words and the tools he writes...it's actually
_because_, in truth, he doesn't "swindle" at all - even when it's
tempting to...even when, for example, he could have kept quiet about
bugs and problems with HLA and tried to create some "terrible
illusion" that it was working better than it was...even when I've
spotted things and mentioned them in private Email to him so that he
could perfectly well have NOT told anyone of the problems but still
announced it regardless...that's Randy's _real_ selling point - and
even mine to the degree that I'm trusted when I say things - that he
simply _doesn't_ try to "swindle" at all...even when he could easily
do so, even when it's tempting...
Indeed, when you decided to pick on Randy's "trustworthiness" with
"lies, swindles and propoganda", you _WERE_ attacking exactly the
right thing to do damage...although, of course, _you_ are the one
who's really lying, swindling and creating propoganda to do
that...but, nevertheless, that _is_ Randy's main "selling point" that
going after that was perhaps the smartest "anti-HLA" thing you ever
did...creating "terrible illusion" features has the potential to be
the _dumbest_ thing you could ever do...I'm not just warning against
this because I'd be highly disappointed to see _illusions_ (another
word for "lies, swindles and propoganda", after all) used to _deceive_
people...but also I have to say this because it's quite possible that
the same "terrible illusion" will backfire on you in a really serious
way...
Just hearing you say "terrible illusions" made me lose 99% of the
respect I'd built up for your "principled stand"...and I always try to
"give the benefit of the doubt" to people...most people out there
_DON'T_ and would immediately cease to have any and all respect for
you right then and there, refusing to ever listen to the "swindler"
ever again...
"There is nothing so powerful as truth, and often nothing so strange."
[ Daniel Webster (pardon the pun on the surname, Rene ;) ]
"Speaking the Truth in times of universal deceit is a _revolutionary_
act."
[ George Orwell (well, what else could I quote to the "revolutioneer"
Rene? ;) ]
Beth :)
Beth
> Randy wrote:
> > ... And just like Rene's arguments, no one's
> > buying your definition. Must make you feel awfully lonely.
>
> I afraid i am feeling less and less lonely, these days,
> master Pdf. If my rude way of saying true things might
> have help others to open their mouths, i will not have
> lost my time.
Mind you, Randy, he has a minor point here...I've now warned _BOTH_ of
you not to turn this into some "no holds barred"* fist fight...neither
of you will walk away unscathed if that is allowed to happen...
Already, Randy, you must have found some shiver running down your
spine at the "you're not a Christian" comment that was made (even if
you don't agree, then you've got to recognise that outright
unforgiving "revenge" just to make you feel better isn't a
particularly good example of "Christian values", even if, sure, it's
hardly "spawn of satan" material just yet that you should be disbarred
for the odd human failing...but, well, _proceeding_ with a mistake
after you've realised that you really shouldn't be doing it _is_ a
somewhat indefensible thing)...
And, Rene, giving up on principles with "terrible illusions" to try to
_cheat_ your way in completely _temporary_ "ratings" is NOT a good
strategy either...eventually, your _frauds_ will be uncovered and, in
that moment, the disappointment and sense of being cheated will likely
overwhelm someone that you could so easily tell a bare faced lie to
their faces...any politician (and revolutionaries are politicians of a
kind :) can promise this and promise that...and, sure, get the
votes...but they will be _temporary only_ if you can't make good on
them...if the "president" of the RosAsm "party" gets caught with his
trousers down, then it could end up ruining RosAsm chances completely
for a while to come...just ask Bill Clinton...in a sense, with only
300 votes (if that) in it for Bush, his "cigar incident" might be a
very significant factor in exactly _why_ we have Bush and all those
things you hate currently running the show (no, not suggesting
Democrats wouldn't have necessarily ended up any better...I mean,
Clinton carried on bombing places like Iraq (which is another point
about the Iraq "war"...actual conflict there had been on-going for _12
years_ prior to the invasion - under both democrat and republican
hands - Bush simply "made it official"...well, no, not quite because,
interestingly, it was never properly legally declared as is usual with
war...kind of suggests what I was saying about it being "invasion" and
"occupation" rather than what technically counts legally as
"war"...there are actually pretty strict rules as to what does and
doesn't qualify that - suspiciously - were not carried out in this
instance whatsoever) without any hesitation to be seen...I'm not a
great fan of Bill Clinton and my Liberalism does NOT actually extend
to _adultery_ because that breaks a Commandment, last time I
looked...just pointing out to Rene that such things can end up
_GIVING_ your opponent "victory", for all your attempts at trying to
deny them it)...
Either start acting with some "chivalry" in your clashes, boys, or,
indeed, someone might just grab a bottle and break it, putting a big
nasty scar that you can never fully recover from across your
faces...if you kind of catch the drift of what I mean by that...
I repeat my favourite Yoda saying:
"Fear and anger path to Dark Side is, young master Annakin"
In other words, by letting fear or anger or whatever rule your
decisions, you have succumbed to the "Dark Side"...it's not easy but
don't _ever_ bite and don't feed the trolls _under any
circumstances_..."rise above it", so to speak...
So, be good Jedi and wave your lightsabers** around in a proper
chivalrous knightly manner from now on ;)
Beth :)
* On the off-chance that this phrase doesn't translate to French very
well - as it is a "colloquialism" of a sort - then it basically means
a fight where _any_ and _all_ forms of attack are permitted...a
_dishonourable_ fight where the boxer ignoring "Queensbury Rules" and
simply kicks the opponent in his unmentionables...where a broken
bottle is used...blah-blah-blah...
** I really want to write "lightsabres", as per English spelling, but
Lucas is American so, actually, the spelling is "lightsabers" (well,
actually, I've never seen it written down to actually know 100% but I
presume this to be the case, seeing as it has American origin :)...
Beth
> Annie wrote:
> > This is getting REALLY silly. ((( `\
> > The facts are quite clear: _ _`\ )
> > (^ ) )
> > HLA translates a text file of ~-( )
> > semi-proprietary mnemonics, _'((,,,)))
> > into ANOTHER text file. This ,-' \_/ `\
> > second text file, which HLA ( , |
> > generates, contains mnemonics `-.-'`-.-'/|_|
> > which MA$M can then assemble to \ / | |
> > binary. =()=: / ,' aa
>
> HLA is a *compiler* for an *assembly langage*.
> Of course, had you read the first section of the manual
> to *learn* something about HLA, you'd know that.
>
> Now as a lot of assembly hackers cannot differentiate
> between a *language* and the *implementation* of a
> language (and you seem to be one of these), allow me
> to briefly describe the difference:
You know - especially with Annie around - I've got this terrible,
terrible thought in my head just to say "look, Randy, fudge the lot of
them...let them stew in their own ignorances, as that is its own
punishment"...but regardless of the temptation to say that, I must
resist and "play nice" :)
But, fair play, Annie is correct regards the _physical facts_ of the
matter...yup, it does just "pre-process" HLA stuff for MASM or FASM or
something to actually finish off the job (of course, this argument
will _ONLY_ hold weight until v2.0 shows up and it's out of the
"prototype" phase...so I Hope you've been preparing your speeches and
statements ready for that eventuality, as the source code is already
being written...and knowing Randy's usual productivity, it'll be here
before we know it :)...
Beth :)
Beth
> Betov wrote:
> > Do you re-read what you write, from time to
> > time, Beth?
>
> LOL How would she find time for that ?
Actually, with only few exceptions because I was feeling lazy or
whatever, _every single time_...just before posting, I quickly read
back over it once more and then I re-read what I said - to remind
myself of what was going on - just before answering replies to it...
Beth :)
Gerhard W. Gruber
<XnF9473D37C2F...@213.228.0.75>
>Long before writting RosAsm, i had two Folders on my Disk:
>One for [assemblers] and one for [HLLs]. I have around 25
>Assemblers in the [Assemblers] one.
>
>Guess in which one HLA is ??? ;)
Considering your feelings towards HLA I would assume its in the Trashbin. :)
--
Gerhard Gruber
Maintainer of
SoftICE for Linux - http://sourceforge.net/projects/pice
Fast application launcher - http://sourceforge.net/projects/launchmenu
Beth
> Beth wrote:
> > But, in that regard, AoA is clearly signposted as "previous HLL
> > experience recommended"...it's targetted at the HLL coder who
wishes
> > to _move down_ to assembly...that's also why Rene's accusation of
> > "polluting" these people with "HLLisms" is an absurd
nonsense...AoA's
> > target audience _ARE_ HLL coders and the way it progresses
gradually
> > introduces them to lower-level ASM coding as they go...
[ No, no, my dear Rene, do _YOU_ re-read what you write before posting
is the better question... ]
> In other words:
>
> People already knowing much about programming
> could eventually learn something with AoA.
People already knowing _HLL_ programming could eventually learn
something about _ASM_ programming with AoA..._then_ you are, indeed,
starting to get the point, perhaps?
> For the pure beginners, there'd better read...
> B_U_Asm and save themselves from a much slower
> access to Assembly...
Well, there's other possible recommendations (like Jeff Duntemann's
texts) than only B_U_Asm...
But, _YES_, amazingly, you seem to be beginning to _REALISE_ what's
actually going on...totally...100%...if someone doesn't know HLL
programming then AoA _is_ actually starting in just as "alien" a place
as anywhere to them...and could even be considered a "bad"
recommendation in asking them to learn HLLs only in order for them to
"unlearn" it all again to learn ASM...
It _WASN'T_ designed to work that way...and no-one's ever claimed that
it was...
And, _YES_, there's an equal argument that they could look to texts
focussing on "bottom up" teaching methods, perhaps...I'm not sure if
I'd be quick to recommend your B_U_Asm stuff...but, certainly, it's a
possibility...
You know, _no-one_ ever said different...that's another one of those
"phantoms" you invent and fight with that has nothing to do with
what's actually going on...
> Do you re-read what you write, from time to
> time, Beth?
As I said in the other post, except for few exceptions, usually every
single time (although, I often don't need to and the re-read tends to
simply be a quick "spelling" check :)...
This is quite funny, really...you seem to be claiming "victory" on a
point that _no-one_ ever disputed in any way, shape or form in the
first place...AoA carries a very clear "previous HLL experience
recommended" signpost on it...oh well, whatever keeps you happy, I
suppose...
Mind you, proves one thing...you've never actually bothered to read
much of it, have you? The "HLL -> ASM" approach is absolutely NO
"secret" whatsoever...AoA is clearly signposted as being "previous HLL
experience recommended"...Randy has repeatedly made the point that AoA
works like a "nictoine patch" programme, slowly and gradually taking
someone off HLLs and introducing them to ASM, just like a nicotine
patch takes someone off smoking and introduces them to the non-smoking
world...
How can, after all this time, you _STILL_ don't even understand this
most basic of points? A point laboured over by Randy and myself
numerous times trying to explain it to you and you _still_ just don't
get it (I'm just waiting for more "you will pollute HLL coders with
HLLs!" nonsense to come in reply, still showing you have no idea what
is even going on here to even make valid comments)...
HLA is working in the _total opposite direction_ to how you think it
is and you've never even realised...*sheesh*...okay, once more, for
good measure: AoA starts with a HLL-like perspective to be "familiar"
to HLL coders...then, as they progress through the text, AoA shows
them bit-by-bit, little-by-little how to "translate" an "IF" statement
into a "CMP; Jxx" machine instruction sequence...it brings them "top
down" from HLLs towards assembly language coding...ultimately, if they
carry on right to the end and do "further reading" on the advanced
topics (like the "how to take complete control of HLA" article which
explains how to _completely_ wipe out all "HLLisms" 100% that HLA
becomes totally a "what you write (in machine instructions) is only
what you get" tool :) then, eventually, they are now _ASM
programmers_...and Randy has always said that though he'd like HLA to
be good enough - capable of "advanced" assembly language that they
could stick with it to write _true ASM_ progams (which is the context
in which I'm using HLA...I reckon Randy has, indeed, succeeded in
making HLA more than good enough to not just be a teaching tool but a
damn good assembly language in itself...good enough that I find it
generally _BETTER_ than the alternatives) - that these "new" ASM
coders could stick with HLA, his _primary intention_ has always been
the promotion and teaching of _assembly language_...
He repeatedly offered you an open invitation to "poach" the new _ASM
coders_ he'd brought from the HLL world to the _ASM world_ for your
assembler...or they can go to FASM or NASM or whatever...
And, after all this time, you _STILL_ have no idea about any of this?
Geez Louise, there's some major "translation" problem with converting
this into French thoughts, isn't there?
Ah-ha! I've got it...let's use the "universal language" of ASCII Venn
diagrams...why didn't I think of that before?
"Before" AoA:
+--------------------+
|+------------------+|
|| ||
|| HLLs ||
|| ||
|+------------------+|
| +---+ |
| |ASM| |
| +---+ |
+--------------------+
The biggest box is the world of people using computers in
general...the really big box is all those millions of HLL
programmers...the really, really _small_ box is the few assembly
language programmers there are at the moment...
AoA text in action:
+--------------------+
|+------------------+|
|| ||
|| HLLs ||
|+------------------+|
| | |
| \|/ |
| +------------+ |
| | ASM | |
| +------------+ |
+--------------------+
Now, in reading AoA, the people in the big HLL box start to learn
about assembly language programming and assembly language ideas and
about the machine and so forth...it introduces these ideas, _starting
with a HLL perspective_ (because the people in the HLL box are HLL
coders and only see things in "HLLisms", so we include some of these
into HLA so that they can immediately feel "comfortable" and
"familiar" using HLA and aren't scared off by those usual _myths_
about "assembly language is too complicated!" and stuff because HLA at
its most "HLL" level is only slightly lower than, say, C programming
:)...but, as they read AoA, they learn more about how the "IF"
statements _work_ "under the hood" and how to use _machine
instructions_ to do "IF" in a "pure ASM" way...
As we can see, the big HLL box is now - thanks to AoA's approach of
meeting HLL coders "at their own level" and then gradually introducing
them to ASM programming in a nice, simple and comfortable way - is
_FEEDING INTO_ the ASM box...and the ASM box is getting bigger because
of this...in other words, there are more programmers who know about
_ASM_, as they've been "tempted off" using HLLs by AoA...
"After" AoA:
+--------------------+
|+------------------+|
|| ||
|| HLLs ||
|| ||
|+------------------+|
|+------------------+|
|| ||
|| ASM ||
|+------------------+|
+--------------------+
Look, now the ASM box is much bigger! It's looking pretty respectable
in size to the HLL box! People have learnt about ASM programming!
Isn't this great?
Note, the people who now in this "ASM" box are the people you can talk
about "specific assembly" to...you can say "hey, you new ASM
programmers...now that you know something about ASM programming, you
can come see my great RosAsm tool! It's a great assembler!"...
Also, now that these people actually know about _ASM programming_
(remember, they were HLL coders before and knew _nothing_ about
ASM...nor, to be honest, were they particularly interest to learn
about the language all the "myths" tell them is "too complicated"),
this is also the perfect opportunity for Herbert to post up some "how
to write your own PE files" tutorial! See, if you posted up something
about "using DB for PEs" to a VisualBASIC newsgroup then they wouldn't
even know what on Earth "DB" or "PE" is nor why they might want to do
that, anyway...but, thanks to AoA introducing them _from HLLs_ TO _ASM
programming_, then Herbert can educate them further in these "advanced
ASM topics"...
Or perhaps, indeed, these new ASM programmers want to get even more
"low-level" - now that AoA has _shown them it's fun and easy to do_
(regardless of what "it's far too complicated, use C++" _myths_ have
been telling them in their HLL world :) - and want a "no red tape"
assembler like NASM...or they want to "go AT&T" with GAS on Linux...
These are all _GOOD_ things...and it's thanks to AoA _introducing_
these HLL coders to ASM programming in the kind of style that HLL
coders like...and that's kind of a "proven" thing that HLL coders _DO_
like AoA's style of teaching because it has been _used_ on such people
in universities and other education places and it worked really well
in making people _interested_ to learn more about assembly language
and stick with it after finishing their ASM courses...they could
quickly get part-HLL, part-ASM programs up and running which meant
they could start using _some_ ASM straight away...as they carry on
through AoA, the ASM content goes up and the HLL content goes
down...do you see how this works yet? It's all very simple and
easy...when they get more and more ASM content and less and less HLL
content, we've managed to turn these HLL coders into new ASM coders
almost without them even realising what's happening...it makes the
learning _much easier_ than forcing people to write PE files with "DB"
from the very first day...in fact, as has been _shown_ to be the case
in _actual practice_, when many HLL coders are just _forced_ to do
things like "optimise SSE instructions with regards to cache concerns
using only DB statements to hand-roll PE files" then, unsurprisingly,
these HLL coders get very scared...all those "myths" are proved true:
"ASM is far too complicated!! Quick!! RUN AWAY!!! It's too
complicated!!"...
So, by starting with a "HLL friendly world", the HLL programmers think
"hey, this is really easy...this is just like programming C like I was
doing before"...then, as they carry on with AoA, it teaches them NOT
to use "IF" but to use machine instructions that do the same
thing...and, as this stuff gets introduced one topic at a time, the
HLL coder thinks: "Hey, writing your own IF statements using real
machine instructions is actually quite easy to do...I think I'll do it
with machine instructions from now on because it's much more versatile
and I can take complete control and make the programs smaller and
faster and better with _real_ assembly language programming!"...
Note, carefully, how AoA is very careful here...it doesn't drop twenty
complicated topics all in one go on the reader...or, oh no, the HLL
coder gets scared and runs away again!! So, instead, we take it a
topic at a time...once they learn how to write "IF" as machine
instructions, then they can see how to write "FOR"...and then they can
see how to write their own procedures _without_ using "HLL
helpers"...and so on and so forth...one topic at a time...nice and
easy...the reader can learn each small little bit in their own time...
Oh, look, our HLL coder has finished reading...so, HLL coder, can you
write proper ASM programs with _only_ machine instructions now? And
the HLL coder says "Yes, yes! I can! It was really easy to
learn...whoever made up this 'myth' about ASM being 'too complicated'
was lying! I found it real easy!"...yes, our HLL coder has _graduated_
slowly to become an _ASM coder_ now...three cheers for Randy and AoA!
Hip, hip, hooray! Now you've got loads more people to tell all about
how they should use RosAsm to be "ethical"!!! Fantastic! :)
[ Mind you, you know what else? When this "new HLL coder" is also
asked about something like "so, how does your C compiler process IF
statements in machine terms?", they also have a very good idea how
that works too...so, they already knew HLL programming and now they've
been taught ASM programming...but, better yet, as they came from HLL
programming to ASM programming bit-by-bit "translating" from one to
the other, it's also taught them something else as well...how HLLs
"translate" into ASM machine instructions...and, guess what, Rene, as
you know next to nothing about C, that makes them _MORE QUALIFIED_
than even you... ]
Has this actually very simple idea sunk in yet? Can't you see that
Randy's working in his own little way on _exactly what you want_?
He "unlearns" HLL from HLL coders, introducing them to _ASM_
programming stage-by-stage...once they've completed AoA, they should
be in a position to learn _any_ of the other assemblers...yes,
including yours...yes, including how to do it "manually" using "DB"
statements as Herbert suggested...yes, wolfgang can post up a tutorial
on "hex coding and Intel instruction encodings" that takes them
_further_ to even PURE MACHINE CODE...Randy creates loads more
prospective "real ASM coders" for you guys to teach all about "real"
low-level coding...if AoA wasn't there to prepare these people for
this, then, well, you could _TRY_ posting your "creating PE files with
DB and pure hex machine code programming" to some Ada or Modula/2 or
VisualBASIC group and see how well it does...it simply won't
work...they won't have a clue what you're talking about...once they've
completed the AoA "nicotine patch" course, though, we've helped them
slowly off of their "HLL cravings" and they can feel confident in
going into the programming world _WITHOUT_ needing HLLs (just like
nicotine patches do for smokers in making them confident of a
smoke-free world without cigarettes :)...
He's working _FOR_ your interests, not against them at all...you
silly, silly people...
Also, Randy's clever not to emphasise this point in case the HLL
coders "read between the lines" but note how Randy compares his AoA
course to a _nicotine patch_...and smoking is such a filthy habit,
right? Are you making the connection yet about the real "respect"
shown to HLL coding? Indeed...you sooo missed the point entirely all
this time, eh? ;)
There's a TV advert they show over here, where there are two men in
some changing rooms after doing some kind of sport...and the one man
spots a bottle of "Head and Shoulders" in the other man's bag...and he
asks: "Head and Shoulders? I didn't know you had dandruff!"...and the
other man smiles and pushes his hand through his perfect dandruff-free
hair and replies: "I don't"...
Do you get the point? It's real easy..._BECAUSE_ the other man uses
"Head and Shoulders" - which is a shampoo that clears up and keeps
dandruff away - he _DOESN'T_ have dandruff...
Well, we could make a similar TV advert...there's two HLL coders and
one HLL coder sees HLA poking out of the other HLL coders' bag and
says: "Hey, I didn't know you programmed HLLs!"...and the other man
picks up HLA and smiles, saying: "I don't...I'm an ASM programmer now,
thanks to AoA and HLA!"...because they've _cleared up_ and _keep away_
HLL coding from getting in the way of real assembly language coding...
What you've done is not appreciate the "negativity argument"...you
don't buy a so-called "Dandruff shampoo" to _give_ yourself
dandruff...you buy it to _get rid_ of your dandruff...you don't buy
"nicotine patches" to _become_ a nicotine addict (unless you're a very
silly person ;)...you buy nicotine patches to help _get off_ your
addiction to nicotine...getting the pattern here yet? Right, now we
can attempt to see if you get this idea yet: You also don't use a
"high-level assembler" (and the accompanying AoA "nicotine patch"
course :) to _learn_ HLLs...you use it to _unlearn_ HLLs and learn ASM
instead...
Perhaps this is, like, one of those ideas that's so simple, it's
actually too simple and people insist on complicating it and confusing
themselves? A so-called "Dandruff shampoo" is NOT to _give_ dandruff
but to take it away...a so-called "nicotine patch" is NOT to _give_
someone a nicotine addiction, but to _take it away_...a so-called
"high-level assembler" (following the prescribed AoA course :) is NOT
to _give_ someone HLL coding, it's to _TAKE IT AWAY_...
Things are, indeed, often named in _reverse_ of what you'd
expect...this is what I call the "negativity" argument...you don't
take the name "dandruff shampoo" _literally_ or you'd get the totally
wrong idea about it being a shampoo to _give_ dandruff, not take it
away...because, sure, it sounds like - from the name - that it's
dandruff-giving shampoo but the name relates not to what it gives you
but to what it takes away...it names the _problem_, not the solution
(after all, if they put up the actual chemical formula that removes
dandruff as the shampoo's name, that would simply confuse people
totally...so, instead, it names the _problem_ rather than the solution
:)...
I repeat to Randy what I've always said..."HLA" as in "High-level
Assembler" is a _bloody awful name_ to give the tool...it gives people
the wrong idea...it's actually a _type_ of assembler (e.g. MASM and
TASM are HLAs, in fact ;) so there's potential confuse between "a" HLA
and _THE_ HLA...it's hardly a catchy title...blah-blah-blah...
See? Like I was saying about your name change from SpAsm probably
being a mistake, though it's easy to overlook _NAMES_ are totally
_CRUCIAL_ when it comes to selling things...one wonders if had Randy
called it something that said "HLL coders can learn assembly
assembler", would people have got this really rather simple message a
whole lot sooner?
"Would a Rose by any other name not smell as sweet?"
[ Shakespeare, from Romeo and Juliet ]
Actually, Mr.Shakespeare, HLA demonstrates with all this nonsense
thrown at it...and, also, on a related note, scientific research into
how people actually really do give _different answers_ when asked
about smells and tastes, where only the _visual appearance_ and
nothing else was changed tends to suggest the actually rather bizarre
answer of: "No, it would smell completely differently because
_psychology_ is a major factor and it appears people are _VERY_ easily
fooled into thinking things by changing the name or making food blue
or showing them a picture of one food as they smell a completely
different food but can't help saying it's the food in the picture
rather than what it really is...and so on and so forth"...
Of course, Mr. Shakespeare is still correct...the Rose _doesn't_
actually physically smell any different when called something
else...but, on a _psychological level_, if you called a rose a "shit
smelling crap thing" instead then, amazingly, people really _DO_ start
thinking it doesn't smell quite as sweet anymore...
There's, as they say, absolutely no accounting for taste, after
all...because it actually often even denies _outright facts_...the
rose is no different but it really is - as seems to be the case here -
_totally impossible_ to convince people psychologically that this is
actually true...you'll go on saying "It looks like Pascal!" until the
grave won't you? ;)...
Oh, for once, I think I'll actually _listen_ to Annie...she got one
thing right...this is getting very silly indeed...and time would,
indeed, be much, much better spent actually doing something
_productive_ rather than argue "black is black" to someone convinced
"black is white"...
So, if you don't mind me, I'll go back to my translation of the
DirectX include files to HLA syntax (in beginning to write my little
DirectX HLA example, I realised that if I took but a small "detour" in
making more complete HLA header files then that could actually prove
the most useful...once I get them up and running, I send them to Randy
and he can then perhaps include them as "standard" with HLA so that
other people can also get to using this stuff without themselves
having to copy out all those constants and "interface GUIDs" and that
kind of thing...Direct3D is now mostly covered and it's time to move
onto DirectDraw because some of the earlier Direct3D interfaces were
actually linked to DirectDraw so I need to work on one to get the
other complete...not that you care, of course...just thinking out loud
about what I must do, just so I don't forget after being "distracted"
by writing these posts ;)...
Beth :)
Annie
On 2004-01-18 BethS...@hotmail.NOSPICEDHAM.com said:
> ...Annie is correct regards the _physical facts_ of the
> matter...yup, it [HLA] does just "pre-process" HLA stuff for
> MASM or FASM or something to actually finish off the job...
_____
Thank you, Bethie. ((( `\
_ _`\ )
Love, (^ ) )
Annie ~-( )
_'((,,,)))
,-' \_/ `\
( , |
`-.-'`-.-'/|_|
Annie
On 2004-01-18 rand...@earthlink.net (Randy Hyde) said:
> HLA is a *compiler* for an *assembly langage*.
>
> ...
>
> HLA v1.x uses an external program file to translate its
> intermediate form to binary machine code.
>
> Most assemblers have their native code generator phase
> built into the same executable.
>
> A mere implementation detail...
_____
A fairly SIGNIFICANT detail, ((( `\
seeing as how the code gene- _ _`\ )
rator (MA$M) was written by (^ ) )
someone else; not by you. ~-( )
_'((,,,)))
But putting that aside, you're ,-' \_/ `\
STILL fudging the definitions ( , |
here, Randy...and you KNOW it. `-.-'`-.-'/|_|
\ / | |
HLA syntax might, indeed, tech- =()=: / ,' aa
nically qualify as -AN- assembly
language -- a semi-proprietary dialect of your own
design -- but it isn't "assembly language" in the
generally-accepted meaning of the common parlance.
Sheesh...I'm getting visions of Billy-Bob Klinton's
pathetic yet hilarious impeachment testimony before
Congress: "It depends on what the definition of 'is' is."
Frankly, you might have greater success with HLA if
you'd quit trying to obfuscate the fact that it's a
"front end" for MA$M, and PROMOTE that fact as a
desirable "feature."
"Already know a high-level language? Then YOU, TOO, can
now write code for MA$M -- using Randy Hyde's amazing
new high level interpolator, HLA (tm)! Yes, now there's
no need to bother with all those pesky and difficult
low-level details of assembly language! Abstract them away,
with HLA!"
It might extend your potential client base beyond the
realm of the slothful, unmotivated university undergrad,
and bring some existing slothful, unmotivated high-level-
language coders into the HLA fold.
Never know. COULD happen.
Of course, if it does, it'll set back the "assembly rebirth"
by another two or three years. Hehehe!
Love,
Annie
The Half A Wannabee
The Half A Wannabee
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:ISqOb.28$7r2...@newsfep3-gui.server.ntli.net...
> Betov wrote:
> > Randy wrote:
>
> I repeat my favourite Yoda saying:
> "Fear and anger path to Dark Side is, young master Annakin"
As in : Fear of the Dark side is the path to the Dark Side.
Dont get misled into dividing things up Beth.
Remember "An Inspector calls" ?
HLA LOGIC:
Listen ye faithless children :
Jesus dies on a cross to wipe out your sins, right ?
All you have to do is belive in it.
So why you are so afraid of sinning.
Is it because you dont belive in him ?
Loop Listen ye faithless children ;
The Half A Wannabee
wolfgang kern
Hi Randy,
| > I think the main differences in the definition of the term
| > "assembler" are found in the programmers targets.
| > And there are many within this NG.
| A target defines whether or not something is an assembler?
| Hmmm....
Think about a newbies background and expectation...
And HLA "is" a high-level language compiler.
| > ... I became familiar with the 'orignal' syntax
| > (I find HLA,GCC and similar are almost unreadable).
| IOW, HLA is not an assembler because you don't know
| anything about it.
Hey, this isn't your style :) too many encounters with Rene?
I've seen your source examples ...
Hard to believe that some people prefer what you make out of:
xx000 MOVZX EAX,CS:[EPB+EDX*4]b
xx005 ...
or even more worse:
xx000 MOV ES:[EDI],87654321h
xx007 ...
how many keystrokes would this require with HLA?
and does HLA show the code size while typing source code?
| > For them it's vital to get in business ASAP and will find Randy's
| > HLA convenient to start with.
| > Fine so far, but HLA-students never will make it to the roots,
| > they will remain 'user-level' programmers (from my point of view).
| And why is that?
| As HLA supports all the same machine level instructions as these
| other assemblers you mention, how does HLA prevent those
| programmers from doing any low-level stuff?
Your students are stuffed with 'your' syntax and need to learn
true machine code later on in addition to get a clue of low-level code.
I see many questions in the ASM-NGs which come from totally
confusing caused by have learned HLA/GCC before reading IA-docs.
| And while you're at it, please explain how you move beyond
| "user-level" stuff in RosAsm?
:) You know, I'm not using this either,
as it is M$/linux-dependent and restricted to PE-files,
but at least I can easy read and interpret it.
__
wolfgang
PS: please don't fall upon every newbe with "go Webster's"
like a pirate, give them a fair choice.
wolfgang kern
Hi Randy,
[..]
| Even .COM files are not exactly pure binary executable images.
?? What else then?
Please tell me what I may have missed in a .COM files structure.
Ok, the file may contain parameters and strings within the code.
__
wolfgang
wolfgang kern
Hi Randy,
| > Perhaps I know why you like HLA,
| > it satisfy your "maniac typing needs"? :) :) :)
| > For me there are too many key-strokes required by far.
| So the truth is, HLA is not an assembler because it's not as
| terse as other assemblers? Hmm....
No, it's just another disadvantage.
I would call it an assembler, if it can show
code-bytes and -size in the HLA source-editor
(without compiling first).
The "standard ASM" layout looks like(opcode may be hidden):
offset|opcode |source |comments [cycles]
0000 b8 21 43 65 87 MOV EAX,87654321 ; [1]
0005 c6 45 33 80 MOV [EBP+33],80 ; [3]
0009 _ ; [ ]
If HLA can't show this while typing source code,
then it is just a text-based compiler.
| Note that this is in direct contrast to a previous post of your's
| where you said that HLA, like GCC, is unreadable.
| It's clear why you find HLA unreadable -- you don't know the language.
Yes, I don't know much about HLA/GCC, but I've seen enough,
so if I really need to translate HLA or AT&T syntax into ASM,
I'll be able to, even this will need a lot of my time.
| OTOH, the principles behind
| HLA's design are based on 30 year's of programming language design
| and one of the things people discovered way back in the 1970's is that
| making a source language as terse as possible hurts the readability of
| the language. Yes, you can go too far in the other direction too (e.g.,
| COBOL), but HLA's design was based on a lot of good research in
| the area of readability (e.g., in the design of languages like Ada,
| Modula-2, and so on).
30 Years? How about to think over?
I would have chosen a BASIC-styled syntax (PB, not C+/VB)
for a 'High Level' Asm.
| You may have *really* learned your own assembler to the point you
| feel it's readable. But the definition of readable isn't "we can train
| someone to read this code really well." It's "if you take an average
| programming with an average amount of training, will they find the
| typical program in this source format easy to read?" A sample
| of one doesn't cut it when you try to make claims about how
| readable a programming language is or is not. It takes a lot of
| careful research to determine what works and what doesn't.
Ok, at least your students can read HLA,
so who cares about the rest (sure the minority in your eyes).
Good readable source-code is a vital fact (service-able, bug-detection).
I really have no explanation for your "%eax%" and all the useless
doubled size definitions (e.g.: AL=byte, AX=word, EAX=dw already).
__
wolfgang
Randall Hyde
>
>
> | A target defines whether or not something is an assembler?
> | Hmmm....
>
> Think about a newbies background and expectation...
> And HLA "is" a high-level language compiler.
No. It is an Assembly Language compiler.
As Beth has amply demonstrated, you can write assembly code
without a single one of those HLL-like control statements.
What newbies are expecting is to learn assembly with a certain level of
comfort *based on their current level of expertise in a HLL* (not their
beginning level when they first learned a HLL. This is the magic of HLA-
it takes advantage of their existing knowledge to help ease the transition
to assembly. In the end, they're using *real* machine instructions, not
IFs/WHILEs/etc. But this educational process is really a function of
AoA, not HLA. In theory, one *could* write a book that ignores all
the HLL-like statements in HLA and teaches assembly language without
all this. They'd be using the same compiler. Just a difference in
perspective
while learning. However, as most programmers who learn assembly
already know a HLL, the AoA approach is generally better (they'll
learn assembly faster using that approach).
>
> | > ... I became familiar with the 'orignal' syntax
> | > (I find HLA,GCC and similar are almost unreadable).
>
> | IOW, HLA is not an assembler because you don't know
> | anything about it.
>
> Hey, this isn't your style :) too many encounters with Rene?
95% of the complaints about HLA are totally based on ignorance.
Sorry, *bluntness* when it comes to ignorance *is* my style;
long before Rene came along.
> I've seen your source examples ...
> Hard to believe that some people prefer what you make out of:
>
> xx000 MOVZX EAX,CS:[EPB+EDX*4]b
> xx005 ...
> or even more worse:
> xx000 MOV ES:[EDI],87654321h
> xx007 ...
>
> how many keystrokes would this require with HLA?
> and does HLA show the code size while typing source code?
DOS code. It would take an infinite amount of keystrokes as
HLA doesn't support DOS.
In Win32, you'd write something like
movzx( b[edx*4], eax );
Your second statement is not syntactically correct in any
assembler I know about, so I cannot offer an HLA
equivalent.
>
> | And why is that?
> | As HLA supports all the same machine level instructions as these
> | other assemblers you mention, how does HLA prevent those
> | programmers from doing any low-level stuff?
>
> Your students are stuffed with 'your' syntax and need to learn
> true machine code later on in addition to get a clue of low-level code.
> I see many questions in the ASM-NGs which come from totally
> confusing caused by have learned HLA/GCC before reading IA-docs.
Explain again why a student would need to learn a different syntax
to write "true" machine code? Why can't they continue to write
"mov( 0, eax );"
instead of
mov eax, 0
????
Either way, they're writing assembly code.
> | And while you're at it, please explain how you move beyond
> | "user-level" stuff in RosAsm?
>
> :) You know, I'm not using this either,
> as it is M$/linux-dependent and restricted to PE-files,
> but at least I can easy read and interpret it.
You are a better man that I :-)
> __
> wolfgang
>
> PS: please don't fall upon every newbe with "go Webster's"
> like a pirate, give them a fair choice.
Now this is *really* funny.
"Please exclude *your* product in order to give the others
a fair chance." I love it :-)
Cheers,
Randy Hyde
Randall Hyde
>
> Hi Randy,
>
> | > Perhaps I know why you like HLA,
> | > it satisfy your "maniac typing needs"? :) :) :)
> | > For me there are too many key-strokes required by far.
>
> | So the truth is, HLA is not an assembler because it's not as
> | terse as other assemblers? Hmm....
>
> No, it's just another disadvantage.
> I would call it an assembler, if it can show
> code-bytes and -size in the HLA source-editor
> (without compiling first).
> The "standard ASM" layout looks like(opcode may be hidden):
>
> offset|opcode |source |comments [cycles]
> 0000 b8 21 43 65 87 MOV EAX,87654321 ; [1]
> 0005 c6 45 33 80 MOV [EBP+33],80 ; [3]
> 0009 _ ; [ ]
>
> If HLA can't show this while typing source code,
> then it is just a text-based compiler.
IOW, only debug and its ilk are "real" assemblers.
yeah, right.
>
> Yes, I don't know much about HLA/GCC, but I've seen enough,
> so if I really need to translate HLA or AT&T syntax into ASM,
> I'll be able to, even this will need a lot of my time.
As are these posts. So why do you make them?
>
> 30 Years? How about to think over?
> I would have chosen a BASIC-styled syntax (PB, not C+/VB)
> for a 'High Level' Asm.
Feel free to write your own assembler based on Basic rather than
C/C++ or whatever. Better yet, join the RosAsm group. I hear
that's what they're doing next.
> | You may have *really* learned your own assembler to the point you
> | feel it's readable. But the definition of readable isn't "we can train
> | someone to read this code really well." It's "if you take an average
> | programming with an average amount of training, will they find the
> | typical program in this source format easy to read?" A sample
> | of one doesn't cut it when you try to make claims about how
> | readable a programming language is or is not. It takes a lot of
> | careful research to determine what works and what doesn't.
>
> Ok, at least your students can read HLA,
> so who cares about the rest (sure the minority in your eyes).
The rest already have this problem. None of the assemblers are
syntactically the same. Some pairs are more similar than others,
but one need only look at posts where some poor NASM user
is trying to enter some MASM syntax to understand the problem.
As I've said in a different post; if someone is going to become
a *good* assembly language programmer, they're eventually going
to have to get comfortable with many different syntaxes for assembly
language. That includes MASM, Gas, HLA, NASM, FASM, etc.
> Good readable source-code is a vital fact (service-able, bug-detection).
> I really have no explanation for your "%eax%" and all the useless
> doubled size definitions (e.g.: AL=byte, AX=word, EAX=dw already).
IOW, you don't really know x86 assembly language. You're happy with
your little DEBUG-like programming scheme, but God forbid you actually
have to learn the syntax for an assembler. I'm supposed to modify HLA
for *your* benefit?
Hmmm...
Cheers,
Randy Hyde
Randall Hyde
> Randy wrote:
>
> But, fair play, Annie is correct regards the _physical facts_ of the
> matter...yup, it does just "pre-process" HLA stuff for MASM or FASM or
> something to actually finish off the job (of course, this argument
> will _ONLY_ hold weight until v2.0 shows up and it's out of the
> "prototype" phase...so I Hope you've been preparing your speeches and
> statements ready for that eventuality, as the source code is already
> being written...and knowing Randy's usual productivity, it'll be here
> before we know it :)...
Well, if you want to bend the term "preprocessor" around, sure
it could mean this (then again, such abuse of the term makes
just about every product out there a "preprocessor").
Preprocessors have traditional been what we call "embedded
languages". A good example of a preprocessor is RatFOR, and
it amply demonstrates the difference between a preprocessor
and a compiler. RatFOR (like all preprocessors) recognizes
certain syntactical elements in a source file and translates those
elements. It ignores everything else (which, in this case, is just
standard FORTRAN code). The C preprocessor is another
example -- it recognizes those items that are specific to the
C preprocessor and passes everything else through unchanged
(which is just plain C code).
HLA doesn't work this way. It processes *everything* and
translates it to something else (well, there is the #asm..#endasm
sequence, but we'll ignore that here because the stuff that
falls between these two statements is not part of the HLA language
and most people never use these statements).
Calling HLA a preprocessor is akin to calling GCC a preprocessor
because, from a technical standpoint, they both work the same way.
They are both compilers, not preprocessors. The fact that their
intermediate output is human readable does not change this fact.
Cheers,
Randy Hyde
Betov
$7r2...@newsfep3-gui.server.ntli.net:
You will excuse me if i miss-understood the question, because i am very
tired, to-night.
If you ask about, where the Data are, in a PE file compiled with
RosAsm,... well,... there are, _evidently_ at the place you wrote them in
your Source.
I don't understand the relationshiop you are doing between this problem
and the TITLE feature. The Assembler don't care of any concept like the
TITLE one, as all of such things are ripped off, just like Comments are.
(By the way, i did a design error with this implemention, i sould have
implemented it the same way i recently implemented the "Tag Comment"s
feture, that is... under the form of TITLE _Comment_:
; TITLE Part1
... Too late,... too bad ;)
The File RosAsm compiles is the one you can see on your Disk when
depressing [Ctrl][S] and selecting the [Save whole Source] Button, in
case of enTITLed Source.
For you other remarks, as soon as my eyes falled under your statements
selling to me the "professionalism" of Master Pdf, i have read in, (as we
say in french) the diagonal way... and just locked my eyes going downward
when reading the words "Terrible illusion".
Yes, the beginners who believe that they can learn Assembly, "Top/down"
by gently and slowly moving from HLL to HLL-Like-Assembly and To
Assembly, ... are living a "terrible Illusion". Nothing but more
difficulties and more spoiled time with this, in all cases, and XXX times
more with an horror like HLA. Evidently.
As whatever i could say will never change a thing, when swindlers like
Master Pdf are gently pushing their heads under the water, with their
full agreament, i will have _NO_ ethical problem with selling them the
SAME BULLSHITS, once the Basic Pre-Parser will be implemented, under the
form of some indecent:
"Hey! Little birds! Come on! You can do Basic with RosAsm, and this will
make it quite easy, for you, to gently, slowly, progressively, upgrade to
Assembly!".
Yes, i am able to say such stupidities, if required. No matter.
What matter (what _will_ matter in some not so far future), will be with
having them COMING IN. As long as they are OUT, i can say whatever i like
to, this will have zero effect. Once they will be IN, it will be quite
trivial and 100% easy to show them how simple Assembly really is, and to
push them directely into the great bath, instead of letting them waste
their time with utterly wrong ideas, that have been spread on young heads
since ages, like: "Asm is difficult", "Assembly Programming is slow",
"Asm programming is dangerous", "Asm bugs are terrific", and so on.
Nobody ever told them: "Yes Assembly is actually difficult because nobody
ever invested some decent time and efforts for making it easy!"... As
long as i am one of the very few -if not the only one- saying that
Assembly Programming can be fast, easy, secure, easy to debug,
readable,... Why would they believe a man saying the reverse of what all
the so great "experts", like Master Pdf, say?
Rest assured that i will have zero ethical problem with fighting
swindlings by swindlings. I am just studying this sophisticated Art of
Propaganda from a great expert, and i think i am on the right way for
fully understanding, as shown by his recent defeats, when trying to
attack me on the seriousness of my work. (By the way, he seems to have
understood that RosAsm was not easy to beat by technical attacks, and
that it is much more easy for me to win the fight when defending than
when attacking... Too bad... it was much fun...).
Betov.
Betov
news:p4mk00tkjmes4dkqr...@4ax.com:
> On 17 Jan 2004 19:26:27 GMT wrote Betov <be...@free.fr> in
> alt.lang.asm with <XnF9473D37C2F...@213.228.0.75>
>
>>Long before writting RosAsm, i had two Folders on my Disk:
>>One for [assemblers] and one for [HLLs]. I have around 25
>>Assemblers in the [Assemblers] one.
>>
>>Guess in which one HLA is ??? ;)
>
> Considering your feelings towards HLA I would assume its in the
> Trashbin. :)
>
:))
Always usefull to know the enemy.
:))
Betov.
Betov
$7r2...@newsfep3-gui.server.ntli.net:
> People already knowing _HLL_ programming could eventually learn
> something about _ASM_ programming with AoA..._then_ you are, indeed,
> starting to get the point, perhaps?
>
Not at all.
I have several experiences with new comers to RosAsm that were coming
from HLL. Such programers seriously experienced in HLLs are amaizingly
fast at switching to Assembler.
(I say "seriously experienced" here, because i have seen too much of
these guys saying "I have learned C",... after two weeks of C... -with
"experienced" i don't mean, here, HLL real experts"...-).
I recall of one who, one day, sent me a mail for saying to me, that he
wanted to write something in Assembly, just for enable him to write on
his CV, that he was really knowing something about Assembly. He asked for
what App he could write in... two weeks... (!!!...).
Needless to say i was a bit horrified with the "Two weeks" and i was
trying to calm him down and to push him to choose something very simple.
But i never succeed to, and he begun writting a "small" Dx Game (!!!...).
I was completely convinced he could never achieve this, with RosAsm, in
two weeks, and i was a bit sad of having failed to "calm him down"...
... Well,... two weeks later he sent me the "SpAsm Invaders" Game
actually available at RosAsm [Users Demos] Page!...
This experience fully and definitively convinced me that, say, a "good"
(same comment as above) C programmer, does need not, at all, that anybody
explain to him how to translate anything from C to Assembly, other but by
reading the very simple informations on the basic of Assembly Syntax, and
a couple of working examples.
Another point is with the IQ. Programming is an intellectual activity. It
does not help with considering new comers stupid. This is always, and in
all cases, a terrific error. 1) If they are intelligent enough they don't
need "year-one-pupils-type" explanations. 2) If they are not intelligent
enough (no shame at this... but...), Programming is not a good activity
for them, and the sooner they leave, the better for everybody, including
for their girl-friends, (as long as not yet any girl at RosAsm Board...).
;)
Betov.
< http://betov.free.fr/RosAsm.html >
Rally
> Ah, this is a personal issue...indeed, some people learn better "top
> down" and some learn better "bottom up"...if you _know_ you're a
> "bottom up" kind of person, then, indeed, perhaps AoA might not be the
> best choice for you...for example, some people around here came to
> assembly programming "from below", so to speak...they are electronics
> people who dealt with the actual circuit boards and that kind of thing
> and then "graduated" up to assembly language (programming their
> home-made boards giving them a "taste" for ASM programming that they
> liked doing :)...
>
> But, in that regard, AoA is clearly signposted as "previous HLL
> experience recommended"...it's targetted at the HLL coder who wishes
> to _move down_ to assembly...that's also why Rene's accusation of
> "polluting" these people with "HLLisms" is an absurd nonsense...AoA's
> target audience _ARE_ HLL coders and the way it progresses gradually
> introduces them to lower-level ASM coding as they go...
I think accusations in this topic are a little silly. "HLLisms" is clearly
dogma and not valid as part of an answer about the best way to learn asm.
> It's a "top down" approach because this approach _usually_ is best
> across a wide range of people...generally in educational
> establishments, in fact, this approach is used because, for the
> "average" person, this works best...note, though, of course, you may
> not personally be an "average" person...OR, as I say, you've got no
> HLL experience but some electronics experience and, thus, are
> naturally "coming from below" to the topic...
I learned asm as my first programming language. This was in a computer
programming school in the 60s. The lessons in assembly began right after a
couple of weeks studying number systems and general computer concepts. Then
assembly, then Cobol and then RPG, which I never used. I have no experience
whatever in electronics.
Most of my career was spent doing about 70% to 85% HLL (Cobol and later
Basic and C) and the rest asm. So while I did learn asm first, I have a lot
more HLL experience than asm experience.
I guess part of the reason I think learning asm first is because that's how
I learned it. But another reason is that understanding the CPU is not only
central to understanding asm for the future asm programmer, but is also
extremely useful to the HLL programmer who will never use asm again, except
possibly in debugging from time to time. Knowing how the computer works is
a major asset for any programmer.
> AoA may, indeed, prove awkward to people who're better with "bottom
> up" or who are naturally coming from that direction or have no idea
> about HLLs to begin with...indeed, AoA may prove more of an obstacle
> than a help if you've got to go learn a HLL first in order to
> "de-learn" the HLL to learn ASM...that's "against the grain" of what
> AoA is presuming about your experience and direction...that's why,
> basically, it has the "previous HLL experience recommended" label
> stuck on it...
I find it hard to conceive of anyone having more difficulty learning the
basics first even if they have a good understanding of ifs and ands. It
seems to me that that understanding might make it somewhat more difficult to
focus their attention on the basics and that starting with the CPU would
help with that.
I think the most difficult thing for an HLL programmer looking at the CPU
and the instruction set is not understanding it, but understanding why it's
useful, and I worry that an HLL programmer will focus on the HLL-like things
in HLA and have a more difficult time making the mental leap from the
instruction set to computing as it's seen from the HLL perspective.
I'm not trying to imply that HLL is a bad way to learn asm. I'm sure it
isn't. But I don't think it's the best way for anyone learning asm. I
guess it's probably easier for the teacher, though. :)
> > Fortunately you can use the 16 bit version of AoA to learn asm the
> usual way
> > with a standard assembler and still have a very comprehensive book,
> while
> > learning in a dos environment, which is a much simpler programming
> > environment. I think this is the best way to learn asm programming.
>
> Yes, it's an alternative that some people may prefer...but, of course,
> if someone intends to write Windows applications then learning DOS is
> "going around the houses" to get there...not that that necessarily is
> a "bad thing" or anything...just it's fair to point out that if your
> destination is Windows coding then going via DOS is "taking the scenic
> route to get there", so to speak...it doesn't make it "wrong" or
> anything, of course...just it's only fair to warn about that need for
> greater patience..
I think learning asm would be so much faster and easier in Dos or some other
"stay out of your way" OS that the typical student would reach some level of
competence in Windows assembly programming more quickly taking that route
than by doing it in Windows from the start.
Of course there will be those people who only have Windows programming
experience who think Windows is the computer and it might take them a little
longer going the Dos route, but then I think they need that more than
others. But I can think of good arguments against their needing it in some
cases, too.
> .one thing about that approach is that you'll get to
> grips with more than one OS in doing so (although, DOS is "outdated"
> in modern OS architecture designs...again, no insult to DOS because
> this fact is often _brilliant_, as you can actually get your hands
> dirty with hardware access on DOS without any fuss or bother...but,
> again, a warning that you're learning methods that all the other
> modern OSes like Windows and Linux have actually "undone")...
I wasn't really thinking of Dos as being advantageous because you can get to
the hardware. I doubt that the typical programmer will care about that
today. The advantage I see is that in Dos you only have to think about ASM
and the CPU and only sometimes be concerned with OS, while with Windows you
have to constantly interface with the OS. In Windows programming, you're
always dealing with Windows programming. In Dos programming....well,
actually there isn't much Dos programming. It's mainly you and the CPU.
> Oh, one last nit-pick: What's a "standard assembler", anyhow? Assembly
> language has _NO_ "standard" (at least, none that anyone pays any
> attention to ;) and no two assemblers are alike (MASM and TASM are the
> closest together...but then compare TASM in ideal mode doing OOP to
> MASM and realise that even these "close cousins" disagree in big ways
> in places...in fact, to an extent, their "disagreement" has fuelled
> the variety of diversity we see...I'm sure that it wasn't total
> coincidence that NASM's "cleaned up" syntax wasn't at least partly
> inspired by TASM's attempt to "clean up" MASM syntax in IDEAL mode
> because kick out "offset" and they are almost identical...did Borland
> start this avalanche we now see without meaning to? ;)...perhaps
> you'll disagree but I think that perhaps "traditional assemblers" is
> the best term to differentiate between HLA from the more "Intel
> syntax" traditional kind of assembly language...
Okay, the term "standard assembler" wasn't a good choice. "Traditional"
works better.
I learned 8086 asm using one of Peter Norton's books, I forget it's title
now, that used debug as the initial tool for teaching the basics of the CPU
and a subset of the instruction set before it went on to using a real
assembler. I didn't finish the book. I had to do my first PC programming
project and I used it to kind of jump start myself. I wish I'd had tools
like that to learn asm initially. It was great
Yes, I know I'm not a good example because I had experience on other systems
already. But that seemed to me so perfectly direct a way to learn that I
can't imagine anything better.
Barry
Rally
news:XnF9473831E7B...@213.228.0.4...
> "Beth" <BethS...@hotmail.NOSPICEDHAM.com> écrivait news:ta3Ob.3$EI4.0
> @newsfep3-gui.server.ntli.net:
>
> > But, in that regard, AoA is clearly signposted as "previous HLL
> > experience recommended"...it's targetted at the HLL coder who wishes
> > to _move down_ to assembly...that's also why Rene's accusation of
> > "polluting" these people with "HLLisms" is an absurd nonsense...AoA's
> > target audience _ARE_ HLL coders and the way it progresses gradually
> > introduces them to lower-level ASM coding as they go...
> >
>
>
> People already knowing much about programming
> could eventually learn something with AoA.
>
> For the pure beginners, there'd better read...
> B_U_Asm and save themselves from a much slower
> access to Assembly...
>
> time, Beth?
In other words.... your technique is to restate what she said in your own
words and then present arguments against what you said.
Cute. :)
Barry
Betov
@news.easynews.com:
I am not quite sure of the real result, once i have played making nodes
on Beth nodes, and after you made nodes on my own nodes, but i feel
pleased that you can make any logical overall statement over the packed
of nodes.
:)) :)) :))
The very initial Node was with Master Pdf saying: "HLA is designed to
help beginners learning Assembler. Proof: It worked fine for me, the last
time -...- i saw studients...".
Though i have no doubt it worked fine for him, i have the heaviest doubt
it could really have worked for the poor studients... other than helping
them having some "Asm grade" while writing HLL.
:)) :)) :))
Betov.
Betov
$1e.1...@newsread2.news.pas.earthlink.net:
> HLA doesn't work this way. It processes *everything* and
> translates it to something else (well, there is the #asm..#endasm
> sequence, but we'll ignore that here because the stuff that
> falls between these two statements is not part of the HLA language
> and most people never use these statements).
>
> Calling HLA a preprocessor is akin to calling GCC a preprocessor
> because, from a technical standpoint, they both work the same way.
> They are both compilers, not preprocessors. The fact that their
> intermediate output is human readable does not change this fact.
>
:)) :)) :)) :)) :))
Fully agrea. Loud applaud. Many thanks. Betov.
< http://betov.free.fr/RosAsm.html >
Betov
@news.f.de.plusline.net:
:)) :)) :))
Too bad you are one of those i call "The new US Nazys". I would be glad
having a girl at RosAsm Board, if not.
Unfortuantely, what i call the Assembly Rebirth includes ethical and
political concerns... Too bad!...
Randall Hyde
> _____
> A fairly SIGNIFICANT detail, ((( `\
> seeing as how the code gene- _ _`\ )
> rator (MA$M) was written by (^ ) )
> someone else; not by you. ~-( )
Yep, it's called leveraging the work others.
Sorta like the linker, resource compiler, RadAsm,
and other tools that I haven't personally written.
Kinda gives me the time to work on the more advanced
features in the assembler. :-) It also makes it possible
to more easily port the assembler to other operating
systems as I don't have to worry about the issues
of the executable format for any given OS; Gas, MASM,
FASM, whatever, handles those details. Perhaps you
can claim I'm lazy; doesn't change what HLA is, however.
_'((,,,)))
> But putting that aside, you're ,-' \_/ `\
> STILL fudging the definitions ( , |
> here, Randy...and you KNOW it. `-.-'`-.-'/|_|
How is that. I've always argued that HLA is a compiler
for an assembly language. Having written several different
compilers and assemblers (including some that generate
machine code directly), having taught compiler courses,
I think I have a pretty good idea what type of tool I've
created. Now what was it *you* done again that makes
you such an expert on the defintions of these tools?
> \ / | |
> HLA syntax might, indeed, tech- =()=: / ,' aa
> nically qualify as -AN- assembly
> language -- a semi-proprietary dialect of your own
> design -- but it isn't "assembly language" in the
> generally-accepted meaning of the common parlance.
Every assembler out there is a "semi-proprietary dialect" of
their author's design. Some are more radically different than
others (e.g., RosAsm, Gas, Terse, and HLA) while others
are closer to one another (FASM/NASM or MASM/TASM)
but the bottom line is that they all have their own unique
syntaxes and their own followers. That doesn't change the definition
of what they are.
>
> Frankly, you might have greater success with HLA if
> you'd quit trying to obfuscate the fact that it's a
> "front end" for MA$M, and PROMOTE that fact as a
> desirable "feature."
The fact that the HLA compiler can translate HLA source
into source code that is acceptable by other assemblers is
indeed a desirable feature to some people. Indeed, originally
I only planned on emitting object code in HLA v2.0 but I've
had several people request the source code output facilities
as an optional feature, it's become clear that this is not a
facility that can be abandoned in HLA v2.0. That facility,
however, doesn't change the definition of what HLA is.
Indeed, such facilities demonstrate the futility of trying to
define what HLA based on the intermediate code generation.
After all, if HLA v2.0 emits binary machine code, then it's
an assembler by your definition. But if it emits source code,
then it's a "front-end" or "preprocessor". But what is it if
it does both? Hmmm....
> "Already know a high-level language? Then YOU, TOO, can
> now write code for MA$M -- using Randy Hyde's amazing
> new high level interpolator, HLA (tm)! Yes, now there's
> no need to bother with all those pesky and difficult
> low-level details of assembly language! Abstract them away,
> with HLA!"
Amazing how the "anti-HLA" contingent keeps trying to promote
the idea that HLA programmers just stick with this HLL concept
rather than simply using it as a stepping stone to learning assembly.
As you've been around long enough to have read the rebuttle to this
argument in the past, this statement is not being made in ignorance,
but simply it has become a misstatement of fact on your part.
Shame on you, you know how the process works yet you keep
trying to present it in a different light. What does Rene call that?
"Lying and Swindling," I believe.
> It might extend your potential client base beyond the
> realm of the slothful, unmotivated university undergrad,
> and bring some existing slothful, unmotivated high-level-
> language coders into the HLA fold.
>
> Never know. COULD happen.
>
> Of course, if it does, it'll set back the "assembly rebirth"
> by another two or three years. Hehehe!
> Love,
> Annie
Rene has no desire to work with beginners. I really have no desire
to work with people who already know assembly language. Not
that I don't respect them or their abilities, but my goal is to teach
people assembly language programming. It's a waste of time to
teach assembly programming to those who already know it.
If they're happy with their tools, let them use them as far as I'm
concerned. Why should they waste time learning HLA?
HLA is not about world conquest. It's about teaching beginners
assembly language who alread know a HLL on terms they find
a bit more comfortable. If it succeeds, it will not be because it
converts the existing world of assembly programmers to HLA
(a plan I gave up on within a week of the release of HLA v1.0
when it was obvious that people don't shift, en-masse, from the
tools they already use); instead, HLA will succeed because it's
the tool that the next generation of assembly programmers are
using to learn assembly.
You can whine and moan about what HLA is and isn't. But with
each passing day, your arguments become a little more archaic.
The "assembly rebirth" that Rene keeps talking about is well
underway. And it's that high-level assembler MASM that's
leading the way (using the high-level assembler paradigm).
Cheers,
Randy Hyde
Gerhard W. Gruber
<rand...@earthlink.net> in alt.lang.asm with
<QXyOb.15549$1e.1...@newsread2.news.pas.earthlink.net>
>Explain again why a student would need to learn a different syntax
>to write "true" machine code? Why can't they continue to write
>"mov( 0, eax );"
>instead of
>mov eax, 0
Wow! This statment really showed me now how far I'm gone now from them M68000
thinking. :)
When I was first learning a PC I had a hard time getting used to the fact that
intel assignes values to registers the "wrong" way around. This was quite some
time ago, and now I'm so used to that syntax, that the first statement looks
totally weir to me, even though it is the "right" way around. :)
--
Gerhard Gruber
Maintainer of
SoftICE for Linux - http://pice.sourceforge.net/
Gerhard W. Gruber
<rand...@earthlink.net> in alt.lang.asm with
<F0zOb.15556$1e....@newsread2.news.pas.earthlink.net>
>> No, it's just another disadvantage.
>> I would call it an assembler, if it can show
>> code-bytes and -size in the HLA source-editor
>> (without compiling first).
>> The "standard ASM" layout looks like(opcode may be hidden):
>>
>> offset|opcode |source |comments [cycles]
>> 0000 b8 21 43 65 87 MOV EAX,87654321 ; [1]
>> 0005 c6 45 33 80 MOV [EBP+33],80 ; [3]
>> 0009 _ ; [ ]
>>
>> If HLA can't show this while typing source code,
>> then it is just a text-based compiler.
>
>IOW, only debug and its ilk are "real" assemblers.
>yeah, right.
SoftICE does this, because it contains a driect assembler, but I never had the
idea to call it an assembler. :)
Actually I don't know of ANY symbolic assembler that really shows you codesize
or that stuff.
Betov
> On Sun, 18 Jan 2004 16:59:28 GMT wrote "Randall Hyde"
> <rand...@earthlink.net> in alt.lang.asm with
> <QXyOb.15549$1e.1...@newsread2.news.pas.earthlink.net>
>
>>Explain again why a student would need to learn a different syntax
>>to write "true" machine code? Why can't they continue to write
>>"mov( 0, eax );"
>>instead of
>>mov eax, 0
>
> Wow! This statment really showed me now how far I'm gone now from them
> M68000 thinking. :)
>
> When I was first learning a PC I had a hard time getting used to the
> fact that intel assignes values to registers the "wrong" way around.
> This was quite some time ago, and now I'm so used to that syntax, that
> the first statement looks totally weir to me, even though it is the
> "right" way around. :)
>
Trap ahead! Gerhard.
Intel "Syntax" is nothing but a "recommendation". Would you create some
Assembler with a ten times more demential Syntax than HLA, as long as the
1:1 correspondance would be preserved, and as long as the Language, by
its implied philosphia, would keep pushing to the "Thinking-Assembly",
... it would yet be an Assembler.
The evident reason why Master Pdf choosed the "reversed syntax" is to
make it as difficult as possible for a beginner, falling into the HLA
trap, to switch from HLA to an Assembler. Nothing else. Strategically
evil,... but,... "neat"... :))
Betov.
Betov
@newsfep3-gui.server.ntli.net:
> But, fair play, Annie is correct regards the _physical facts_ of the
> matter...yup, it does just "pre-process" HLA stuff for MASM or FASM or
> something to actually finish off the job (of course, this argument
> will _ONLY_ hold weight until v2.0 shows up and it's out of the
> "prototype" phase...so I Hope you've been preparing your speeches and
> statements ready for that eventuality, as the source code is already
> being written...and knowing Randy's usual productivity, it'll be here
> before we know it :)...
>
When HLA will have an Encoder inside, it will yet be an HLL Pre-Parser
with an Encoder inside, instead of a Pre-Parser with an Encoder outside.
This yet not make HLA an Assembler at all. Whatever room you put the
things, HLA will aways be Top-Down, in the exact same way RosAsm will
always remain an Assembler, even with a Basic Pre-Parser inside, because
RosAsm is Buttom-Up.
So said, given the "competency" level of Master Pdf, i would be a bit
estonished if HLA Encoder could be finished and bug free in the soon
coming weeks... As usual, he will much probably begin to "sell" it two or
for years before effective. Unfortunately for him, i am afraid that
"being good at selling" will not help that much one this one. And, again,
even when perfectly finished and bug free, this will not change a thing.
Betov.
Betov
$1e....@newsread2.news.pas.earthlink.net:
> Rene has no desire to work with beginners.
Oh! Yes, i "would" like to. By the way... i _did_ in the past.
Unfortunately, because of propaganda, and because of time... I CAN NOT.
I am not working for ethical-free guys wanting an Assembler for
programming under windows. And, as long as ReactOS is not yet usable, for
at least, a simple Auto-Compilation, i can answer nothing to injuries
like "You are writing and Assembler for Windows".
This is the main reason why i stopped SpAsm Devs, and restarted with
RosAsm Devs.,... with an evident huge lost of user base.
Another good reason for doing so is that taking care of beginners takes a
lot of time and that i have only two hands and 12 hours a day... whereas
the oncoming of ReactOS is becoming closer and closer each day, and that
RosAsm _must_, absolutely, be ready for that event.
Betov.
< http://betov.free.fr/RosAsm.html >
Annie
On 2004-01-18 be...@free.fr said:
> :)) :)) :))
>
> Too bad you are one of those i call "The new US Nazys".
> I would be glad having a girl at RosAsm Board, if not.
_____
C'est un plasir distingue' a' ((( `\
faire de votre connaisance _ _`\ )
aussi, Monsieur Betov. (^ ) )
~-( )
Eh bien, je ne utile pas les _'((,,,)))
'Windows.' Si pour moi, RosAsm ,-' \_/ `\
et HLA sont merde. ( , |
`-.-'`-.-'/|_|
Maintenant...donnez-moi du \ / | |
vin de francais. Hehehe! =()=: / ,' aa
wolfgang kern
Hi Gerhard,
[about code view within asm source..]
| SoftICE does this, because it contains a direct assembler,
| but I never had the idea to call it an assembler. :)
| Actually I don't know of ANY symbolic assembler that really
| shows you codesize or that stuff.
Yes, almost all of them need to first link/compile/make/..,
and then disassemble to see what BS-code they may have created.
So I don't understand the regular repeated discussion about
the question if HLA is an assembler or not.
From my point of view: none of NASM,MASM,TASM,FASM,RosASM,etc.
are 'assemblers' in classical means, this all are compilers,
regardless of the used syntax.
I miss any of the immediate line compilers in the IA-xx world
(this is what I'd call 'pure assembler'),
which are very common tools since ages for other CPUs.
The last tool seen with this behaviour was debug.exe
(unchanged since DOS1.0).
__
wolfgang
wolfgang kern
Hi Randy,
[..]
| > Yes, I don't know much about HLA/GCC, but I've seen enough,
| > so if I really need to translate HLA or AT&T syntax into ASM,
| > I'll be able to, even this will need a lot of my time.
| As are these posts. So why do you make them?
Why? More than 1000 notes about HLA vs. RosASM ...
and only a few ASM-questions from soon scared off newbies.
| IOW, you don't really know x86 assembly language.
| You're happy with your little DEBUG-like programming scheme,
| but God forbid you actually have to learn the syntax for an
| assembler.
Yes, I'm very happy with my 'little' tools.
Yes, as I know hexadecimal machine-code by hearth,
I've no need to learn any 'weird syntax',except I use the
'original mnemonics' to discuss/share code solutions within NGs.
| I'm supposed to modify HLA for *your* benefit?
Sure not, but as you talk your very own language,
you may once find yourself with your students on an isolated isle.
__
wolfgang
wolfgang kern
Hi Randy,
[..]Ok.
| > I've seen your source examples ...
| > Hard to believe that some people prefer what you make out of:
| > xx000 MOVZX EAX,CS:[EPB+EDX*4]b
| > xx005 ...
| > or even more worse:
| > xx000 MOV ES:[EDI],87654321h
| > xx007 ...
| > how many keystrokes would this require with HLA?
| > and does HLA show the code size while typing source code?
| DOS code. It would take an infinite amount of keystrokes as
| HLA doesn't support DOS.
What makes you think of DOS by this?
I see, the segments ... HLA doesn't support segments.
But KESYS use segments in PM (for kernel isolating only).
| In Win32, you'd write something like
| movzx( b[edx*4], eax );
Where is the EBP gone to?
CS-overrides make sense in Win32 also,
allowing local parameter-reads without detouring pointers.
| Your second statement is not syntactically correct in any
| assembler I know about, so I cannot offer an HLA equivalent.
Ok, other compilers may need double defined parameter-size also.
26 c7 07 21 43 65 87 MOV ES:[EDI]dw,0x87654321
| Explain again why a student would need to learn a different syntax
| to write "true" machine code? Why can't they continue to write
| "mov( 0, eax );"
| instead of
| mov eax, 0
| Either way, they're writing assembly code.
Ok either way, but don't you see the obvious size difference?
| > PS: please don't fall upon every newbe with "go Webster's"
| > like a pirate, give them a fair choice.
| Now this is *really* funny.
| "Please exclude *your* product in order to give the others
| a fair chance." I love it :-)
Not to pick on your distribution strategy,
[even it looks like you are on a holy mission :) ]
but whenever you answer a newbe-question with "go Webster's",
all non-HLA fans leaded by Rene will start again the regular
repeated and already boring discussion.
And as a side-effect the newbe will flee 'this ASM scene' AOI.
Have you ever seen me posting "go KESYS" or
"HEX_WORK is the only truth"?
I select my pupils with more care about adequate targets.
__
wolfgang
Randall Hyde
>
> | In Win32, you'd write something like
> | movzx( b[edx*4], eax );
>
> Where is the EBP gone to?
> CS-overrides make sense in Win32 also,
> allowing local parameter-reads without detouring pointers.
if "b" is a local variable or parameter (my assumption reading
that code above), then EBP is included there. Just as with
MASM, TASM, etc.
> | Your second statement is not syntactically correct in any
> | assembler I know about, so I cannot offer an HLA equivalent.
>
> Ok, other compilers may need double defined parameter-size also.
> 26 c7 07 21 43 65 87 MOV ES:[EDI]dw,0x87654321
Okay, my mistake. I see now that you're using a suffix on the
addressing mode to specify the size of the operand. You'll
have to forgive me, not having ever seen that syntax (on the x86)
prior to your post.
>
> Ok either way, but don't you see the obvious size difference?
Obviously, it wasn't obvious :-)
> Not to pick on your distribution strategy,
> [even it looks like you are on a holy mission :) ]
> but whenever you answer a newbe-question with "go Webster's",
> all non-HLA fans leaded by Rene will start again the regular
> repeated and already boring discussion.
> And as a side-effect the newbe will flee 'this ASM scene' AOI.
Well, FWIW, Webster discusses a lot more about assembly
language than just HLA.
> Have you ever seen me posting "go KESYS" or
> "HEX_WORK is the only truth"?
> I select my pupils with more care about adequate targets.
Have you ever seen me posting HLA as the "only truth?"
Certainly, based on *experimental evidence* (i.e., classroom
and laboratory use), I can state that it is a *very* good way
to teach assembly language programming to students. Much
better than using MASM (as I was doing the ten years
prior to HLA's appearance). If it didn't work, I would have
gone right back to the traditional approach. However, it's
also clear that it's not the *perfect* solution for *everybody*.
In particular, the pedagogical approach that AoA uses
is not appropriate for people who don't already know a HLL
like C/C++, Java, Pascal, etc. AoA is a *lousy* book for
someone who wants to learn programming with assembly
as their first language, for example (however, note that such
a book *could* be written using HLA that simply ignores
all the HLL-like control structures, which would be irrelevant
to someone without the appropriate background).
Damn straight I'm on a holy mission. Have been for nearly
20 years- pushing the use of assembly language! I don't have
a problem at all with people learning with other assemblers.
I do have a problem with people shooting off their mouths
about how "this way isn't a good way to learn assembly"
when, in fact, they have no basis for making such claims
(and the evidence suggests otherwise).
BTW, if I my class were supposed to teach students
how to design a CPU, would you suggest simply handing
them the manufacturer's data sheets for the logic gates
and the FPGA and telling them "have at it; now build me
a CPU and write me an assembler for it."?
As for not promoting KEYOS, well, if there were an
OS development group and people were wanting to
learn about OS development, you'd be doing them a
disservice by not making that information available.
Similarly, if there is signficant information about assembly
programming on your site (suitable for a beginner), I
would make the same claim - you're depriving those
beginners of some interesting knowledge by not making
the URL available. And even if someone isn't interested
in using HLA, Webster has one of the best "links" pages
around to other assembly related sites.
Cheers,
Randy Hyde
Beth
> Beth wrote:
> You will excuse me if i miss-understood the question, because i am
very
> tired, to-night.
>
> If you ask about, where the Data are, in a PE file compiled with
> RosAsm,... well,... there are, _evidently_ at the place you wrote
them in
> your Source.
Yes; But where are my "titles" with regards to the source?
> I don't understand the relationshiop you are doing between this
problem
> and the TITLE feature. The Assembler don't care of any concept like
the
> TITLE one, as all of such things are ripped off, just like Comments
are.
>
> (By the way, i did a design error with this implemention, i sould
have
> implemented it the same way i recently implemented the "Tag
Comment"s
> feture, that is... under the form of TITLE _Comment_:
>
> ; TITLE Part1
>
> ... Too late,... too bad ;)
>
> The File RosAsm compiles is the one you can see on your Disk when
> depressing [Ctrl][S] and selecting the [Save whole Source] Button,
in
> case of enTITLed Source.
Yes; But shouldn't you actually _specify_ how it works? After all,
doesn't do so mandate that you must use a _different_ editor? You
can't tell from within RosAsm itself and you must use other tools to
answer your questions?
Oh, alright...you seem to think this is "great" and everything...I'll
leave you to your "terrible illusion"...
> For you other remarks, as soon as my eyes falled under your
statements
> selling to me the "professionalism" of Master Pdf, i have read in,
(as we
> say in french) the diagonal way... and just locked my eyes going
downward
> when reading the words "Terrible illusion".
Oh, yes, Rene...look down in _SHAME_ at saying that...
> Yes, the beginners who believe that they can learn Assembly,
"Top/down"
> by gently and slowly moving from HLL to HLL-Like-Assembly and To
> Assembly, ... are living a "terrible Illusion". Nothing but more
> difficulties and more spoiled time with this, in all cases, and XXX
times
> more with an horror like HLA. Evidently.
>
> As whatever i could say will never change a thing, when swindlers
like
> Master Pdf are gently pushing their heads under the water, with
their
> full agreament, i will have _NO_ ethical problem with selling them
the
> SAME BULLSHITS, once the Basic Pre-Parser will be implemented, under
the
> form of some indecent:
>
> "Hey! Little birds! Come on! You can do Basic with RosAsm, and this
will
> make it quite easy, for you, to gently, slowly, progressively,
upgrade to
> Assembly!".
>
> Yes, i am able to say such stupidities, if required. No matter.
Then you are a fool...sorry, but, whatever you believe about Randy, he
is NOT delibrately trying to deceive anyone...if there is any
deception there at all - and there simply isn't - then it must be
because _he_ has, in fact, fallen for his own illusions...
Do you understand what I'm saying? There is a world of difference
between, say, Randy believing genuinely that he's helping beginners
and helping to promote assembly...but, oops, he might have made a
mistake about how to go about it...if there is a mistake - which I
don't believe for a second - then it is _entirely_ an "honest mistake"
and nothing more...no attempt at deception at all...
In fact, you had to constantly push him over and over for _years_ just
to make him bite and actually say something _bad_ about RosAsm...he
resisted all that time because he had no intention originally of
wanting to bad mouth _any_ programmer who was working towards
_promoting assembly_ - just like he was and is trying to do - even if
he didn't personally believe in your "methods" of doing it at
all...but if there was _someone_ out there who liked what you were
doing and this helped with the overall promotion of _assembly
language_ - whichever one that is - then that was all to the good...I
told him sincerely that I was amazed at his patience with you with
unjustified assault after unjustified assault..."the patience of a
saint", indeed...which only really goes to show how much of a pest you
really can be that you could even test the patience of a saint and
find it lacking...
But what you are doing here is _delibrate_...a _conscious_ decision
(but certainly not a "conscience"-based decision or it would be
screaming "NO!!" at you right now, like I am, more or less :) to
deceive and hoodwink and _lie_ to people, simply to attempt to gain an
unfair advantage through the use of controlling _propoganda_...
You have made a very big mistake in doing this and admitting to me
that you simply don't give a crap about oppressing people with lies
and propoganda...surely, by now, you know I will NOT stand for such
things...I'm deadly serious...back down or, as you know I'm perfectly
capable of doing, I can make your life hell in response...you should
also be aware by now that I don't make bluffs...
I leave it up to you...if there's not even a partial or modicum of
retraction on this position...or a sign of regret at considering
it...then, fine...I shall endeavour to ensure that you reap exactly -
pound for pound - what you sow...of course, in my own little "poetic
justice" way because I never was much of a believer in Mosaic
law...there are many ways to win a battle and I can, at your request,
show you every single one in turn until you get the Message...
No man (or woman) of _principle_ could even consider what you
suggesting...no amount of "attack" could make Gandhi or Martin Luther
take up arms against anyone...no "ethical" conscience could ever
permit it...
Which means that you are either not the person you've claimed all this
time to be...or you have changed from the person I originally
respected for his guts to stand by principle, come what may...
You folded, you gave up, you sold out and signed the contract of
Faust...well, I assure you, I do NOT do the same...you're currently
hanging on a Damoclesian thread on the principle of "second chance"
and mercy to allow someone to turn back in regret...but, if you know
the story, it's only a single horse's hair...it takes very little to
break it...
> What matter (what _will_ matter in some not so far future), will be
with
> having them COMING IN. As long as they are OUT, i can say whatever i
like
> to, this will have zero effect. Once they will be IN, it will be
quite
> trivial and 100% easy to show them how simple Assembly really is,
and to
> push them directely into the great bath, instead of letting them
waste
> their time with utterly wrong ideas, that have been spread on young
heads
> since ages, like: "Asm is difficult", "Assembly Programming is
slow",
> "Asm programming is dangerous", "Asm bugs are terrific", and so on.
> Nobody ever told them: "Yes Assembly is actually difficult because
nobody
> ever invested some decent time and efforts for making it easy!"...
As
> long as i am one of the very few -if not the only one- saying that
> Assembly Programming can be fast, easy, secure, easy to debug,
> readable,... Why would they believe a man saying the reverse of what
all
> the so great "experts", like Master Pdf, say?
"Master PDF" does NOT say what you accuse him of saying...a long, long
while ago, he took efforts to exactly state the case against these
"ASM myths" in his "Great Debate" (actually, Randy, that stuff was
great...it's still on Webster, right? You should bring it to more
prominence under some "Assembly Articles" section, perhaps? Articles
discussing assembly language generally...ramifications, drawbacks,
advantages and kind of thing...that "Great Debate" should be _pushed
forward_, not held back, in my opinion :)...
As I've tried to explain to you time and again, Randy and myself could
have been your greatest _allies_...we also wish to explode all of
those myths...we also wish to further the promotion of assembly
language...we also wish to _educate_ primarily...we, at the core,
_share_ your original objectives...take a look back and only Randy and
myself have resisted pouring ridicule on your "assembly rebirth"
concept (yes, we've made comments about your _specific implementation_
and you don't stand a chance of succeeding taking the path you've
chosen...but no criticism at all of the _destination_)...
And, despite your "woe is me! I'm the only one who believes in large
applications being written solely in assembly" protestations, Randy
and myself have _regularly_ stated how we believe that it is entirely
possible and, in fact, share your basic idea that "tool support" is
where the "weak link" resides...
But, you have turned allies into enemies - despite our every attempt
repeatedly for _years_ that you should not do so - and now you talk
about how it is "acceptable" to _deceive_ and _lie_ and _break your
promises_ and _break your principles_, in order to "herd the sheep in
through the front door"...perhaps you're not quite getting this or not
"translating" me very well, I really am _FURIOUS_ at you...that's not
a figment of speech...are you catching my drift? I really, really mean
I'm _ANGRY_ at this...you have, indeed, tempted out my wrath on this
and I struggle desparately to hold it back because I know just how
merciless the beast inside me can really be...
In an amusing reversal of the tale, you've really been dealing with
Dr.Jekyll as you thought you were talking to Mr.(Randall) Hyde...you
will be in for a major culture shock if you make the _real_ Mr.Hyde
come out...
> Rest assured that i will have zero ethical problem with fighting
> swindlings by swindlings.
Then you are an _unethical_ fool...you will entirely reap exactly what
you sow...
> I am just studying this sophisticated Art of
> Propaganda from a great expert, and i think i am on the right way
for
> fully understanding, as shown by his recent defeats, when trying to
> attack me on the seriousness of my work. (By the way, he seems to
have
> understood that RosAsm was not easy to beat by technical attacks,
and
> that it is much more easy for me to win the fight when defending
than
> when attacking... Too bad... it was much fun...).
No, Rene, no...he just could only "suffer fools gladly" for so
long...every patience has its limits (I was always thoroughly amazed -
I commented many times - that his patience lasted as long as it
did)...if you're taking "justification" out of this, then you're in
for a major disappointment when you finally realise what really was
happening...
And you've made a double mistake in that I'm capable of suffering
practically anyhing - I make it my mission in life, I'm that good at
it - BUT you've crossed a line...ignorance is always excused...not
realising what you were actually doing is forgiveable...but you've
shown you know better...you've talked the big talk about being such a
"principled" man..._you_ were the one who pulled out words like
"morals", "ethics", etc....
But delibrate and conscious _oppression_ and _deception_ is an
altogether different thing entirely...what made you think I took
immediate and constant offence at Annie for? In the end, she made a
joke out of herself - that "poetic justice" I've mentioned...you
really do always reap what you sow, even if some choose not to believe
that - that it no longer requires my intervention and I eventually
ceased to be interested (though, such as her racist comments to
Gerhard, that does not mean I'm not jumping straight back into the
fray should she prove a problem again)...
As always, the ball is in your court...by principle, I may never
strike first and, unlike you, I stick by those religiously...but if
want to whack that ball back in my direction then you've implicitly
asked for it, as I'm warning you what'll happen, and I'll gladly
demonstrate exactly how tennis really is played...and part of me is
saying "go on, go on, I dare ya!" quietly to itself...
Beth ;)
Beth
> Beth wrote:
> > ...Annie is correct regards the _physical facts_ of the
> > matter...yup, it [HLA] does just "pre-process" HLA stuff for
> > MASM or FASM or something to actually finish off the job...
>
> Thank you, Bethie.
Facts is facts; One does not need to ever deny them at all to "win" a
battle when right _truly_ is on your side...lies are, in fact, an
implicit admission of defeat and failure...only the weak and the
deceitful ever have need to "cheat" because they had no chance to
succeed by any other means...
So, when you are correct, Annie - and you are also usually spot-on
regards Microsoft (you go too softly on them, really...as I know you
have a wicked tongue on you when you want to exercise it ;) and also
in essence about their infamous "pointee-clickee monstrosity" - I will
gladly post in confirmation of that...
Mind you, that kind of implies - because of all the arguments we've
had - just how much you've got so sorely wrong when I don't mind
saying "you're right" when you're right...but, hey, with those
"moogies" of yours to wave about, you just don't give a crap about any
of that, right? ;)
Beth :)
Beth
> Annie wrote:
> > "Already know a high-level language? Then YOU, TOO, can
> > now write code for MA$M -- using Randy Hyde's amazing
> > new high level interpolator, HLA (tm)! Yes, now there's
> > no need to bother with all those pesky and difficult
> > low-level details of assembly language! Abstract them away,
> > with HLA!"
>
> Amazing how the "anti-HLA" contingent keeps trying to promote
> the idea that HLA programmers just stick with this HLL concept
> rather than simply using it as a stepping stone to learning
assembly.
> As you've been around long enough to have read the rebuttle to this
> argument in the past, this statement is not being made in ignorance,
> but simply it has become a misstatement of fact on your part.
> Shame on you, you know how the process works yet you keep
> trying to present it in a different light. What does Rene call that?
> "Lying and Swindling," I believe.
Oh, yes...that's my Annie for you, Randy...there's a damn good reason
I've never much liked her...it's because she's ever so prone to doing
this...and, unlike Rene, who you could sort of believe is just being a
touch ignorant in his ramblings, Annie is an entirely different
beast...we _know_ she knows better, as there certainly appears to be a
very sharp mind indeed behind that "bimbo"-like fascade...
I apologise as - though this may seem a touch egocentric, the presence
of Annie _actually bothering to make a technical comment_ tends to
strongly suggest it, as she _never_ does that but to pretend that
she's being "reasonable" in order to try to tempt me back into
responding to her usual nonsense - she's probably only spreading
Rene's "propoganda" around after noticing how I was responding to Rene
and thought: "oh, so that's how to get her attention again, is
it?"...ordinarily, of course, I'd join everyone else in thinking
"geez, that's a touch paranoid" to such apparent egocentricism...but
when it comes from Annie, there's no paranoia at all, it's just
_fact_...
She is some punishment for a misdeed in my youth or previous life or
something, I'm sure...
Beth :)
Beth
> I am not working for ethical-free guys wanting an Assembler for
> programming under windows.
Right, so 100% "public domain" is "unethical"...and it's a "Windows
assembler", despite running equally well on Linux with full standard
library support for it...
And your assembler is "ethical" because you're filling it with, in
your own words, "terrible illusions" to willfuly _deceive_ people into
believing it is something it isn't (and you've also displayed that you
have no idea about any of the principles or ramifications of the GPL
licence you carry)...and your assembler isn't a "Windows assembler",
despite the fact that it can only actually run on Microsoft Windows
and has the _Microsoft Win32 API_ hard-coded into it, producing _ONLY_
Microsoft PE files (and even if the slim possibility of ReactOS
finally showing up happens, it does NOT in any way break the tie that
this is a _Microsoft specific_ assembler with support directly for
_Microsoft designs and API_ using a _Microsoft originated_ file
format...and, by this, you mean to "rid the world of Microsoft"? And
what turns this into the ultimate joke is you seem to have absolutely
no idea how ludicrous that really is in the cold light of day)...
Come on, Annie, where's your "straight talking" when we need it?
Rene's clearly talking straight out of his backside on this one and
has been doing so, as he wasted years of his time on this doomed "Holy
War"...I mean, fair's fair, Annie...I happily backed you up when you
told the truth, so surely even you have enough decency to return that
favour...after all, imagine what it would be like to remain in my
"wishy-washy" debt for a long time to come...well, you can call that
in and we can go back to being "evens", yes? ;)
Beth :)
Beth
> Always usefull to know the enemy.
Totally; Just wondering when you're actually going to get around to
doing that...
Beth :)
The Half A Wannabee
>
> Hi Gerhard,
>
Hi Wolfgang. I was wondering, are there such a compiler in your KeSys
installation ? I havent got time to look at it yet. I would like to take a
serious look at it later, maybe by beginning of mars. But the way you
describe "immediate line compilers ", makes me interested. It would be cool
to see the extact bytes written in column at the side, when I write my code.
Sort of would learn me the byte values after some time. And I guess would
learn me other things as well. Like just reading and recognizing code bits,
from glancing at some hex numbers. after all, the bytes take up way less
space than memonics.
The Half A Wannabee
> Betov wrote:
> > Beth wrote:
> Yes; But where are my "titles" with regards to the source?
Its self evident. they are in the source in order of "declaration".
TITLE Constants
..code
TITLE MemoryManagment
..code
TITLE Types
..code
TITLE Objects
..code
TITLE Threads
..code
TITLE Graphics
ecc
> Beth ;)
>
>
The Half A Wannabee
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:g3MOb.108$%8....@newsfep3-gui.server.ntli.net...
> Betov wrote:
> > Beth wrote:
(*
Then you are a fool...sorry, but, whatever you believe about Randy, he
is NOT delibrately trying to deceive anyone...if there is any
deception there at all - and there simply isn't - then it must be
because _he_ has, in fact, fallen for his own illusions...
*)
Beth. Its human. I could maybe happen to anyone.
>
> Beth ;)
>
>
The Half A Wannabee
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:g3MOb.108$%8....@newsfep3-gui.server.ntli.net...
> Betov wrote:
> > Beth wrote:
(*
Do you understand what I'm saying? There is a world of difference
between, say, Randy believing genuinely that he's helping beginners
and helping to promote assembly...but, oops, he might have made a
mistake about how to go about it...if there is a mistake - which I
don't believe for a second - then it is _entirely_ an "honest mistake"
and nothing more...no attempt at deception at all...
*(
Self-deception
>
> Beth ;)
>
>
The Half A Wannabee
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:g3MOb.108$%8....@newsfep3-gui.server.ntli.net...
> Betov wrote:
> > Beth wrote:
(*
In fact, you had to constantly push him over and over for _years_ just
to make him bite and actually say something _bad_ about RosAsm...he
resisted all that time because he had no intention originally of
wanting to bad mouth _any_ programmer who was working towards
_promoting assembly_ - just like he was and is trying to do - even if
he didn't personally believe in your "methods" of doing it at
all...but if there was _someone_ out there who liked what you were
doing and this helped with the overall promotion of _assembly
language_ - whichever one that is - then that was all to the good...I
told him sincerely that I was amazed at his patience with you with
unjustified assault after unjustified assault..."the patience of a
saint", indeed...which only really goes to show how much of a pest you
really can be that you could even test the patience of a saint and
find it lacking...
*)
Yes Randy is a saint. And Betov is Jesus. And I am God.
I command you all, all of you. You too God. To Shut up.
Or at least to stop theese endless threads of HLA vs RosAsm.
Randy should take his brillance into the field of writing a real assmebler.
lol.
Come toogether.......
> Beth ;)
>
>
Betov
8....@newsfep3-gui.server.ntli.net:
>> Beth wrote:
>> You will excuse me if i miss-understood the question, because i am
> very
>> tired, to-night.
>>
>> If you ask about, where the Data are, in a PE file compiled with
>> RosAsm,... well,... there are, _evidently_ at the place you wrote
> them in
>> your Source.
>
> Yes; But where are my "titles" with regards to the source?
The TITLEs are where you write them in your Source.
>> I don't understand the relationshiop you are doing between this
> problem
>> and the TITLE feature. The Assembler don't care of any concept like
> the
>> TITLE one, as all of such things are ripped off, just like Comments
> are.
>>
>> (By the way, i did a design error with this implemention, i sould
> have
>> implemented it the same way i recently implemented the "Tag
> Comment"s
>> feture, that is... under the form of TITLE _Comment_:
>>
>> ; TITLE Part1
>>
>> ... Too late,... too bad ;)
>>
>> The File RosAsm compiles is the one you can see on your Disk when
>> depressing [Ctrl][S] and selecting the [Save whole Source] Button,
> in
>> case of enTITLed Source.
>
> Yes; But shouldn't you actually _specify_ how it works?
Specify what?, to who?, what for? If you mean a complete
description of the internals of the Editor about how it
efectively manages the TITLEs, i have some other things
to do, and you have the Source.
> After all,
> doesn't do so mandate that you must use a _different_ editor? You
> can't tell from within RosAsm itself and you must use other tools to
> answer your questions?
>
> Oh, alright...you seem to think this is "great" and everything...I'll
> leave you to your "terrible illusion"...
Well, i not sure i understand a word in this, but if
you mean to get back to this old debate about RosAsm
being 'closed' and 'forcing' the user to use the
Sources Editor, all i can answer is that this debate
is several years old, and that since some long time
i have no more such requests from users, as long as
they perfectely understand all the advantages coming
with this technical choice. They all seem now very
happy with the unic features set of this Editor, saving
about one half of their Dev. time.
___________________________
For your other remarks, you are just on the wrong side
of the line, and i only hope that, some day, your eyes
will give you access to facts. For now, I am tired of
having to read no end delirium defending Master Pdf and
HLA, this is to say, "things" that can not be defended,
in any way.
If you do not understand what master Pdf is and does,
... not my fault. I do my best for explaining this.
If you do not understand what HLA is, it is only really
sad, _for you_. Not for me. It will become sad for others
the day -if ever...- you will write some significative
App with that packet of shit. Your first "Demonstration
that HLA was "Assembly able""" was, by principle, funny
enough for not hurting anyone but yourself.
Betov.
< http://betov.free.fr/RosAsm.html >
The Half A Wannabee
"Beth" <BethS...@hotmail.NOSPICEDHAM.com> wrote in message
news:g3MOb.108$%8....@newsfep3-gui.server.ntli.net...
> Betov wrote:
> > Beth wrote:
(*
I leave it up to you...if there's not even a partial or modicum of
retraction on this position...or a sign of regret at considering
it...then, fine...I shall endeavour to ensure that you reap exactly -
pound for pound - what you sow...of course, in my own little "poetic
justice" way because I never was much of a believer in Mosaic
law...there are many ways to win a battle and I can, at your request,
show you every single one in turn until you get the Message...
*)
Hey Beth. What are you on about girl? Are you jeaous on Betov on behalfe of
Randall ?
Are you waging war, on behalfe of Randalls ego ? RosAsm is evidently a very
decent work.
It has some minor flaws, mostly in the looks. But it is true to its
philosofy and please list all the
assmeblers that come with 2 megabytes of autoassemblable source code.
Look at what Spasm can become. Look at what will be the end focus of OOP.
Cut through the BS.
Bytes are bytes. Format are format. Creating new formats are where the fun
is Spasm forces you to work and be creative. you will not fall in love with
programming if you have everything solved out for you at the outset. And you
cant. Okey so HLA is an assembler. Its not an assmebler I would even
consider at this stage.
Its evident that Randall is an ego tripper.
Beth, Betov gives you the truth. Plain & simple. Sometimes it might hurt
those with an egoinvestment in what they have done, what they are used to
think. I too have much of an ego, and it will be a hammer to hurt yourself
with until you realize that that is not the way to go about things really.
> Beth ;)
>
>
The Half A Wannabee
> Betov wrote:
Why Beth do you insist on dicourage the ReactOS team with sayings like
"....and even if the slim possibility of ReactOS
finally showing up happens.."
Why wouldnt you want for it to show up ?
> Beth :)
>
>
Betov
@newsreader1.utanet.at:
> Not to pick on your distribution strategy,
> [even it looks like you are on a holy mission :) ]
> but whenever you answer a newbe-question with "go Webster's",
> all non-HLA fans leaded by Rene will start again the regular
> repeated and already boring discussion.
> And as a side-effect the newbe will flee 'this ASM scene' AOI.
>
It's a very long time i am also bored of it,
Wolfgang. What can we do else? Let it go? Let
99% of beginners fall into the trap? Let Master
Pdf definitively destroy Assembly, because this
is the only way he found to keep his ridicoulous
personal glory alive?
On my side, i consider that, trying to "limit"
the disaster, is an everyday necessary work, that
i will go on doing again and again, up to the day
i will be in political situation of promoting a
real Tool. Things will be much more easy and
pleasant, at that time.
Betov.
< http://betov.free.fr/RosAsm.html >
The Half A Wannabee
> Randy wrote:
> > Annie wrote:
Love,
The Half A Wannabee.
PS : Its boundless ....of course...not really...cant include the people you
disagree with of course. Then you end up in h(e)ll.
> Beth :)
Betov
@newsfep3-gui.server.ntli.net:
> Betov wrote:
>> I am not working for ethical-free guys wanting an Assembler for
>> programming under windows.
>
> Right, so 100% "public domain" is "unethical"...and it's a "Windows
> assembler", despite running equally well on Linux with full standard
> library support for it...
>
> And your assembler is "ethical" because you're filling it with, in
> your own words, "terrible illusions" to willfuly _deceive_ people into
> believing it is something it isn't (and you've also displayed that you
> have no idea about any of the principles or ramifications of the GPL
> licence you carry)...and your assembler isn't a "Windows assembler",
> despite the fact that it can only actually run on Microsoft Windows
> and has the _Microsoft Win32 API_ hard-coded into it, producing _ONLY_
> Microsoft PE files (and even if the slim possibility of ReactOS
> finally showing up happens, it does NOT in any way break the tie that
> this is a _Microsoft specific_ assembler with support directly for
> _Microsoft designs and API_ using a _Microsoft originated_ file
> format...and, by this, you mean to "rid the world of Microsoft"? And
> what turns this into the ultimate joke is you seem to have absolutely
> no idea how ludicrous that really is in the cold light of day)...
:)) You are just providing the very perfect example
of propaganda, i was pointing, to in:
>>I am not working for ethical-free guys wanting an
>>Assembler for programming under windows. And, as
>>long as ReactOS is not yet usable, for at least,
>>a simple Auto-Compilation, i can answer nothing to
>>injuries ...
Thanks for helping at making it so clear.
Betov.