Beginners and All That Are New To Assembly Language - Read This
Joel Davison
Language should avoid using any product that comes from someone with
such unprofessional manners, and that uses such vulgar and offensive
language in a public forum, as in the following examples.
The offensive words have been altered with the asterisk symbol (*).
*********************************************
Betov wrote:
...as an answer, to any of his selling sh*t.
Betov wrote:
...attract more beginners than your megas
of boring bullsh*ts.
Betov wrote:
Not considering the task of kicking the big
fat *ss...
Betov wrote:
...and even less to provide publicly the real
evidences to such stinking b*stards...
Betov wrote:
... the same kind of beasts f*ck together.
Betov wrote:
My 'ma told me, i could get f*cked.
Betov wrote:
...nobody cares of your bulls*ts.
Betov wrote:
...your future un-answered bullsh*ts.
*********************************************
These are but a few examples of the type of foul language used by this
person.
Beginners at Assembly Language should avoid using anything produced by
this person, that shows such a high disregard for others in this public
forum, with his extremely low moral standard, and his highly
unprofessional display of character.
Julienne Walker
> Beginners at Assembly Language should avoid using anything produced by
> this person, that shows such a high disregard for others in this public
> forum, with his extremely low moral standard, and his highly
> unprofessional display of character.
Ignoring proficiency with English and charisma, you and Rene don't
seem that different. I would rather let beginners choose which tool
works best for them than try to drive their education with my personal
biases.
rh...@cs.ucr.edu
>
> Beginners at Assembly Language should avoid using anything produced by
> this person, that shows such a high disregard for others in this public
> forum, with his extremely low moral standard, and his highly
> unprofessional display of character.
I wouldn't worry too much about beginners accidentally using RosAsm.
Rene has a habit of telling people who ask beginning questions what
"idiots" they are and he drives them away. As for his new set of
tutorials (hey, he's finally taking my advice after all these years
and creating a set-- have to give him credit for that), you should try
walking through a few of them. If you can momentarily suspend any
knowledge of assembly language programming you possess, you'll quickly
discover that beginners will find those tutorials to be of very little
value.
The bottom line is that if you *really* want people to avoid Rene and
RosAsm, just let him do his thing around here. He's more than capable
of driving any possible supporters away. And the few people who think
he's cool (e.g., "wannabee"/"Eric") are more than welcome to go the
RosAsm route.
hLater,
Randy Hyde
sevag.krikorian
> Language should avoid using any product that comes from someone with
> such unprofessional manners, and that uses such vulgar and offensive
> language in a public forum, as in the following examples.
>
> The offensive words have been altered with the asterisk symbol (*).
> *********************************************
>
It's amazing how this clown can be civil if he is forced to be by a
more mature individual.
-sevag.k
www.geocities.com/kahlinor
Joel Davison
I'm wondering if you held much the same view when calls to boycott the
Imus Show on MSNBC were being made recently.
I can assure you, there is no "personal bias" involved here. This is all
about maintaining a level of decorum, and of common courtesy and decency
while in a public place.
By not taking a stand against Betov's indecent use of language and his
unprofessional demeanor, you are in effect condoning his behavior, and
handing him your stamp of approval. There is no middle ground here, no
sitting on the fence. You either approve or disapprove of it.
rh...@cs.ucr.edu
>
> By not taking a stand against Betov's indecent use of language and his
> unprofessional demeanor, you are in effect condoning his behavior, and
> handing him your stamp of approval. There is no middle ground here, no
> sitting on the fence. You either approve or disapprove of it.
IIRC, it was Julilenne who told Rene that no one would take him
serious if he continued to call me "asshole" all the time, which is
why Rene now calls me "clown". Of course, I think it went right over
his head that she was really complaining about name calling in
general, and profanity only specifically.
hLater,
Randy Hyde
Julienne Walker
> Julienne Walker wrote:
> > On Jun 18, 1:48 pm, Joel Davison <J...@hip.net> wrote:
> >> Beginners at Assembly Language should avoid using anything produced by
> >> this person, that shows such a high disregard for others in this public
> >> forum, with his extremely low moral standard, and his highly
> >> unprofessional display of character.
>
> > Ignoring proficiency with English and charisma, you and Rene don't
> > seem that different. I would rather let beginners choose which tool
> > works best for them than try to drive their education with my personal
> > biases.
>
> I'm wondering if you held much the same view when calls to boycott the
> Imus Show on MSNBC were being made recently.
Sadly, I have no idea what you're talking about, so I can't confirm or
deny it.
> I can assure you, there is no "personal bias" involved here. This is all
> about maintaining a level of decorum, and of common courtesy and decency
> while in a public place.
I'm sorry, it really seemed like you were saying "Don't use RosAsm
because I don't like Rene". Supporting the tool and supporting the
behavior of its author are two different things. For example, there
are people who despise Richard Stallman but still support GNU.
> By not taking a stand against Betov's indecent use of language and his
> unprofessional demeanor, you are in effect condoning his behavior, and
> handing him your stamp of approval. There is no middle ground here, no
> sitting on the fence. You either approve or disapprove of it.
http://en.wikipedia.org/wiki/False_dilemma
You're also using Rene's behavior as an excuse to attack RosAsm, which
strikes me as childish. If you really have a problem with his
behavior, there are better ways of solving it than trying to convince
us that by boycotting RosAsm, Rene will immediately see the connection
and change his ways.
Besides, if you really want to attack RosAsm, it's not lacking in
flaws. You don't need to take such a roundabout route.
Jim Carlock
: By not taking a stand against Betov's indecent use of language and his
: unprofessional demeanor, you are in effect condoning his behavior,
: and handing him your stamp of approval.
That ends up false and/or untrue sometimes. For those that seek attention,
even providing negative attention, you support that attention seeking and
satisfy them. There is no requirement to stand. Most people prefer to sit
at the computer and type. :-)
: There is no middle ground here, no sitting on the fence. You either
: approve or disapprove of it.
Where is the ground? Where is the fence? How does a fence or ground
relate to the subject at hand? And even if there was a fence to sit upon,
sometimes it's better to sit and watch the sunrise and pay attention to
what's really happening than to pay attention to the attention folks seek.
It's easy to spot those that are attention seekers, as they run around
repetitiously calling others names.
It sometimes ends up better to listen (and ignore what needs to get ignored)
than to actively engage and support things with a negative response.
It ends up easier to put down those you disrespect, than it does to
encourage, enlighten, entertain and show respect to them.
Now, where's the content for those beginners?
Somethings that deal with macros will help beginners.
Somethings that deal with certain assembly language concepts helps
beginners, like developing an INVOKE macro to pass parameters
around.
And there's not much out there in the way of teaching macros (or
perhaps I just missed out on it all). I think that's probably one of
the least understood concepts in assembly language. I speak for
myself. I don't have a book on the subject and the books I do have
do not deal with the topic.
So perhaps we can get a discussion going here on some simple
macros, some examples that encourage others to use macros,
examples which entertain the mind, and examples that enlighten?
--
Jim Carlock
Wolfgang Kern
[... Betov vs. RosAsm ...]
I almost agree with Julienne.
Yes, Rene is often an impolite and rude old french hog :)
But if you ever read news:alt.os.linux you'll find more nasty
words than posted lines.
So compared to this Rene sounds very civil and handsome.
But I'd miss the hidden humour which is often found in abusive
speach (OK, the sense of humour may depend on ones aspect).
About Rene's attacks on Randy ...
I would need long sentences to describe my thoughts on Mr.Hide's
limited view of the universe without being impolite ...
... short words often express things more doubtfree :)
RosAsm is a matter of taste like any other tool.
Even windoze coding is a very rare opportunity in my business, I
personally find it really usefull for windoze asm-coding, because
it got an integrated debugger and is a single window tool without
the need for separated link/make/compile/run/debug steps.
And it allowes me to type in my prefered 'skeleton' style as well.
__
wolfgang
rh...@cs.ucr.edu
>
> And there's not much out there in the way of teaching macros (or
> perhaps I just missed out on it all). I think that's probably one of
> the least understood concepts in assembly language. I speak for
> myself. I don't have a book on the subject and the books I do have
> do not deal with the topic.
One of the coolest books ever written on assembly language was "Macro
Magic" that demonstrated how to do some really neat things with TASM
(MASM) macros. If you can find a copy of this (10 years out of print)
book somewhere, I would snap one up.
Of course, it's not suitable for beginners, but if you already know
assembly language it's a great book to get.
> So perhaps we can get a discussion going here on some simple
> macros, some examples that encourage others to use macros,
> examples which entertain the mind, and examples that enlighten?
Well, let's see. You post code using a macro invocation like
"stdout.put" and people start hollering about how it's a "high-level
language". It is no wonder that so few people are interested in
posting macro examples around here.
I *have* done this over the past several years. Take a look at the
"STL" macros I posted to this newsgroup a while back. Look at the
"lookup table" macros I posted before that. Granted, these are pretty
advanced macros, but if beginning macros are what you're interested in
reading about, there are a couple of chapters on the subject in "The
Art of Assembly Language".
hLater,
Randy Hyde
rh...@cs.ucr.edu
>
> RosAsm is a matter of taste like any other tool.
> Even windoze coding is a very rare opportunity in my business, I
> personally find it really usefull for windoze asm-coding, because
> it got an integrated debugger and is a single window tool without
> the need for separated link/make/compile/run/debug steps.
> And it allowes me to type in my prefered 'skeleton' style as well.
So, because you have *very limited and narrow requirements* for an
assembler (Windows or otherwise), you're an expert on how assembly
language ought to be taught to beginners? Don't get me wrong, RosAsm
may be the *perfect* Windows programming tool for you -- that doesn't
mean it's the perfect tool, or even a suitable tool, for anyone else.
In the "I want to learn or use assembly language" marketplace, RosAsm
has been a complete failure. The #1 (technical) reason of course, is
RosAsm inability to handle linking of object files. That feature you
find so valuable (not having to go through the linking phase) is a
defect so bad that only a tiny number of programmers would ever give
RosAsm a second thought. This fact alone should tell you that you are
a little out of sync with the rest of the world's programming
community and should provide a small clue that whatever opinions you
hold on how they ought to be taught assembly language need to be taken
with a grain of salt.
hLater,
Randy Hyde
Betov
news:1182261079.1...@x35g2000prf.googlegroups.com:
> This fact alone should tell you that you are
> a little out of sync with the rest of the world's programming
> community
Clown, if you had any knowledge of Assembly, you would also be
completely "out of sync with the rest of the world's programming
community". Given the number of nerds around, this is quite an
honour to be "out of sync".
:)
Betov.
Wolfgang Kern
"Betov" écrivait:
>> This fact alone should tell you that you are
>> a little out of sync with the rest of the world's programming
>> community
> Clown, if you had any knowledge of Assembly, you would also be
> completely "out of sync with the rest of the world's programming
> community". Given the number of nerds around, this is quite an
> honour to be "out of sync".
>
> :)
Indeed, but Randy always talk about teaching "assembly language",
but self-thinking newbies want to learn 'assembly programming'
(for Randy: this is the instruction-set and how a PC works, and
not compiler directives, macros and libs copied from C).
__
wolfgang
kistj...@excite.com
This may seem counter to the typical traditionalists' (or should I say
fundamentalists') asm'ers view, but AoA expects one to be able to do
full-fletched low-level coding by the end of the book.
Betov
@newsreader2.utanet.at:
> Randy always talk about teaching "assembly language",
> but self-thinking newbies want to learn 'assembly programming'
Yes, this is part of his propaganda system. I don't know if
we should consider this hillarous or pathetic, but it seems
that some beginners:
1) Really believe that he would be a teacher.
2) Really believe that, if he would be teacher, he should know
something about Assembly, even though it is more than proven
that teachers do not know a thing about Assembly, each time
we see any exercise, they give to their studients.
Well... as long as the good old trick works...
That being said, yes, there is a _HUGE_ difference in between
pedagogic materials, that would be designed to "teach", and
materials that would be designed to _learn_. Effectively, and
absolutely, no relationship, in between a guy who is forced to
pass through a diploma, and a guy who wants to learn something:
When my cat wants to eat something, she understands everything.
:)
Betov.
rh...@cs.ucr.edu
>
> Indeed, but Randy always talk about teaching "assembly language",
> but self-thinking newbies want to learn 'assembly programming'
> (for Randy: this is the instruction-set and how a PC works, and
> not compiler directives, macros and libs copied from C).
Yes, wolfgang, I realize that *you* think that "assembly language
programming" means knowing what the instruction set is and how a PC
works. However, the vast majority of people out there don't share your
opinion on this. The them, "programming" means solving problems with a
computer language. And it takes a little more knowledge about things
like data structures and algorithms to be able to accomplish this. The
fact that you've never risen above the level of a self-taught
electrical engineer/hacker assembly programmer is probably the main
reason you don't understand why people really like the way AoA teaches
assembly language. Like Rene, you constantly delude yourself with the
rationalization of "Mr. Hyde is swindling people." The truth is,
however, that you (and Rene) can't handle the fact that most people
*don't* subscribe to your pedagogical menthods. Rather than accepting
the fact that you are simply wrong about how assembly language ought
to be taught, you start making up stories like "libs copied from C".
Grow up. Admit you're mistaken and move on. You only make yourself
look foolish by criticizing all the people (here and elsewhere) that
*are* successfully learning assembly language using AoA. Their
programming methods may not have *your* stamp of approval, but I don't
recall them asking you for it.
hLater,
Randy Hyde
rh...@cs.ucr.edu
> "Wolfgang Kern" <nowh...@nevernet.at> écrivait news:f58qup$pct$2
> @newsreader2.utanet.at:
>
> > Randy always talk about teaching "assembly language",
> > but self-thinking newbies want to learn 'assembly programming'
>
> Yes, this is part of his propaganda system. I don't know if
> we should consider this hillarous or pathetic, but it seems
> that some beginners:
>
> 1) Really believe that he would be a teacher.
Well, when *you* are offering yourself up as the alternative, is it
any wonder?
>
> 2) Really believe that, if he would be teacher, he should know
> something about Assembly, even though it is more than proven
> that teachers do not know a thing about Assembly, each time
> we see any exercise, they give to their studients.
I would like to see this proof.
And, as you are now offering *yourself* up as a teacher, I guess that
this proof suggests that you don't know a thing about assembly, eh?
>
> Well... as long as the good old trick works...
Amazing, isn't it. It's an *old* trick and it keeps on working and
working and working. Keep telling yourself it's a trick. You might
even convince yourself it is true. But until *you* have managed to
train a few thousand people how to program in assembly language and
can demonstrate that their knowledge is superior to the "tricked
students" I've taught over the years, you're standing on very shaky
ground. It's real easy for you to criticize AoA. That only takes a few
words. The *real* work is providing an alternative to AoA. One that
becomes as universally accepted as the standard. I encourage you to
try, because the AoA approach is designed for a typical student, not
*every* student, and having a few alternatives, no matter how far off
the beaten path, is always a good thing. However, from the looks of
your "12 tutorials" thus far, it's pretty clear that whatever assembly
language knowledge you feel you possess, you don't have a clue about
how to teach people that knowledge.
>
> That being said, yes, there is a _HUGE_ difference in between
> pedagogic materials, that would be designed to "teach", and
> materials that would be designed to _learn_.
You really don't know anything about teaching, so your proclamations
as though you were some authority on the subject are truly ridiculous.
BTW, teachers *teach* and student's *learn*. If you're relying on the
student's abilities to "learn" your materials, that's an admission
that they're not very good.
> Effectively, and
> absolutely, no relationship, in between a guy who is forced to
> pass through a diploma, and a guy who wants to learn something:
No question about it. However, if your teaching materials can interest
the disinterested and actually teach them something, that's a *good*
thing. A student who is bound and determined to learn a subject will
succeed no matter how bad the pedagogical materials are. If you're
depending on good students for your materials to be successful, that's
an admission that your materials are not very good. As any instructor
will tell you, the pedagogical materials must be aimed at the average/
typical student in order to have the maximum impact. Aiming your
materials at the best students is a waste of time -- they will learn
the subject regardless.
>
> When my cat wants to eat something, she understands everything.
I'm sure. So go feed your cat. You're probably far better qualified to
do that than discuss how students ought to be taught assembly
language.
hLater,
Randy Hyde
Betov
news:1182270030.4...@g4g2000hsf.googlegroups.com:
> you are now offering *yourself* up as a teacher
:))
Where did i say that i was the author of The Twelve Assembly
Lessons, clown? My job is just to manage the proof-readings,
the ports to the national languages, and the distribution.
For the name of the author, it is: Anonymous.
:)
Betov.
rh...@cs.ucr.edu
> "r...@cs.ucr.edu" <r...@cs.ucr.edu> écrivaitnews:1182270030.4...@g4g2000hsf.googlegroups.com:
>
> > you are now offering *yourself* up as a teacher
>
> :))
>
> Where did i say that i was the author of The Twelve Assembly
> Lessons, clown? My job is just to manage the proof-readings,
> the ports to the national languages, and the distribution.
>
> For the name of the author, it is: Anonymous.
You are selling yourself and your product. Period. Whether you are the
author or not, you are selling yourself and your pedagogy through this
system. Whether or not anyone actually *buys* into your "Lessons",
you're selling yourself with them. If you're too chicken to admit that
you wrote this, that's fine. If the people who wrote it are too
ashamed to put their name on it, just keep in mind that *you* are the
one being held responsible for it. Yes, you are selling *yourself*
with these tutorials.
hLater,
Randy Hyde
Betov
news:1182273959.1...@x35g2000prf.googlegroups.com:
> You are selling yourself and your product
Given my way of life, and given the number of years, i hope
to live along, this would be a very funny thing, clown. The
only problem is... how much?
:]]]]]]]]
Betov.
rh...@cs.ucr.edu
> "r...@cs.ucr.edu" <r...@cs.ucr.edu> écrivaitnews:1182273959.1...@x35g2000prf.googlegroups.com:
>
> Given my way of life, and given the number of years, i hope
> to live along, this would be a very funny thing, clown. The
> only problem is... how much?
It's not the amount, just the fact that you've been so hypocritical
complaining about other's "selling themselves" when, in fact, it's
been you selling yourself all along.
hLater,
Randy Hyde
Betov
news:1182277857.8...@z28g2000prd.googlegroups.com:
> It's not the amount, just the fact that you've been so hypocritical
> complaining about other's "selling themselves" when, in fact, it's
> been you selling yourself all along.
Well, i perfectly understand that the only thing you could make
a living from, is your reputation, clown. And quite frankly, i
would not much care about that, if only you were not artificialy
creating this reputation by stealing other works, parroting others'
idea, denigrating others efforts, and missleading the beginners
with your vicious propaganda.
On my side, i have enough money for the rest of my life, that
i have earned the regular way, by buiding quantities of houses
with my hands, my knowlegde, and my past physical capacities, in
matter of houses building competencies. In matter of reputation,
i do not think that anybody ever saw me walking in the streets,
with a T-shirt on which it would be written:
"Hey, people! I am the famous main maintainer of RosAsm".
:)
And you know what? Clown? The day will will both die, your fucky
god will push your big bat ass on the left side, while i will be
pissing on the right side of his white barb:
Yes, clown, death is as crual as life is.
:))
Betov.
rh...@cs.ucr.edu
> "r...@cs.ucr.edu" <r...@cs.ucr.edu> écrivaitnews:1182277857.8...@z28g2000prd.googlegroups.com:
>
> > It's not the amount, just the fact that you've been so hypocritical
> > complaining about other's "selling themselves" when, in fact, it's
> > been you selling yourself all along.
>
> Well, i perfectly understand that the only thing you could make
> a living from, is your reputation, clown.
Funny, I don't recall ever getting a paycheck made out to my
reputation. Perhaps you're confused and think that I make a living
writing books. Ha! Anyone who has published books in the computer
field can tell you that you won't make a decent living writing
computer books (particularly on obscure subjects like assembly
language).
> And quite frankly, i
> would not much care about that, if only you were not artificialy
> creating this reputation by stealing other works,
Said by the guy who publishes his tutorials by "Anonymous" so he
doesn't have to give credit to the person who wrote them.
> parroting others'
> idea,
Hmmm...
HLA was definitely someone else's idea. :-)
> denigrating others efforts,
You seem to be the one doing that.
> and missleading the beginners
> with your vicious propaganda.
Just because *you* can't attract any beginners, for whatever reason,
doesn't mean that I am misleading them. People are not flocking to
your products and your tutorials for two main reasons:
1. You are incredibly rude,
2. Your products are very good.
>
> On my side, i have enough money for the rest of my life, that
> i have earned the regular way, by buiding quantities of houses
> with my hands, my knowlegde, and my past physical capacities, in
> matter of houses building competencies.
So, because you've built houses, you feel you are competent to teach
people assembly language? You think you are competent to write
software? You think you are an expert on what is and what is not an
"assembler"? You feel you have the authority to speak for "assembly
language programmers?" Wow. Maybe I should have become a carpenter
rather than going to school all those years and getting my Master's
degree in computer science. Maybe I should have become a carpenter
rather than spending the last 30 years of my life working in embedded
systems (mostly in assembly language). Maybe I should have become a
carpenter rather than teaching assembly language for 11 years of my
life. Maybe I should have become a carpenter rather than wasting all
that time writing books on assembly language and other subjects. Thank
you Rene, you've turned on the lights. I see where I've gone wrong all
these years. :-)
> In matter of reputation,
> i do not think that anybody ever saw me walking in the streets,
> with a T-shirt on which it would be written:
>
> "Hey, people! I am the famous main maintainer of RosAsm".
No, but we have seen you make lots of posts to this very newsgroup
which effectively said that.
>
> And you know what? Clown? The day will will both die, your fucky
> god will push your big bat ass on the left side, while i will be
> pissing on the right side of his white barb:
I guess you will have to take up that issue with "My God" the day you
die, eh?
hLater,
Randy Hyde
Betov
news:1182284650.1...@i13g2000prf.googlegroups.com:
> Funny, I don't recall ever getting a paycheck made out to my
> reputation. Perhaps you're confused and think that I make a living
> writing books
No clown. I know that publishing restricted distribution books,
does not make significative incomes. I also know that, if you
had not usurpated your reputation, you would never be hired by
anyone.
Betov.
rh...@cs.ucr.edu
> "r...@cs.ucr.edu" <r...@cs.ucr.edu> écrivaitnews:1182284650.1...@i13g2000prf.googlegroups.com:
>
> > Funny, I don't recall ever getting a paycheck made out to my
> > reputation. Perhaps you're confused and think that I make a living
> > writing books
>
> No clown. I know that publishing restricted distribution books,
> does not make significative incomes. I also know that, if you
> had not usurpated your reputation, you would never be hired by
> anyone.
Actually, I can't think of a single firm that has ever hired me
because I wrote a book on assembly language programming. Indeed, for
the past seven years or so, most of the places I've worked have
probably considered my work in the assembly language area to be a
drawback because they've wanted most of their code written in C/C++ or
some other HLL. The last thing they want is code written in assembly
language that someone else will have to maintain after I leave the
project. If I wanted to leverage my published works to get a job, I
certainly *wouldn't* be writing books on assembly language
programming. I'd be concentrating on traditional HLLs, instead. That
would be more lucrative (in terms of book sales) and would be far
better for my "reputation" when it comes time to seek another job or
contract.
Suppose, for example, you wrote a book on how to build houses using
techniques that are not acceptable to modern architects. How much of a
"reputation boost" do you think you would get from that? The same is
true for someone writing books on assembly language these days. I
happen to get hired *in spite* of that because the people have looked
at my resume and seen my accomplishments over the years. It's those
accomplishments that have gotten me hired, not Rene Tournois' concerns
about my "reputation".
And you will notice one thing: I've actually gotten *hired* to write
code. And I've been relatively successful at this over the past 30
years or so. IIRC, you failed miserably at it back in the 60's and
went into carpentry because you couldn't handle being a programmer. It
is no wonder you are so jealous of the small successes I've had;
you've failed in this field.
hLater,
Randy Hyde
Wolfgang Kern
kistjebier wrote:
>> ... but Randy always talk about teaching "assembly language",
>> but self-thinking newbies want to learn 'assembly programming'
>> (for Randy: this is the instruction-set and how a PC works, and
>> not compiler directives, macros and libs copied from C).
> This may seem counter to the typical traditionalists' (or should I say
> fundamentalists') asm'ers view, but AoA expects one to be able to do
> full-fletched low-level coding by the end of the book.
Whatever 'full-fletched' may mean, low level programming
(in the literal sense and not 'just a bit below C') is extremely
CPU specific and need detailed study of the CPU-manuals.
AoA might be enough to help CS-students through their examina,
but I (and many others as well) wouldn't hire an ASM-programmer
who only finished AoA reading and a short course on university.
theory vs. practice, ... guess who get the job ...
__
wolfgang
Frank Kotler
...
> 1. You are incredibly rude,
> 2. Your products are very good.
A sure sign you're going too fast, Randy! :)
In any case, the "goodness" or "not" of RosAsm has little to do with the
fact that Betov frequently emits an unpleasant noise. Unfortunately, in
the "real world", #1 reflects badly on #2... a pity, IMO.
Best,
Frank
hutch--
allowing that he is not a native English speaker, like everything else
in ALA, who gives a PHUK.
Evenbit
>From the subject: "Beginners and All That Are New To Assembly
Language - Read This"
By my count, I've become the eleventh poster to this thread, so we can
make a reasonable assumption that your message got through to *an*
audience. Could we further assume that we {posters} represent the
_intended_ audience?? ;)
Nathan.
Evenbit
>
> You're also using Rene's behavior as an excuse to attack RosAsm, which
> strikes me as childish.
"attack RosAsm"??? Come on... why would anyone want to do that?? :)
Oh, a few reasons:
o It is innovative
o Combines assembler + disassember/debugger + IDE into one package
o Breaks with established norms about UI editing/navigation
standards
o Encourages a non-traditional application building philosophy
--------------------------------------------
CONCLUSION: RosAsm pushes the envelope (and a lot of people's
buttons)
Why would anyone want to attack HLA??
Just one reason:
o It is true to it's name: "High Level"
Nathan.
BWIGLEY
news:1182312180.4...@k79g2000hse.googlegroups.com...
And I'm sure that people like me, the so-called intended audience
aren't getting anything at all out of this thread.
Wolfgang Kern
"Evenbit" wrote:
>
> >From the subject: "Beginners and All That Are New To Assembly
> Language - Read This"
>
> By my count, I've become the eleventh poster to this thread, so we can
> make a reasonable assumption that your message got through to *an*
> audience. Could we further assume that we {posters} represent the
> _intended_ audience?? ;)
No Nathan.
We aren't the addressed horde of newbies, I'm afraid.
__
wolfgang
rh...@cs.ucr.edu
>
> Whatever 'full-fletched' may mean, low level programming
> (in the literal sense and not 'just a bit below C') is extremely
> CPU specific and need detailed study of the CPU-manuals.
What makes you think that this information is only available in the
CPU manuals? And what makes you think that AoA doesn't contain this
very same material?
>
> AoA might be enough to help CS-students through their examina,
> but I (and many others as well) wouldn't hire an ASM-programmer
> who only finished AoA reading and a short course on university.
You seem to have a lot of opinions about AoA, that were obviously
developed without actually *reading* the book through.
>
> theory vs. practice, ... guess who get the job ...
Informed vs. uninformed opinion, ... guess who gets the job.
Next time you want to act as an authority on what AoA does and does
not teach, you should first read the book *through* so you know what
you're talking about.
hLater,
Randy Hyde
rh...@cs.ucr.edu
>
> Why would anyone want to attack HLA??
>
> Just one reason:
>
> o It is true to it's name: "High Level"
I agree 100%. Except you left out part of the name: "Assembler".
hLater,
Randy Hyde
Nathan.
Julienne Walker
> On Jun 18, 8:50 pm, Julienne Walker <happyfro...@hotmail.com> wrote:
>
>
>
> > You're also using Rene's behavior as an excuse to attack RosAsm, which
> > strikes me as childish.
>
> "attack RosAsm"??? Come on... why would anyone want to do that?? :)
>
> Oh, a few reasons:
>
> o It is innovative
I don't see anything in RosAsm that I would call innovative.
Different, perhaps, but not innovative.
> o Combines assembler + disassember/debugger + IDE into one package
This, is one of the nice features of RosAsm. However, I rather dislike
the fact that if I hate the IDE, I can't plug the assembler
+disassembler/debugger into another one. If I want a more conventional
IDE, I'd have to reimplement RosAsm. I simply don't have that kind of
free time.
> o Breaks with established norms about UI editing/navigation
> standards
That's generally viewed as a bad thing. Unconventional interfaces are
harder to learn and stand out like warts. I'm sure Rene thinks his
design is superior to conventional interface design, but I find it
awkward.
> o Encourages a non-traditional application building philosophy
On the contrary, RosAsm encourages a very traditional application
building philosophy:
1) Everything must be written in assembly
2) Code reuse is accomplished with cut and paste
It's like a time warp back to the 1960s.
> --------------------------------------------
> CONCLUSION: RosAsm pushes the envelope (and a lot of people's
> buttons)
We're scientists. We want hypotheses, objective tests, and hard
numbers. Rene has provided none of these to show that RosAsm is as
good as he claims. As a software developer, I think that RosAsm as a
whole is an immature product. As a programmer who dabbles in language
design, I think that RosAsm as an assembly language has promise. As a
compiler writer, I think that Rene is blowing a lot of smoke about
these so called innovations.
But that's just me. I'm primarily a C programmer, so my opinion
doesn't weigh heavily in Rene's mind.
> Why would anyone want to attack HLA??
I can think of quite a few reasons. But since my comment had nothing
to do with HLA, I'm wondering why you even felt the need to bring it
up. It seems like HLA and RosAsm are in some kind of death spiral and
they'll always be associated in the minds of a.l.a. regulars.
> Just one reason:
>
> o It is true to it's name: "High Level"
I have only one requirement for an assembly language: If I can write
assembly instructions and the compiler produces exactly what I wrote
without extra hidden instructions, it's an assembly language.
This means that RosAsm is an assembly language because the only thing
it adds to my code is the PE framework required to create an
executable. It means that inline assembly in C is *not* an assembly
language because it requires the C runtime code. And it means that HLA
*is* an assembly language because I can set up the compiler so that it
doesn't add any of the bookkeeping and helper code that's enabled by
default. The result will be the instructions I wrote without any extra
fat.
As long as the language meets the requirement, it's an assembly
language. It doesn't matter if it also supports higher level features
and enables those features by default. If I can turn them off and meet
the requirement, it's an assembly language. Simple.
> Nathan.
Betov
@q75g2000hsh.googlegroups.com:
> On Jun 18, 8:50 pm, Julienne Walker <happyfro...@hotmail.com> wrote:
>>
>> You're also using Rene's behavior as an excuse to attack RosAsm, which
>> strikes me as childish.
>
> "attack RosAsm"??? Come on... why would anyone want to do that?? :)
>
> Oh, a few reasons:
>
> o It is innovative
Right.
> o Combines assembler + disassember/debugger + IDE into one package
Right.
> o Breaks with established norms about UI editing/navigation
> standards
Wrong. It respects the usual norms, and introduces innovative
methods, that make the developments easier and faster. As long
as features, like the Right-Click moves, which make the reading
and the searches so easy, did not exist, when i invented it, i
fail to imagine what "norm", i could have conformed to.
> o Encourages a non-traditional application building philosophy
Right.
Summary: There is no reason for attacking RosAsm.
> --------------------------------------------
> Why would anyone want to attack HLA??
>
> Just one reason:
Right.
> o It is true to it's name: "High Level"
Wrong. It is the name _Assembler_. No Asmer on earth will ever
accept calling an HLL "Assembler". As an HLL, there is absolutly
no reason for attacking such a product. But selling this as an
_Assembler_ is way over what any Asmer could accept. And when
it come to the level of insanity of selling such a product for
"teaching Assembly to the beginners", it is urgent to arase the
swindler, in order to protect the beginners.
For sure, there is something that does not need to be attacked,
_AT ALL_: This is the beginners group.
Betov.
Betov
news:1182348586.7...@c77g2000hse.googlegroups.com:
> I don't see anything in RosAsm that I would call innovative.
Well, RosAsm is the only Assembler, around, which comes with
a button for coffea and a button for pizza. Of course, i did
not invent pizza nor coffea, but i was the one who innovated
with implementing these in an Assembler.
Betov.
Wolfgang Kern
Jim Higgins wrote:
>>"Evenbit" wrote:
> Nope, we're just the collateral damage.
Perhaps right :)
So what could we try instead ?
LET HLA be a valid ASM? IMHO: No, under no circumstance.
__
wolfgang
Wolfgang Kern
<rhyde answered Evenbit:
>> Why would anyone want to attack HLA??
>> Just one reason:
>> o It is true to it's name: "High Level"
It's purpose seemm to be selling more books ?
> I agree 100%. Except you left out part of the name: "Assembler".
This execption stands valid:
HLA got nothing to do with ASM.
It merely is an poor attempt to ease INLINE asm for C and other HLL-tools
with weird syntax/compiler directives appendizies and nothing else.
__
wolfgang
Wolfgang Kern
Hi Julienne,
I can fully agree with your notes, except I wouldn't count HLA within
available assembler tools (my view: a weird variant of C-inline asm).
__
wolfgang
Wolfgang Kern
rhyde wrote:
>> Whatever 'full-fletched' may mean, low level programming
>> (in the literal sense and not 'just a bit below C') is extremely
>> CPU specific and need detailed study of the CPU-manuals.
> What makes you think that this information is only available in the
> CPU manuals? And what makes you think that AoA doesn't contain this
> very same material?
Show it.
> > AoA might be enough to help CS-students through their examina,
> > but I (and many others as well) wouldn't hire an ASM-programmer
> > who only finished AoA reading and a short course on university.
> You seem to have a lot of opinions about AoA, that were obviously
> developed without actually *reading* the book through.
Right, during reading the first chapter of AoA , I fell asleep on
these useless boring verbose comments ...
>> theory vs. practice, ... guess who get the job ...
> Informed vs. uninformed opinion, ... guess who gets the job.
> Next time you want to act as an authority on what AoA does and does
> not teach, you should first read the book *through* so you know what
> you're talking about.
I can see the result (nothing at all),
so let's count the few who ever read this sh*t until end and then were
encouraged enough to call themself 'assembly programmer'.
Yes Mr. clown (main actor in some christian sketches),
you and all your victims/minions/whatsoverver you may have convinced
with "your" point of view, are lost within logical native coding.
BTW: let the jews make jokes about themself, because their jokes are funny,
in opposition to your attemp of being humorous
(you behave just ridicules, so "clown == true)".
__
wolfgang
rand...@earthlink.net
> rhyde wrote:
> >> Whatever 'full-fletched' may mean, low level programming
> >> (in the literal sense and not 'just a bit below C') is extremely
> >> CPU specific and need detailed study of the CPU-manuals.
> > What makes you think that this information is only available in the
> > CPU manuals? And what makes you think that AoA doesn't contain this
> > very same material?
>
> Show it.
Appendix D.
>
> > > AoA might be enough to help CS-students through their examina,
> > > but I (and many others as well) wouldn't hire an ASM-programmer
> > > who only finished AoA reading and a short course on university.
> > You seem to have a lot of opinions about AoA, that were obviously
> > developed without actually *reading* the book through.
>
> Right, during reading the first chapter of AoA , I fell asleep on
> these useless boring verbose comments ...
Not surprising:
1. You already know assembly.
2. You had a predisposition against the use of HLA.
Unquestionably, AoA isn't perfect for everyone. However, based on its
popularity, I think we can safely assume that it does a pretty good
job of hitting its target audience. You, clearly, are not the target
audience for AoA.
>
> >> theory vs. practice, ... guess who get the job ...
> > Informed vs. uninformed opinion, ... guess who gets the job.
> > Next time you want to act as an authority on what AoA does and does
> > not teach, you should first read the book *through* so you know what
> > you're talking about.
>
> I can see the result (nothing at all),
Yes, you see nothing at all.
Probably because you don't even know where to look, and when an
example is pretty obvious around here (e.g., Sevag), you simply ignore
it.
> so let's count the few who ever read this sh*t until end and then were
> encouraged enough to call themself 'assembly programmer'.
And how many have become encouraged enough to call themselves the same
by doing nothing more than reading the CPU manuals? I'd bet I have
that beat by *at least* an order of magnitude. Probably two orders of
magnitude.
>
> Yes Mr. clown (main actor in some christian sketches),
> you and all your victims/minions/whatsoverver you may have convinced
> with "your" point of view, are lost within logical native coding.
Wow, for a moment there I thought I was responding to Rene. I had to
check the signature line down below just to be sure.
Oh well, all the people are lost to *you*. As for what they do with
their lives, that's really not your choice and not really any of your
business. The real people I need to satisfy are them, not you. So what
makes you think your opinion really matters? If, in their opinion,
they weren't learning assembly language programming using AoA, I think
we'd be hearing a lot about it, don't you? As it is, the only people
around here I see complaining about AoA's effectiveness are people
such as yourself who never read past the first chapter.
>
> BTW: let the jews make jokes about themself, because their jokes are funny,
> in opposition to your attemp of being humorous
> (you behave just ridicules, so "clown == true)".
I guess something got lost in the translation there. This sentence
makes little since in English other than to display a considerable
anti-semetic attitude on your part. It really doesn't help strengthen
whatever argument you're trying to make.
hLater,
Randy Hyde
rand...@earthlink.net
> <rhyde answered Evenbit:
>
> >> Why would anyone want to attack HLA??
> >> Just one reason:
> >> o It is true to it's name: "High Level"
>
> It's purpose seemm to be selling more books ?
Actually, this is quite correct. HLA was developed to support "The Art
of Assembly Language" and make learning assembly language easier for
the reader. Of course, when HLA was created, AoA was available free on
the net and the published edition didn't appear until four years after
HLA first appeared, so "selling" is a bit strong here (as nothing was
being sold, nor was there an expectation that something would be sold,
at the time I developed HLA)>
>
> > I agree 100%. Except you left out part of the name: "Assembler".
>
> This execption stands valid:
> HLA got nothing to do with ASM.
So you and Rene say. Let's even throw Eric (Wannabee) and Herbert in
there for fun. Hmmm... *Four* people think HLA has nothing to do with
assembly. I can live with that.
> It merely is an poor attempt to ease INLINE asm for C and other HLL-tools
> with weird syntax/compiler directives appendizies and nothing else.
You seem to know about as little about HLA as you do about AoA. You
might actually try *learning* it before you make further criticisms.
Otherwise, you just come off sounding ignorant.
hLater,
Randy Hyde
rand...@earthlink.net
Obviously, you know nothing about C and you know nothing about C's in-
line asm capabilities. Certainly, you know nothing about HLA. You come
off sounding very foolish when you attempt to speak with authority
about things you know nothing about.
hLater,
Randy Hyde
rand...@earthlink.net
>
> LET HLA be a valid ASM? IMHO: No, under no circumstance.
And you'd let MASM be a valid assembler?
How about TASM?
Watch out for that slippery slope you're headed down.
hLater,
Randy Hyde
Julienne Walker
If that's your view then you don't agree with me at all. Inline
assembly is basically a compiler feature that lets you embed limited
assembly instructions inside of a higher level language. I can see how
you might apply HLA to that definition, but you also need to consider
that you can't have just inline assembly. It *has* to be embedded in
the higher level language, and you cannot remove the framework of that
language to get just the assembly instructions. In the case of HLA,
you can do away with the high level features and be left with only the
instructions, directives that any assembler has, and a somewhat
unconventional syntax.
With that view, I have trouble seeing how HLA isn't an assembly
language. If I'm wrong in any way, feel free to explain to me why.
rand...@earthlink.net
>
> With that view, I have trouble seeing how HLA isn't an assembly
> language. If I'm wrong in any way, feel free to explain to me why.
I can answer for him (he does enough of it for me, turnabout is fair
play): the bottom line is that he learned assembly language using a
completely different approach, using a completely different syntax,
and is uncomfortable with the fact that all these young whipper-
snappers are learning it a completely different way and *gasp* aren't
having to work as hard at learning it as he did. That makes him feel a
bit insecure. So he (incorrectly) blames the tool. In fact, you don't
see him complaining about MASM or TASM even though they have roughly
the same high-level features. Like Rene, Wolfgang is confused -- he
really wants to complain about AoA's pedagogical methods (forming a
bridge from HLLs to assembly), but he seems incapable of annunciating
his complaints properly. HLA is something tangible he can latch on to.
It is something he can attack to make himself feel a bit more secure
in his life choices.
hLater,
Randy Hyde
rand...@earthlink.net
> On Wed, 20 Jun 2007 22:36:25 +0200, "Wolfgang Kern"
>
Yet here you are, participating in the threads.
If you really don't want to read this stuff, why do you persist, well,
in reading it? Even if you haven't learned how to use a kill file,
how much effort does it take to quickly scan one message in a thread
and say "okay, on to the next one?" For example, you'll never see me
complaining about threads like "Mark Folley" (or whomever the heck
that is) or any of the "right-wing US policy" or other such threads
around here. I simply ignore them. They generally hold no interest
whatsoever at all to me. At least *these* threads, as abusive as they
are, have *something* to do with assembly language.
Now I just did a quick scan of this newsgroup via Google, looking at
the threads that *were* strictly assembly language. I didn't really
see you posting to *any* of those threads. Granted, I only looked back
a few weeks, but still. If you're going to complain about the signal
to noise ratio around here, please make sure that your posts are part
of the solution rather than part of the problem.
hLater,
Randy Hyde
Betov
news:86hj735pgr3ofdq8n...@4ax.com:
> I don't give a damn about the HLA vs RosAsm argument.
There does not exist any "HLA vs RosAsm argument". This would
be absurd, as long as there is absolutely no possible comparison.
The situation is clear:
1) Master Pdf damaging the beginners market by selling himself.
2) A couple of Asmers intend to defend Assembly.
Period.
Now, the fact that Master Pdf believes that, by attacking RosAsm,
he could defend himself, is not the problem of the Asmers.
Betov.
Herbert Kleebauer
> If that's your view then you don't agree with me at all. Inline
> assembly is basically a compiler feature that lets you embed limited
Limited in which sense?
> assembly instructions inside of a higher level language. I can see how
> you might apply HLA to that definition, but you also need to consider
> that you can't have just inline assembly. It *has* to be embedded in
> the higher level language, and you cannot remove the framework of that
> language to get just the assembly instructions. In the case of HLA,
> you can do away with the high level features and be left with only the
> instructions, directives that any assembler has, and a somewhat
> unconventional syntax.
When a program is started, the OS has to initialize many things before
the first instruction in the exe file is executed. What difference does
it make when there also some additional initialization is made by code
in the exe file before the the first user written instruction is executed?
But once the first instruction of the inline assembler code is executed,
then control remains by the assembler code until you give it back to
compiler generated code. So I don't see any difference between
inline assembler code in a HLL and HLA.
> With that view, I have trouble seeing how HLA isn't an assembly
> language. If I'm wrong in any way, feel free to explain to me why.
Let's take a look at still cameras. There exist full automatic cameras
where you only have to press a button an you get perfect pictures in
most cases (auto focus, auto exposure, auto flash, anti shake). And there
are full manually cameras, where you have to make any setting yourself
(distance, aperture, time, focal length, flash). There are still
a few people who prefer the manual cameras (as there are still some
assembly programmer) which are able to make in some rare conditions
high quality pictures you wouldn't get with an automatic camera.
But it would be crazy to design a new manual camera with the intent
to replace the the automatic cameras (assembly rebirth).
Now suppose there is somebody who wants to design his own camera.
Because it's a one man project he can only implement very primitive
automatic functions. It's obvious that nobody wants to use this
camera. For the same money you get one of the full featured high
tech cameras which are much superior to the new one. On the other
side, people who have decided to use a manual camera surely also
don't want to use it. (There is no market niche for HLA between the
HLL's and assembler). Now the great idea: there are thousands
of people who have to pass a course about photographing with a
manual camera. If he call his new camera "High Level Manual Camera"
the maybe it can be use in that a course. The participants of
the course are happy about any automatic mode support, which
saves them from learn to understand the technical background.
And that's the moment where the new camera becomes dangerous. The
students have to understand the technical background of making
picture. Not because they later all have to use manual cameras
instead of automatic cameras, but because they must be able to
recognize situations where the automatic can't generate the proper
settings and the have to use a manual override. And it isn't an
argument at all, that the students are able to take pictures much
earlier in the course when using this camera or that the average
picture quality is much better than when using a pure manual
camera or that in the last lesson all automatic features are
switched off anyhow. And I don't see any difference in using this
camera or a real HL automatic camera, in both you can switch off
automatic functions. An your argument, that the "C" camera always
does some initialization at power up before you can switch to
manual mode whereas the HLA camera can be switched to manual mode
already before power up so no startup code is generated isn't
really an argument. Once you start taking photos (assembly
programming) they are both in manual mode.
If you want to learn the principles of photography, start with a black
box, fix a sensor on one side and make a small hole in the other side
and start to experiment. But it's essential to not use an analog
film but a digital sensor, so you immediately can take a look at
the results. This means, you don't need a library of i/o functions
but you need a well designed debugger for learning assembly
programming.
But now to the question: is HLA an assembly language? Is an
automatic camera a manual camera just because you can switch
off automatic mode. If yes, then not only HLA but also C is
an assembly language. To say an automatic camera can be called
a manual camera if you can switch to manual mode before power on
but not if you only can switch to manual mode after some automatic
configuration is done at power on doesn't make any sense.
kistj...@excite.com
Nice try but you conveniently leave a few things out here. 1. A HLA
executable doesn't need a runtime lib in contrast to C. 2. As Julienne
already stated, one can configure HLA in such a way that it works like
a traditionalist' assembler. Granted, you need a considerate amount of
tweaking to eliminate all the bookkeeping code, but it can be pulled
off. The only thing I can see is that HLA doesn't do 16-bits real mode
code "natively" (I'm not sure about this one, but I seem to remember
to have read somewehere that the _asm _endasm directives are used to
embed 16-bits code into HLA source), which is rather a shame imho, cos
it would be nice to be able to write OS booting code (e.g. bootloader)
with HLA.
Julienne Walker
> Julienne Walker wrote:
> > If that's your view then you don't agree with me at all. Inline
> > assembly is basically a compiler feature that lets you embed limited
>
> Limited in which sense?
Probably a poor choice of words to cover my ass. I've used compilers
where the inline assembly only supported minimal instructions.
Compilers these days tend to be more robust.
> > assembly instructions inside of a higher level language. I can see how
> > you might apply HLA to that definition, but you also need to consider
> > that you can't have just inline assembly. It *has* to be embedded in
> > the higher level language, and you cannot remove the framework of that
> > language to get just the assembly instructions. In the case of HLA,
> > you can do away with the high level features and be left with only the
> > instructions, directives that any assembler has, and a somewhat
> > unconventional syntax.
>
> When a program is started, the OS has to initialize many things before
> the first instruction in the exe file is executed. What difference does
> it make when there also some additional initialization is made by code
> in the exe file before the the first user written instruction is executed?
Okay, write an assembly program and then a C program that does the
same thing using inline assembly. Remove the loading and initializing
that the OS performs for every program and see what you have left. In
the case of the assembly program, you have your instructions. In the
case of the C program, you have all of the C runtime framework
instructions before and after your instructions. That's the
difference, and you can't remove the extra code that the compiler
adds.
> But once the first instruction of the inline assembler code is executed,
> then control remains by the assembler code until you give it back to
> compiler generated code. So I don't see any difference between
> inline assembler code in a HLL and HLA.
The difference is that with HLA, you *can* remove the extra code that
the compiler adds. So there's no logical way to describe HLA as inline
assembly because there's no embedding going on. You can run standalone
HLA and get the same result as the assembly program above. If there
were no difference between inline assembly and HLA, The HLA program
would be like the C program and removing the framework code not
written by you would be impossible.
This isn't a difficult concept.
> But it would be crazy to design a new manual camera with the intent
> to replace the the automatic cameras (assembly rebirth).
I agree.
> (There is no market niche for HLA between the HLL's and assembler).
I agree.
> An your argument, that the "C" camera always
> does some initialization at power up before you can switch to
> manual mode whereas the HLA camera can be switched to manual mode
> already before power up so no startup code is generated isn't
> really an argument. Once you start taking photos (assembly
> programming) they are both in manual mode.
So what's the problem? If I read that paragraph correctly, you
essentially agreed that HLA is enough of an assembly language to learn
and use assembly programming. I guess that's a step forward since now
you're admitting that HLA is inline assembly rather than a full HLL.
Maybe eventually you'll start saying that HLA actually is an assembly
language. ;-)
> If you want to learn the principles of photography, start with a black
> box, fix a sensor on one side and make a small hole in the other side
> and start to experiment. But it's essential to not use an analog
> film but a digital sensor, so you immediately can take a look at
> the results. This means, you don't need a library of i/o functions
> but you need a well designed debugger for learning assembly
> programming.
I don't think I agree with your learning methodology. Discarding all
of the available resources and doing experiments from scratch is
stupid. If everyone had to relearn everything before moving forward,
we would never get anywhere. So why not use the resources available
and use any existing knowledge as a base to work from? If I know C
then it makes sense to compare assembly examples to C examples so that
I have a point of reference and can make the connections more quickly.
Yes, at some point a beginner needs to dig down and work toward a
deeper understanding. That kind of knowledge only comes from
experience; it can't really be taught effectively. Risking being
called some nasty name by Rene for agreeing with Randy's "swindlings",
if I can get to that point more quickly be leveraging my existing HLL
knowledge, all the better. Right?
> But now to the question: is HLA an assembly language? Is an
> automatic camera a manual camera just because you can switch
> off automatic mode. If yes, then not only HLA but also C is
> an assembly language. To say an automatic camera can be called
> a manual camera if you can switch to manual mode before power on
> but not if you only can switch to manual mode after some automatic
> configuration is done at power on doesn't make any sense.
It's generally a good idea to make a distinction between high level
languages and assembly language. At the very least it makes anal
assembly programmers who feel the need to be classed differently feel
better. The problem with most definitions of assembly language is that
inline assembly meets the requirements. My definition largely fixes
that because it ensures that when you write assembly, all you get is
the assembly you wrote after the OS gives control to your program and
before you return control. With inline assembly that's not the case
because the C compiler adds quite a bit of extra code before and after
the assembly instructions you wrote.
If you can write HLA code and it meets my definition, why not call it
an assembly language? You keep saying that HLA and inline assembly are
the same thing, but it's literally impossible to meet my definition
using inline assembly.
Now here's the real kicker. While it's impossible for inline assembly
to meet my definition, it's possible to set up real assembly so that
it fails the test:
[section .data]
msg: db 'Hello, world!',13,10,0
[section .text]
global _main
extern _printf
_main:
push hello
call _printf
add esp,4
mov eax,0
ret
I think it's been widely accepted that NASM is a real assembly
language. Even Rene has said so, if I recall correctly. But I can turn
it into inline assembly simply by assembling to object code and
linking that object code using a C compiler.
C:\> nasmw -f win32 myprog.asm -o myprog.obj
C:\> gcc myprog.obj -o myprog.exe
C:\> myprog.exe
This adds the C runtime framework. Why is NASM still an assembly
language after this and not inline assembly? Now for the inverse
question. Why is HLA not an assembly language because it does this by
default? Both can remove the framework code, so there's really no
difference. If HLA is inline assembly and I just proved that NASM can
also be inline assembly, you guys need to re-evaluate your
definitions. If you want NASM to be an assembly language, HLA has to
be too. If you want HLA to be inline assembly, NASM has to be too.
See the problem? There's so much inconsistency here that it's
impossible to make a clear and consistent definition. Rene thrives on
this because he can constantly change the argument to meet his needs.
Until you come up with a definition of an assembler and of assembly
language that applies everywhere you want and still excludes HLA,
you're not going to be convincing.
Wolfgang Kern
Jim Higgins wrote:
[..]
> I don't give a damn about the HLA vs RosAsm argument.
> What we need is for Randy and Betov to take their feud to a new group
> dedicated to the purpose and let all who do give a damn follow. I
> very striongly suspect the new place will have one hell of an echo.
Sure, this long lasting, never ending war become sometimes boring,
but I'd miss the sense of humour often found in it.
A bit like the two oldies on the balcony of the muppet-show :)
__
wolfgang
Wolfgang Kern
randyhyde wrote:
>> LET HLA be a valid ASM? IMHO: No, under no circumstance.
> And you'd let MASM be a valid assembler?
> How about TASM?
> Watch out for that slippery slope you're headed down.
We all know about this two and they are almost gone anyway,
but they were more close to ASM than your HLA.
__
wolfgang
Wolfgang Kern
Randy answered Julienne on by behalf:
>> With that view, I have trouble seeing how HLA isn't an assembly
>> language. If I'm wrong in any way, feel free to explain to me why.
> I can answer for him (he does enough of it for me,...
[..]
> ... Like Rene, Wolfgang is confused -- he really wants to complain
> about AoA's pedagogical methods
***
> (forming a bridge from HLLs to assembly),
***
And exact here is the point what I see totally wrong.
Why must an ASM-newbie have to learn HLL before ?
So my way of teaching ASM is (in this order):
* binary logic
* hardware in general
* CPU(s) capabilities (registers, addressing modes, RM/PM)
* introduction of used tools (debugger, text-/data-viewer)
* ASM ("the bridge" from text source to machine code)
introduction of the syntax used yet (and other possibities)
* the (only basic on start) instruction set
* a general overview of OSes (parameter passing methodes, FS)
* advanced instructions
* system instructions (which aren't available in user mode)
* FPU and CPU numeric extension (SSE) instructions.
* API (a few examples and a link to the whole)
developers level only:
** enhanced CPU features (pipes, MSRs, instruction timing)
** chipsets and busses (ISA-ports,PCI,SCSI,1394,i^2C,USB)
** SMC (when should it be used or avoided)
** pratice: how to avoid redundancy
** optimisation (size and/(and/or) speed)
** how to interprete HLL compiled disassembly
* and finally:
a short introduction of HLL with PowerBasic- and C-compiled
examples compared to plain ASM (size and speed).
> It is something he can attack to make himself feel a bit more
> secure in his life choices.
Be sure Randy, I'm not in need of any kind.
You are the one who weekly announce a new release of HLA....
__
wolfgang
kistj...@excite.com
> Be sure Randy, I'm not in need of any kind.
> You are the one who weekly announce a new release of HLA....
>
If that were true we'd already have HLA v3.xx, complete with ssse3,
sse4, vmx and x86-64 support :)
Betov
news:1182434551....@k79g2000hse.googlegroups.com:
> [section .data]
>
> msg: db 'Hello, world!',13,10,0
>
> [section .text]
>
> global _main
> extern _printf
>
> _main:
> push hello
> call _printf
> add esp,4
> mov eax,0
> ret
>
> I think it's been widely accepted that NASM is a real assembly
> language. Even Rene has said so, if I recall correctly.
Simply absurd. Yes, NASM _is_ an Assembler. Like most Assemblers,
it can be used for integrating Satic Libs, and integrating Static
Libs, is HLL. Do the very same thing with Include Statements, and
you are back to Assembly.
This is the very same thing with embeeded Macros, by the way:
Do some HLLism with User Defined Macros, and you are doing Macros
Assembly. Do the very same thing with the embeeded macros of a
Compiler for Assembly Language (typically MASM), and you are no
more in the Assembly field.
All of this is a matter of _DEFINITION_. If HLA is an Assembler,
then C is an Assembler. Visual Basic is an Assembler. Anything
is an Assembler. Therefore, the _word_ Assembler_ does no more
exist, because it does no more mean a thing. As Beth was used
say, when locked in a very similar discussion:
"OK. HLA is a banana".
Betov.
Jim Carlock
: It [inline assembly] *has* to be embedded in the higher level language,
That statement is wrong. It probably should get stated as:
"Inline assembly *has* to get embedded in another language,..."
but even that one can punch holes in.
Explain please.
Ok. <g>
If an IF statement compiles directly to a CMP / Jcc macro, it ends up
as assembly language. It requires the individual to know the particular
the specific implications involved by the IF macro. The end result is that
the IF simplifies things and the end user needs to worry less about the
resulting flags (possibly).
Higher and lower are opinionated words, sometimes, and maybe
should be avoided. Many of the posts that Randy and others present
involves their own special definitions of higher and lower (and no one
should really care as one MACRO changes an assembly language
compiler from a low level language to a high level language, even
though that compiler is both!).
If IF makes a language a high level language but IF safely recurses
it's implementations in a low level language, and if the low-level
language is assembly language, the end result is a low-level language
that the developer knows evolved from a high-level language
construct written in a low-level language as an "inline high-level
language construct". If you and the compiler can safely recurse
the definitions of high-level, low-level and IF, congratulations!
That's all I have to say about that.
--
Jim Carlock
Julienne Walker
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182434551....@k79g2000hse.googlegroups.com
>
> > I think it's been widely accepted that NASM is a real assembly
> > language. Even Rene has said so, if I recall correctly.
>
> Simply absurd. Yes, NASM _is_ an Assembler. Like most Assemblers,
> it can be used for integrating Satic Libs, and integrating Static
> Libs, is HLL. Do the very same thing with Include Statements, and
> you are back to Assembly.
So you have no problem with using an include directive to merge source
files together at compile time, but taking two assembled files and
merging them with another tool suddenly makes the whole thing an HLL?
I guess that explains your penchant for cut and paste reuse, but I'm
having trouble understanding how you're using an HLL when none of the
parts were written with an HLL. Could you describe exactly how and why
using a linker means that your code is an HLL?
> This is the very same thing with embeeded Macros, by the way:
>
> Do some HLLism with User Defined Macros, and you are doing Macros
> Assembly. Do the very same thing with the embeeded macros of a
> Compiler for Assembly Language (typically MASM), and you are no
> more in the Assembly field.
Ah, so if I write a bunch of macros in MASM that duplicate the effect
of the built in macros and use them instead, then I'm doing macro
assembly?
> All of this is a matter of _DEFINITION_. If HLA is an Assembler,
> then C is an Assembler. Visual Basic is an Assembler.
Why? You can say "x is y", but if you can't give consistent and
unambiguous reasons, it means nothing. Kind of like "HLA is a banana".
I've given reasons why HLA is an assembly language that are consistent
and unambiguous. You say that HLA isn't assembly because <so and so>.
Yet when I give a situation where <so and so> is false, you say that
HLA still isn't assembly.
So I say bullshit. Give me a complete list of why HLA isn't an
assembly language so that I can see the whole picture all at once. If
you can't do this for any reason, that means you admit that my logic
is sound and yours is lacking.
Julienne Walker
> "Julienne Walker" wrote:
>
> : It [inline assembly] *has* to be embedded in the higher level language,
>
> That statement is wrong. It probably should get stated as:
> "Inline assembly *has* to get embedded in another language,..."
> but even that one can punch holes in.
>
> Explain please.
> Ok. <g>
>
>
> That's all I have to say about that.
You didn't explain why my statement was wrong. Are you somehow trying
to suggest that inline assembly isn't embedded in the parent language
because the parent language is eventually broken down into assembly?
That's the only thing I could see that would make an attempt at
proving me wrong. Everything else was just talking about how high
level and low level are subjective, which has no bearing on inline
assembly that I can see.
rand...@earthlink.net
> And exact here is the point what I see totally wrong.
> Why must an ASM-newbie have to learn HLL before ?
Because it's more efficient and they wind up a better programmer by
doing so. History, with *lots* of students over the years, has
demonstrated that if students master the techniques of structure
programming, and learn about the proper using of data structures and
algorithms *before* they learn a low-level programming language, they
become better programmers.
>
> So my way of teaching ASM is (in this order):
> * binary logic
Chapters 1.2, 1.3, & 2.3 in AoA (on-line)
> * hardware in general
Chapters 2.1-2.7 in AoA
> * CPU(s) capabilities (registers, addressing modes, RM/PM)
Chapters 1.1, 2.1-2.7 in AoA
> * introduction of used tools (debugger, text-/data-viewer)
Chapter 1.1 in AoA
> * ASM ("the bridge" from text source to machine code)
> introduction of the syntax used yet (and other possibities)
Chapter 1.1 in AoA
> * the (only basic on start) instruction set
This spread through the first three volumes because I've found that
the last thing you want to do is hit them over the head with a bunch
of instructions at once, without giving them time to assimilate each
instruction.
> * a general overview of OSes (parameter passing methodes, FS)
AoA doesn't bother much with this at all. It has little to do with
assembly language. It makes a good follow-on study once the student
has learned basic assembly language.
> * advanced instructions
Chapters 3.10-3.12, 4.1-4.12, and 5.1-5.5
> * system instructions (which aren't available in user mode)
This don't belong in an introductory text on assembly language
programming.
> * FPU and CPU numeric extension (SSE) instructions.
3.11 (FPU) and 4.11 (MMX).
SSE will probably show up in a second edition.
> * API (a few examples and a link to the whole)
> developers level only:
See the comment about OSes above.
> ** enhanced CPU features (pipes, MSRs, instruction timing)
Ch 2.1-2.7
> ** chipsets and busses (ISA-ports,PCI,SCSI,1394,i^2C,USB)
This has *nothing* to do with assembly langage programming.
> ** SMC (when should it be used or avoided)
As I noted elsewhere, this would be an interesting to the end of a
second edition of AoA.
> ** pratice: how to avoid redundancy
> ** optimisation (size and/(and/or) speed)
Far beyond the scope of an introductory textbook on assembly.
Attempts to teach this material as a follow-on to a basic assembly
text have not met with much commercial success, so don't expect too
many publishers to jump on this. Agner Fog's material will continue to
provide this info.
> ** how to interprete HLL compiled disassembly
See "Write Great Code: Volume II"
>
> * and finally:
> a short introduction of HLL with PowerBasic- and C-compiled
> examples compared to plain ASM (size and speed).
See "Write Great Code: Volume II"
>
> > It is something he can attack to make himself feel a bit more
> > secure in his life choices.
>
> Be sure Randy, I'm not in need of any kind.
Well, one "Life Choice" that I happen to make is to try and *know
something* about a subject before acting like an authority on it. I
may not always be successful, but at least I haven't made the blunder
you've done here and attack AoA/HLA without knowing anything about
them, and then announce to the whole world how teaching assembly
*ought* to be done, without realizing that AoA pretty much follows
your approach.
At least we agree on the material and roughly the order in which it
ought to be taught. Next time you want to attack AoA and my
pedagogical methods, you ought to try *reading* it first, and verify
that it really *does* teaching things differently from the way you
would expect people to learn the material.
> You are the one who weekly announce a new release of HLA....
Actually, since it's inception, I've probably averaged about one
release per month (I'm almost to revision 100, and it's been 8 years
since the first release). I suspect you'll find that most people
consider this "good support" and could care less what you mean by
"life choices".
hLater,
Randy Hyde
rand...@earthlink.net
>
> Granted, you need a considerate amount of
> tweaking to eliminate all the bookkeeping code, but it can be pulled
> off.
Not quite sure what you mean by "considerate amount..."
To eliminate any extra code HLA might produce for you, you do the
following:
1. Use a "UNIT" declaration rather than a "PROGRAM" declaration:
2. Add the following two statements immediately after the UNIT:
?@nodisplay := true;
?@noframe := true;
>From that point forward, you're on your own.
> The only thing I can see is that HLA doesn't do 16-bits real mode
> code "natively" (I'm not sure about this one, but I seem to remember
> to have read somewehere that the _asm _endasm directives are used to
> embed 16-bits code into HLA source),
The #asm..#endasm (and #emit) directives are deprecated. They were
originally added to all the use of segmentation (though not 16-bit
code), e.g., "mov eax, fs:[0]", but the need for that has long since
gone away.
> which is rather a shame imho, cos
> it would be nice to be able to write OS booting code (e.g. bootloader)
> with HLA.
I will gladly defer the need to write 16-bit code to other assemblers.
Boot loaders are small; write it in MASM. While I agree that writing
boot loaders is a popular past time for people who think they are
going to become the next Linus, the truth is that there really isn't
much need for people to write them these days. And sooner or later,
the BIOS (or whatever) is going to come up in 32-bit mode and it won't
really matter anymore.
hLater,
Randy Hyde
rand...@earthlink.net
> he could defend himself, is not the problem of the Asmers.
An amusing statement, coming from the guy who has always used attacks
on other products as a marketing strategy for his own product.
hLater,
Randy Hyde
Betov
news:1182440487....@q75g2000hsh.googlegroups.com:
> On Jun 21, 10:51 am, Betov <b...@free.fr> wrote:
>> Julienne Walker <happyfro...@hotmail.com>
écrivaitnews:1182434551.88391
> 2.4...@k79g2000hse.googlegroups.com
>>
> So you have no problem with using an include directive to merge source
> files together at compile time, but taking two assembled files and
> merging them with another tool suddenly makes the whole thing an HLL?
Right.
> I guess that explains your penchant for cut and paste reuse,
Right. The reason why Cut&Paste Methods like the one of RosAsm
"Clip File" implementation, or the Wizards implementations, or
the Applications Builders implementations, should be developed.
> but I'm
> having trouble understanding how you're using an HLL when none of the
> parts were written with an HLL. Could you describe exactly how and why
> using a linker means that your code is an HLL?
Simple: Because Assembly is a Language that _shows_, and
not a Language that _hides_. As soon as you hide (or Hyde),
you have left the Assembly field.
> so if I write a bunch of macros in MASM that duplicate the effect
> of the built in macros and use them instead, then I'm doing macro
> assembly?
Of course. Even though you would have some serious problems
for doing so, with MASM.
>> All of this is a matter of _DEFINITION_. If HLA is an Assembler,
>> then C is an Assembler. Visual Basic is an Assembler.
>
> Why? You can say "x is y", but if you can't give consistent and
> unambiguous reasons, it means nothing. Kind of like "HLA is a banana".
> I've given reasons why HLA is an assembly language that are consistent
> and unambiguous. You say that HLA isn't assembly because <so and so>.
> Yet when I give a situation where <so and so> is false, you say that
> HLA still isn't assembly.
>
> So I say bullshit. Give me a complete list of why HLA isn't an
> assembly language so that I can see the whole picture all at once. If
> you can't do this for any reason, that means you admit that my logic
> is sound and yours is lacking.
I did not directly talk about that. I was talking about your NASM
absurd example. It would absurd, because you do understand that
the key is the _method_.
The discussion about HLA not being an Assembler, how and why, has
been closed since Randall Hyde stole FASM, and embeeded it inside
his HLL Pre-Parser. Now on, HLA is an HLL, and there is no possible
discussion about this point. It would make absolutely no sense to
discuss about why an HLL is an HLL. This is perfectly clear since
day one of the HLLs.
Now, the problem is as follows:
* "Can an HLL be use for learning Assembly?".
I always said that this is utterly impossible, because the
programming methods of Assembly, as done by the real Asmers,
cannot be compared to their HLL equivalent. Particulary on
the front-line of Strategy Optimization.
* "Can an HLL be use for learning Inline Asm?".
I say: Yes.
* "Can HLA be used for learning Inline Asm?".
I say: No, because it does not even have any
Asm {
}
... Statement. With an HLL not making any difference in between
what is HLL, and what could, eventually, be some never seen weird
form of Assembly Instruction, this is utterly impossible to learn
inline Assembly.
So, HLA is now a strange form of HLL that mimics C, but that will
never compete with C. One another of these innoumerous Tools that
passed away. In its case, the sooner will be the better, as long
as it is used as a tool for drying out the flow of beginners, who
could come to Assembly, for the only benefit of the personal glory
of one single criminal, doing his best to kill Assembly, because
he is unable to write any Assembler.
Betov.
Jim Carlock
> "Julienne Walker" wrote:
>
> : It [inline assembly] *has* to be embedded in the higher level language,
>
> That statement is wrong. It probably should get stated as:
> "Inline assembly *has* to get embedded in another language,..."
> but even that one can punch holes in.
>
> Explain please.
> Ok. <g>
>
> <snip>
>
> That's all I have to say about that.
"Julienne Walker" wrote...
: You didn't explain why my statement was wrong.
You missed it totally! It wasn't about the word "inline assembly".
It was about defining "inline assembly" as MUST exist inside of a
"high level language". Then there came a presentation of a better
example of the statement made which changed "high level language"
to "another language". But I now see that definition is wrong as well.
Perhaps...
"Inline assembly *has* to get embedded in a language, even within
itself..."
: Are you somehow trying to suggest that inline assembly isn't embedded
: in the parent language because the parent language is eventually broken
: down into assembly?
:-) The new definition works a little better. The experts can judge that.
Just trying to post something with a little factual humor. Dry, humor?
There's a funny words... "factual humor".
--
Jim Carlock
Betov
news:1182442652.7...@o11g2000prd.googlegroups.com:
Any reader can witness that i have never attacked any Assembler
around. I must even say that i am the only Assembler's author,
who ever came here, and promoted NASM, FASM and GoAsm.
Any reader can also witness that i am not used to promote RosAsm
often times, because a good produce can sell itself. I do not
even post announcements, here, each time there is a new release.
The only products i have ever attacked have been the ones damaging
Assembly: MASM, which i do not talk much about, nowadays, because
it is a dead horse, and your HLL, because you are a criminal doing
your best for killing Assembly. Other than that, why would i talk
about an HLL, would it be as absurd as yours?
Betov.
Julienne Walker
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182440487....@q75g2000hsh.googlegroups.com:
>
> > On Jun 21, 10:51 am, Betov <b...@free.fr> wrote:
> >> Julienne Walker <happyfro...@hotmail.com>
>
> > having trouble understanding how you're using an HLL when none of the
> > parts were written with an HLL. Could you describe exactly how and why
> > using a linker means that your code is an HLL?
>
> Simple: Because Assembly is a Language that _shows_, and
> not a Language that _hides_. As soon as you hide (or Hyde),
> you have left the Assembly field.
You can look at each of the individual files and see the code. I
wouldn't say anything is hidden unless all you have are the object
files. But even then, you could disassemble them and nothing is
hidden. So I think it's more accurate to say that assembly is a
language that _shows_ rather than a language that doesn't hide. A
subtle but significant difference.
> > so if I write a bunch of macros in MASM that duplicate the effect
> > of the built in macros and use them instead, then I'm doing macro
> > assembly?
>
> Of course. Even though you would have some serious problems
> for doing so, with MASM.
How so? Last I checked, MASM doesn't penalize you for not using the
high level features.
> >> All of this is a matter of _DEFINITION_. If HLA is an Assembler,
> >> then C is an Assembler. Visual Basic is an Assembler.
>
> > Why? You can say "x is y", but if you can't give consistent and
> > unambiguous reasons, it means nothing. Kind of like "HLA is a banana".
> > I've given reasons why HLA is an assembly language that are consistent
> > and unambiguous. You say that HLA isn't assembly because <so and so>.
> > Yet when I give a situation where <so and so> is false, you say that
> > HLA still isn't assembly.
>
> > So I say bullshit. Give me a complete list of why HLA isn't an
> > assembly language so that I can see the whole picture all at once. If
> > you can't do this for any reason, that means you admit that my logic
> > is sound and yours is lacking.
>
> The discussion about HLA not being an Assembler, how and why, has
> been closed since Randall Hyde stole FASM, and embeeded it inside
> his HLL Pre-Parser. Now on, HLA is an HLL, and there is no possible
> discussion about this point. It would make absolutely no sense to
> discuss about why an HLL is an HLL. This is perfectly clear since
> day one of the HLLs.
Wrong.
I've already asked you if HLA would be an assembler should it do all
of the work instead of passing on intermediate code to FASM. You said,
very clearly and in no uncertain terms, _No_. So you can't use this as
an argument anymore because removing the problem (the fact that HLA
defers to FASM) isn't significant enough to change your answer.
> Now, the problem is as follows:
>
> * "Can an HLL be use for learning Assembly?".
>
> I always said that this is utterly impossible, because the
> programming methods of Assembly, as done by the real Asmers,
> cannot be compared to their HLL equivalent. Particulary on
> the front-line of Strategy Optimization.
This is true to an extent, but I disagree that Strategy Optimization,
as you call it, is specific to assembly programming in any way. Note
that I'm going on the definition from B_U_Asm.
> * "Can an HLL be use for learning Inline Asm?".
>
> I say: Yes.
It would have to be, because without the HLL that supports inline
assembly, there's no inline assembly. :-)
Betov
news:1182445135.6...@n2g2000hse.googlegroups.com:
> On Jun 21, 12:28 pm, Betov <b...@free.fr> wrote:
>> Julienne Walker <happyfro...@hotmail.com>
écrivaitnews:1182440487.29738
>>
>
>> > so if I write a bunch of macros in MASM that duplicate the effect
>> > of the built in macros and use them instead, then I'm doing macro
>> > assembly?
>>
>> Of course. Even though you would have some serious problems
>> for doing so, with MASM.
>
> How so? Last I checked, MASM doesn't penalize you for not using the
> high level features.
Heuuhh! Is my english _that_ bad ?! You wrote "if I write a
bunch of macros in MASM", talking of replacing the embeeded
MASM macros that make it a Compiler and no more an Assembler.
Therefore, i reply, that developing these macros would me
often times impossible with MASM (The MASM Macros System is
too weak for this).
>> The discussion about HLA not being an Assembler, how and why, has
>> been closed since Randall Hyde stole FASM, and embeeded it inside
>> his HLL Pre-Parser. Now on, HLA is an HLL, and there is no possible
>> discussion about this point. It would make absolutely no sense to
>> discuss about why an HLL is an HLL. This is perfectly clear since
>> day one of the HLLs.
>
> Wrong.
>
> I've already asked you if HLA would be an assembler should it do all
> of the work instead of passing on intermediate code to FASM. You said,
> very clearly and in no uncertain terms, _No_. So you can't use this as
> an argument anymore because removing the problem (the fact that HLA
> defers to FASM) isn't significant enough to change your answer.
Yes, it is significant enough for changing the name. In the
previous swindling, HLA was passing down the source File to
FASM. Therefore, it was an HLL Pre-Parser. Now that Master
Pdf has stolen and obfuscated FASM inside his HLL Pre-Parser,
this is no more an HLL Pre-Parser, but an... HLL, like any
other HLL... but deprived of Inline Asm Statement, so that
it can even not be used for learning Inline Asm, as one
could do with C.
Betov.
Julienne Walker
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182445135.6...@n2g2000hse.googlegroups.com:
>
> >> Of course. Even though you would have some serious problems
> >> for doing so, with MASM.
>
> > How so? Last I checked, MASM doesn't penalize you for not using the
> > high level features.
>
> Heuuhh! Is my english _that_ bad ?!
Yes, your English is horrendous. I assume that you look like an idiot
simply because you have trouble expressing yourself in English and not
because you're actually an idiot. That's why I keep trying different
ways to get the whole story in a way that I can understand.
> Therefore, i reply, that developing these macros would me
> often times impossible with MASM (The MASM Macros System is
> too weak for this).
You're dodging the question. Assume for a moment that I could do this
with MASM and answer it, please.
> >> The discussion about HLA not being an Assembler, how and why, has
> >> been closed since Randall Hyde stole FASM, and embeeded it inside
> >> his HLL Pre-Parser. Now on, HLA is an HLL, and there is no possible
> >> discussion about this point. It would make absolutely no sense to
> >> discuss about why an HLL is an HLL. This is perfectly clear since
> >> day one of the HLLs.
>
> > Wrong.
>
> > I've already asked you if HLA would be an assembler should it do all
> > of the work instead of passing on intermediate code to FASM. You said,
> > very clearly and in no uncertain terms, _No_. So you can't use this as
> > an argument anymore because removing the problem (the fact that HLA
> > defers to FASM) isn't significant enough to change your answer.
>
> Yes, it is significant enough for changing the name. In the
> previous swindling, HLA was passing down the source File to
> FASM. Therefore, it was an HLL Pre-Parser. Now that Master
> Pdf has stolen and obfuscated FASM inside his HLL Pre-Parser,
> this is no more an HLL Pre-Parser, but an... HLL, like any
> other HLL... but deprived of Inline Asm Statement, so that
> it can even not be used for learning Inline Asm, as one
> could do with C.
I still say bullshit. Not too long ago I asked you a question. I asked
you if I wrote my own HLA compiler (all my code, mind you) that parsed
HLA assembly and produced machine code, would it be an assembler? You
said _no_.
Therefore, I refuse to accept any mention of FASM as the reason why
HLA is not an assembler. It's irrelevant to the question because even
if I take FASM and Randy's implementation out of the problem
completely, you still say HLA is not an assembler.
So, I want you to tell me your reasoning for two things without
resorting to the above nonsense:
1) Why could HLA never be an assembler?
2) Why could the HLA language never be assembly?
Note that these are two different questions. When I say _assembler_, I
mean a tool that takes a text file with characters that represent
assembly language code and creates machine code from it. In the case
of RosAsm, that would mean the file RosAsm2049a.EXE. When I say
_assembly_, I mean a programming language that you type into a text
file. In the case of RosAsm, that would mean the source code that your
text editor displays.
These are two simple questions yet you've never been able to answer
them to my satisfaction. Now is your chance to shut me up.
Herbert Kleebauer
> On Jun 21, 5:04 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > When a program is started, the OS has to initialize many things before
> > the first instruction in the exe file is executed. What difference does
> > it make when there also some additional initialization is made by code
> > in the exe file before the the first user written instruction is executed?
>
> Okay, write an assembly program and then a C program that does the
> same thing using inline assembly. Remove the loading and initializing
> that the OS performs for every program and see what you have left. In
> the case of the assembly program, you have your instructions. In the
> case of the C program, you have all of the C runtime framework
> instructions before and after your instructions. That's the
> difference, and you can't remove the extra code that the compiler
> adds.
What does it matter which code is linked to my own code? We are speaking
about the code the user writes (programming) and not about which other
code is linked to it. And when the code the user writes is written in
an assembly language, it is assembly programming. If it is written
in a HLL then it is not assembly programming.
> > But once the first instruction of the inline assembler code is executed,
> > then control remains by the assembler code until you give it back to
> > compiler generated code. So I don't see any difference between
> > inline assembler code in a HLL and HLA.
>
> The difference is that with HLA, you *can* remove the extra code that
> the compiler adds. So there's no logical way to describe HLA as inline
> assembly because there's no embedding going on. You can run standalone
> HLA and get the same result as the assembly program above. If there
> were no difference between inline assembly and HLA, The HLA program
> would be like the C program and removing the framework code not
> written by you would be impossible.
>
> This isn't a difficult concept.
No, it's really not difficult, but you still don't get it. HLA supports
HL constructs and this HL constructs are mixes with CPU instructions
and this is not assembly programming it is using inline assembler code
at very fine grain level. On the other side, if you use inline assembler
in real HLL language, then you normally have a coarse grained intermix between
HL and assembly programming (you don't use a single mov instruction
in a C for loop). In this sense inline assembly programming in a HLL
is much more assembly programming than HLA programming because when
you write inline assembly code in a HLL, then the complete inline assembly
block is written in assembly only.
> > An your argument, that the "C" camera always
> > does some initialization at power up before you can switch to
> > manual mode whereas the HLA camera can be switched to manual mode
> > already before power up so no startup code is generated isn't
> > really an argument. Once you start taking photos (assembly
> > programming) they are both in manual mode.
>
> So what's the problem? If I read that paragraph correctly, you
> essentially agreed that HLA is enough of an assembly language to learn
> and use assembly programming. I guess that's a step forward since now
> you're admitting that HLA is inline assembly rather than a full HLL.
> Maybe eventually you'll start saying that HLA actually is an assembly
> language. ;-)
I don't understand what you want to say. If you sit down and write
a program then whether this is an assembly program or an HLL program
only depends on the character string you write but not on something
you later link to it. If I write an assembly program, then there
is a sequence of CPU instructions and if I have an CPU manual at hand
I can manually convert the source to object code. And if I use an
intermix of CPU instructions and HL language constructs, then this
is not assembly programming.
> I don't think I agree with your learning methodology. Discarding all
> of the available resources and doing experiments from scratch is
> stupid. If everyone had to relearn everything before moving forward,
> we would never get anywhere. So why not use the resources available
> and use any existing knowledge as a base to work from? If I know C
> then it makes sense to compare assembly examples to C examples so that
> I have a point of reference and can make the connections more quickly.
If the goal is to learn the language of the CPU why should I waste my
time with something like IF/ELSE/FOR/WHILE? If you want to learn French
do you then start with one French word and then write many English
sentences where you just replace this one word with the French version?
An then learn the next word and again write English with now two
words replaced?
> Yes, at some point a beginner needs to dig down and work toward a
> deeper understanding. That kind of knowledge only comes from
> experience; it can't really be taught effectively. Risking being
> called some nasty name by Rene for agreeing with Randy's "swindlings",
> if I can get to that point more quickly be leveraging my existing HLL
> knowledge, all the better. Right?
Do you really think you have learned French just because you can
write complicated English sentences with a few words replaced
by the French version? Better start with very easy sentences completely
written in French.
> It's generally a good idea to make a distinction between high level
> languages and assembly language. At the very least it makes anal
> assembly programmers who feel the need to be classed differently feel
> better. The problem with most definitions of assembly language is that
> inline assembly meets the requirements. My definition largely fixes
> that because it ensures that when you write assembly, all you get is
> the assembly you wrote after the OS gives control to your program and
> before you return control. With inline assembly that's not the case
> because the C compiler adds quite a bit of extra code before and after
> the assembly instructions you wrote.
Again, what is added outside my code doesn't matter. It's the code
I write which matters. If you use inline assembly in C, then you
normally have a clearly separated piece of code and within this
code you do assembly programming. But in HLA there is a directly intermix
of HL constructs and CPU instructions and you cant say from page 1 to 10
is HL code and from page 11 to 13 assembly code.
> If you can write HLA code and it meets my definition, why not call it
> an assembly language? You keep saying that HLA and inline assembly are
> the same thing, but it's literally impossible to meet my definition
> using inline assembly.
You can use a PC as typewriter (directly send and key press to the printer)
but is this enough to claim that a PC is a typewriter?
> See the problem? There's so much inconsistency here that it's
> impossible to make a clear and consistent definition.
It's pretty clear. If you write a textual representation of CPU instructions,
then you do assembly programming. If you write instructions for an compiler
which doesn't have any meaning for the CPU and for what the compiler generates
CPU instructions, then you don't do assembly programming. The CPU doesn't
know and IF/ELSE/WHILE/FOR etc.
Herbert Kleebauer
> Nice try but you conveniently leave a few things out here. 1. A HLA
> executable doesn't need a runtime lib in contrast to C. 2. As Julienne
What do you mean with "need a runtime lib"? Do you think an exe generated
by a C compiler when copied to an other computer doesn't run as long
as you don't also copy some library files? Or do you mean the user
written code is liked together with some library code to form an exe?
But what has this to do with assembly programming? To use a linker to
add other code doesn't mean you haven't written your code in assembler.
> already stated, one can configure HLA in such a way that it works like
> a traditionalist' assembler. Granted, you need a considerate amount of
> tweaking to eliminate all the bookkeeping code, but it can be pulled
> off. The only thing I can see is that HLA doesn't do 16-bits real mode
> code "natively" (I'm not sure about this one, but I seem to remember
> to have read somewehere that the _asm _endasm directives are used to
> embed 16-bits code into HLA source), which is rather a shame imho, cos
> it would be nice to be able to write OS booting code (e.g. bootloader)
> with HLA.
You also can switch off the automatic mode of the camera but does
this make it a manual camera? You can also not start the motor of
a motor saw and use by hand, but it still is a motor saw. You can
ignore the HLL features of HLA but it is still a HLL language.
Betov
news:1182449892....@m36g2000hse.googlegroups.com:
> 1) Why could HLA never be an assembler?
? Again ?!
Because a cat can never be a dog, and nobody ever needed
demonstrating that a cat and a dog are different animals.
We call them differently because they _are_ different.
Period.
The definitions of the words: Assembler, Symbolic Assembler,
Macros Symbolic Assembler, compiler for Assembly Language,
HLL, VHLL, do not need to be reviewed for pleasing master
Pdf swindlings. These definitions are known, fixed, and have
been debated to death, here, and in other places.
So, i fail to understand where you mean to go, with your
absurd questions, now that HLA has stopped matching with the
definition of an "HLL Pre-parser" for enhancing to the status
of HLL.
> 2) Why could the HLA language never be assembly?
The _Language_? You mean... the way for physicaly writing
an Assembly Statement? Whatever absurd writing convention
(notation) it would inflict on people, a Asm Statement is
an Asm Statement. And then? Does an Asm Statement, as found
in so many HLLs, make any _HLL-Language_ Assembly Language?
At least, if there was an Inline-Asm notation around the
Asm Statement, this could be "the Assembly Language of the
Inline Asm", if you really want to call it that strange way,
but, here, with HLA, you do not even have this. So what do
you want to talk about? This is so absurd...
Betov.
Julienne Walker
> Julienne Walker wrote:
> > On Jun 21, 5:04 am, Herbert Kleebauer <k...@unibwm.de> wrote:
> > > But once the first instruction of the inline assembler code is executed,
> > > then control remains by the assembler code until you give it back to
> > > compiler generated code. So I don't see any difference between
> > > inline assembler code in a HLL and HLA.
>
> > The difference is that with HLA, you *can* remove the extra code that
> > the compiler adds. So there's no logical way to describe HLA as inline
> > assembly because there's no embedding going on. You can run standalone
> > HLA and get the same result as the assembly program above. If there
> > were no difference between inline assembly and HLA, The HLA program
> > would be like the C program and removing the framework code not
> > written by you would be impossible.
>
> > This isn't a difficult concept.
>
> No, it's really not difficult, but you still don't get it. HLA supports
> HL constructs and this HL constructs are mixes with CPU instructions
> and this is not assembly programming it is using inline assembler code
> at very fine grain level.
I don't think you understand. The HL constructs that HLA supports are
*optional*. FASM supports HL constructs too, also in the form of
macros
supplied with the assembler. Is FASM a fine grained inline assembly
too?
If no, then your argument doesn't apply to HLA. If yes, then your idea
of a standalone assembly language is in the minority.
> > I don't think I agree with your learning methodology. Discarding all
> > of the available resources and doing experiments from scratch is
> > stupid. If everyone had to relearn everything before moving forward,
> > we would never get anywhere. So why not use the resources available
> > and use any existing knowledge as a base to work from? If I know C
> > then it makes sense to compare assembly examples to C examples so that
> > I have a point of reference and can make the connections more quickly.
>
> If the goal is to learn the language of the CPU why should I waste my
> time with something like IF/ELSE/FOR/WHILE? If you want to learn French
> do you then start with one French word and then write many English
> sentences where you just replace this one word with the French version?
> An then learn the next word and again write English with now two
> words replaced?
You obviously don't understand what I meant when I said "use any
existing
knowledge as a base to work from". But I'll give you kudos for taking
my statement to the most illogical and ridiculous extreme in a
pathetic
attempt to prove your point.
> > Yes, at some point a beginner needs to dig down and work toward a
> > deeper understanding. That kind of knowledge only comes from
> > experience; it can't really be taught effectively. Risking being
> > called some nasty name by Rene for agreeing with Randy's "swindlings",
> > if I can get to that point more quickly be leveraging my existing HLL
> > knowledge, all the better. Right?
>
> Do you really think you have learned French just because you can
> write complicated English sentences with a few words replaced
> by the French version? Better start with very easy sentences completely
> written in French.
Allow me to make a more accurate analogy. Let's say you're a native
English
speaker and want to learn Japanese. You already know a bit of Spanish.
You can use the fact that Spanish grammar is similar in build to
Japanese
grammar and learn more quickly. This is leveraging existing knowledge
to
pick up the pace of learning. However, Japanese grammar is different,
so
you would still need to keep it simple while learning. This is
equivalent
to learning the basic instruction set and working with simple
programs.
Once you're comfortable with the basics, you can then learn more of
the
nuances of Japanese grammar. This is equivalent to digging down into a
more complete understanding of assembly programming, picking up more
advanced instructions and techniques, and building larger and more
complicated programs. Of course, you get to this point faster because
you used your existing knowledge of Spanish to learn Japanese more
quickly.
You didn't learn Japanese by intermingling Japanese and Spanish. You
learned Japanese by taking advantage of similar concepts from Spanish
to save yourself the trouble of relearning something you already knew.
> > It's generally a good idea to make a distinction between high level
> > languages and assembly language. At the very least it makes anal
> > assembly programmers who feel the need to be classed differently feel
> > better. The problem with most definitions of assembly language is that
> > inline assembly meets the requirements. My definition largely fixes
> > that because it ensures that when you write assembly, all you get is
> > the assembly you wrote after the OS gives control to your program and
> > before you return control. With inline assembly that's not the case
> > because the C compiler adds quite a bit of extra code before and after
> > the assembly instructions you wrote.
>
> Again, what is added outside my code doesn't matter. It's the code
> I write which matters. If you use inline assembly in C, then you
> normally have a clearly separated piece of code and within this
> code you do assembly programming. But in HLA there is a directly intermix
> of HL constructs and CPU instructions and you cant say from page 1 to 10
> is HL code and from page 11 to 13 assembly code.
If you remove the HL constructs, it's all assembly code.
Julienne Walker
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182449892....@m36g2000hse.googlegroups.com:
>
> > 1) Why could HLA never be an assembler?
>
> ? Again ?!
Yes, again. Because, and I'll repeat myself *again* and make it nice
and easy to read so that you don't miss it this time, YOU HAVE NOT
ANSWERED TO MY SATISFACTION.
> Because a cat can never be a dog, and nobody ever needed
> demonstrating that a cat and a dog are different animals.
> We call them differently because they _are_ different.
> Period.
Yet we can all describe the differences between a cat and a dog in
detail. You seem to be incapable of doing that with HLA. This means
you either don't know difference, or you're lying about there being a
difference. All of this hand waving about cats and dogs just shows
that you can't back up your claims with provable facts.
> The definitions of the words: Assembler, Symbolic Assembler,
> Macros Symbolic Assembler, compiler for Assembly Language,
> HLL, VHLL, do not need to be reviewed for pleasing master
> Pdf swindlings. These definitions are known, fixed, and have
> been debated to death, here, and in other places.
If the definitions are so well known and fixed, you shouldn't have any
problem giving me a list that everyone agrees on. Of course, if
they've been debated to death, that suggests the definitions aren't as
fixed in reality as they are in your mind.
> So, i fail to understand where you mean to go, with your
> absurd questions, now that HLA has stopped matching with the
> definition of an "HLL Pre-parser" for enhancing to the status
> of HLL.
I just want to understand. You make so little sense that I have to ask
"absurd questions" to figure out the absurd answers you give me.
> > 2) Why could the HLA language never be assembly?
>
> The _Language_? You mean... the way for physicaly writing
> an Assembly Statement? Whatever absurd writing convention
> (notation) it would inflict on people, a Asm Statement is
> an Asm Statement.
An asm statement is an asm statement because an asm statement is an
asm statement? You're like a walking dictionary of logical fallacies,
Rene.
> And then? Does an Asm Statement, as found
> in so many HLLs, make any _HLL-Language_ Assembly Language?
No, for reasons which I've already stated in this thread.
Betov
news:1182452662....@k79g2000hse.googlegroups.com:
> I don't think you understand. The HL constructs that HLA supports are
> *optional*. FASM supports HL constructs too, also in the form of
> macros
> supplied with the assembler.
Much evidently _you_ do not understand.
All (most) actual Assemblers around come with a Macros System.
The one of FASM is, no contest, the most powerful one, even
though complicated to program.
You seem to not understand the difference in between a User
Macros System, and embeeded Macros. So, the simpler way for
you to open your eyes, is to take the very first example of
an HLA program (pure HLL Source). To try to remove the HLLisms
the way you think it possible to do, and try to re-write all
of those HLLisms, by _yourself_ with the HLA Macros System.
As a result, you should have a Source, with macros for the
HLLisms that you use, followed by the very same program as
previously, but _not_ making use of the HLA embeeded macros.
Good luck and courage.
:)
Betov.
Betov
news:1182453491.2...@c77g2000hse.googlegroups.com:
> If the definitions are so well known and fixed, you shouldn't have any
> problem giving me a list that everyone agrees on
Again ?! Well, here we go:
Level 1: An Assembler is a Programming Tool that translates
Processor Mnemonics based Instructions into Binary
Code.
Level 2: A Symbolic Assembler is an Assembler translating
Data and Code Labels and references into Addresses
and displacements
Level 3: A Macro Assembler is a Symbolic Assembler offering
Macros and Equates substitutions features.
Level 4: An Assembly Compiler is a Macro Assembler that
includes hidden Macros.
Level 5: An HLL is a Compiler that frees the programmer from
having to deal with the Mnemonics.
Level 6: A VHLL is an HLL offering buit-in features covering
specific tasks.
Period. Flat enough?
Levels 1, 2, 3 _are_ Assemblers.
Levels 5 and 6 are HLLs.
Level 4 is an intermediate, that can be _used_, if the programmer
understand what the Compiler does (...), as well as an Assembler
or (partially) as an HLL. Notice that an "Assembly Compiler"
(a Compiler for Assembly Language), is something like _MASM_.
Betov.
Julienne Walker
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182452662....@k79g2000hse.googlegroups.com:
Well, the first HLA program from AoA is this:
program helloWorld;
#include( "stdlib.hhf" );
begin helloWorld;
stdout.put( "Hello, World of Assembly Language", nl );
end helloWorld;
To do what you're asking, all I need is to download the HLA standard
library source code (which is written in HLA), copy the macros to make
stdout.put functional without using the standard library itself, and
paste them directly into the program. Voilà. I'm no longer using the
embedded macros and the program does exactly the same thing. I'd
estimate about 10 minutes of work, most of that caused by locating the
macros I need.
Betov
news:1182454950.0...@c77g2000hse.googlegroups.com:
> paste them directly into the program. Voilą. I'm no longer using the
> embedded macros and the program does exactly the same thing. I'd
> estimate about 10 minutes of work, most of that caused by locating the
> macros I need.
Do not play the nerd with me. Do it, and come back when you are done.
Betov.
Julienne Walker
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182453491.2...@c77g2000hse.googlegroups.com:
Excellent! Finally you give me a straight answer. So at last we can
agree that HLA is an assembly language because the HLA compiler meets
the requirements for level 4, but fails to meet the requirements for
level 5.
Now, I can see you arguing that HLA meets the requirements for level 5
because the hidden macros free the programmer from having to deal with
the mnemonics. So I'll save us a couple of posts and address that
opinion right now.
If using hidden macros is level 5, that means you categorized MASM
incorrectly. That alone means you're confused even when using your own
categories and that means your categories are probably invalid. I
would also argue that 1) level 5 isn't achieved unless you're _forced_
to be free from the mnemonics by the language syntax (which HLA
doesn't do) and 2) the whole point of a macro is to abstract away the
mnemonics into something more convenient.
So if you choose to go that route, you have two options. First, admit
that HLA does indeed meet level 4 but not level 5, and as a result is
an assembly language because level 4 is "a Compiler for Assembly
Language". Or second, since the point of macros is to free the
programmer from the mnemonics, merge levels 3, 4, and 5. The resulting
options are fairly simple:
1) HLA is an assembly language because it doesn't meet level 5
2) HLA is an assembly language because RosAsm is an assembly language
and RosAsm is an assembly language because you merged down, so both
are at level 3
3) HLA is not an assembly language because it's at level 5, but
neither is RosAsm because you merged up and now RosAsm is at level 5
too.
So with simple logic, you can admit that HLA is an assembly language,
or be forced to admit that your own RosAsm is *not* an assembly
language. :-) Of course, I fully expect more hand waving and dodging.
Betov
news:1182456582.6...@q75g2000hsh.googlegroups.com:
> If using hidden macros is level 5, that means you categorized MASM
> incorrectly.
If you do not even know that MASM has embeeded Macros, and
therefore, disqualifies itself as an Assembler, this is not
my fault. That being said, MASM is generaly considered as an
Assembler, even though it does not output what you write,
because it is simply admitted (wrongly) to be one. Power of
tradition over logic.
> That alone means you're confused even when using your own
> categories and that means your categories are probably invalid. I
> would also argue that 1) level 5 isn't achieved unless you're _forced_
> to be free from the mnemonics by the language syntax (which HLA
> doesn't do)
C does not force you to be free from the Mnemonics, and nobody
calls C an Assembler. And C has the _HUGE_ advantage on HLA,
that, when doing inline Assembly, one knows what he is doing,
because he can _SEE_ it.
Betov.
Herbert Kleebauer
> On Jun 21, 2:36 pm, Herbert Kleebauer <k...@unibwm.de> wrote:
> > Do you really think you have learned French just because you can
> > write complicated English sentences with a few words replaced
> > by the French version? Better start with very easy sentences completely
> > written in French.
>
> Allow me to make a more accurate analogy. Let's say you're a native English
> speaker and want to learn Japanese. You already know a bit of Spanish.
> You can use the fact that Spanish grammar is similar in build to Japanese
> grammar and learn more quickly. This is leveraging existing knowledge to
> pick up the pace of learning. However, Japanese grammar is different, so
> you would still need to keep it simple while learning. This is equivalent
> to learning the basic instruction set and working with simple programs.
>
> Once you're comfortable with the basics, you can then learn more of the
> nuances of Japanese grammar. This is equivalent to digging down into a
> more complete understanding of assembly programming, picking up more
> advanced instructions and techniques, and building larger and more
> complicated programs. Of course, you get to this point faster because
> you used your existing knowledge of Spanish to learn Japanese more
> quickly.
>
> You didn't learn Japanese by intermingling Japanese and Spanish. You
> learned Japanese by taking advantage of similar concepts from Spanish
> to save yourself the trouble of relearning something you already knew.
You again mix up things. If you already know Spanish and there are
similarities between Spanish and Japanese, then this surely gives
you an advantage compared to people who don't know Spanish. But it
would be nothing but silly to start the first lesson in Japanese
with a Spanish sentence with the motivation that the student want
to start as early as possible writing text and because they don't
know any Japanese at the moment we use Spanish instead:
program helloWorld;
#include( "stdlib.hhf" );
begin helloWorld;
stdout.put( "Hello, World of Assembly Language", nl );
end helloWorld;
Then later we introduce more and more Japanese words and in the
last lesson they maybe are able to write a sentence without any
Spanish words.
Once you have to introduce the very first Japanese word (CPU instruction).
Let's say we start with the move instruction:
The CPU has 8 32 bit registers, the first 4 of this registers (r0-r3)
can be accessed as a byte (8 bit), word (16 bit) or long (32 bit)
register. There is a MOVE instructions which allows to move an
immediate constant into the registers and to move the content from
one register to an other.
Now explain why you need any Spanish (HLL code) to allow the students
to test this instructions? Just generate a text file with the content:
move.l #$12345678,r0
move.l r0,r1
move.w #$abcd,r1
move.l r1,r2
move.b #$00,r2
assembly it and executed it within the debugger:
(sp.w): 0000
r0: 00000000 00001fd9 000000ff 00020000 r4: 00000912 00000100 83c5fffe 0000fffe
pc: 00000100 s0:1fd9 s1:1fd9 s2:0000 s3:0000 s6:1fd9 s7:1fd9 sr: 00003202
1fd9 : 00000100 move.l #$12345678,r0 (66 b8 78 56 34 12)
1fd9 : 00000106 move.l r0,r1 (66 89 c2)
1fd9 : 00000109 move.w #$abcd,r1 (ba cd ab)
1fd9 : 0000010c move.l r1,r2 (66 89 d1)
0000:00000000>
(sp.w): 0000
r0: 12345678 00001fd9 000000ff 00020000 r4: 00000912 00000100 83c5fffe 0000fffe
pc: 00000106 s0:1fd9 s1:1fd9 s2:0000 s3:0000 s6:1fd9 s7:1fd9 sr: 00003202
1fd9 : 00000106 move.l r0,r1 (66 89 c2)
1fd9 : 00000109 move.w #$abcd,r1 (ba cd ab)
1fd9 : 0000010c move.l r1,r2 (66 89 d1)
1fd9 : 0000010f move.b #$00,r2 (b1 00)
0000:00000000>
(sp.w): 0000
r0: 12345678 12345678 000000ff 00020000 r4: 00000912 00000100 83c5fffe 0000fffe
pc: 00000109 s0:1fd9 s1:1fd9 s2:0000 s3:0000 s6:1fd9 s7:1fd9 sr: 00003202
1fd9 : 00000109 move.w #$abcd,r1 (ba cd ab)
1fd9 : 0000010c move.l r1,r2 (66 89 d1)
1fd9 : 0000010f move.b #$00,r2 (b1 00)
1fd9 : 00000111 nop (90)
0000:00000000>
(sp.w): 0000
r0: 12345678 1234abcd 000000ff 00020000 r4: 00000912 00000100 83c5fffe 0000fffe
pc: 0000010c s0:1fd9 s1:1fd9 s2:0000 s3:0000 s6:1fd9 s7:1fd9 sr: 00003202
1fd9 : 0000010c move.l r1,r2 (66 89 d1)
1fd9 : 0000010f move.b #$00,r2 (b1 00)
1fd9 : 00000111 nop (90)
1fd9 : 00000112 nop (90)
0000:00000000>
(sp.w): 0000
r0: 12345678 1234abcd 1234abcd 00020000 r4: 00000912 00000100 83c5fffe 0000fffe
pc: 0000010f s0:1fd9 s1:1fd9 s2:0000 s3:0000 s6:1fd9 s7:1fd9 sr: 00003202
1fd9 : 0000010f move.b #$00,r2 (b1 00)
1fd9 : 00000111 nop (90)
1fd9 : 00000112 nop (90)
1fd9 : 00000113 nop (90)
0000:00000000>
(sp.w): 0000
r0: 12345678 1234abcd 1234ab00 00020000 r4: 00000912 00000100 83c5fffe 0000fffe
pc: 00000111 s0:1fd9 s1:1fd9 s2:0000 s3:0000 s6:1fd9 s7:1fd9 sr: 00003202
1fd9 : 00000111 nop (90)
1fd9 : 00000112 nop (90)
1fd9 : 00000113 nop (90)
1fd9 : 00000114 nop (90)
0000:00000000>
There is absolutely no need for any HLL constructs or any "stdlib".
And each new introduced Japanese word (CPU instruction or addressing
mode) can immediately be tested in the debugger. And after a few instructions
(move, add, sub, and, or, br, bsr, rts) they will be able to write
first meaningful programs (without any HL code or "HLA stdlib").
> > Again, what is added outside my code doesn't matter. It's the code
> > I write which matters. If you use inline assembly in C, then you
> > normally have a clearly separated piece of code and within this
> > code you do assembly programming. But in HLA there is a directly intermix
> > of HL constructs and CPU instructions and you cant say from page 1 to 10
> > is HL code and from page 11 to 13 assembly code.
>
> If you remove the HL constructs, it's all assembly code.
Yes, and if you remove the HL part from the HLA language specification
then HLA becomes an assembler. If you don't use HL constructs in your
HLA source code, then your source is an assembler program but this doesn't
make HLA an assembler. If you don't switch on the motor of a motor saw,
then you can use it as a hand saw but that doesn't mean that it isn't
a motor saw anymore. You have to distinct between what "something" is
and how this "something" is used.
Betov
@unibwm.de:
> If you don't switch on the motor of a motor saw,
> then you can use it as a hand saw but that doesn't mean that it isn't
> a motor saw anymore.
:))
I love this idea. I imagine Julienne sawing a tree with
a motor saw without runing the engine:
Lock the chain first, Julienne !...
:))
Betov.
Julienne Walker
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182456582.6...@q75g2000hsh.googlegroups.com:
>
> > If using hidden macros is level 5, that means you categorized MASM
> > incorrectly.
>
> If you do not even know that MASM has embeeded Macros, and
> therefore, disqualifies itself as an Assembler, this is not
> my fault. That being said, MASM is generaly considered as an
> Assembler, even though it does not output what you write,
> because it is simply admitted (wrongly) to be one. Power of
> tradition over logic.
Just as a thought, hand waving. I was truly hoping you would at least
try to make an entertaining argument, but with your track record, I
really wasn't expecting much.
> > That alone means you're confused even when using your own
> > categories and that means your categories are probably invalid. I
> > would also argue that 1) level 5 isn't achieved unless you're _forced_
> > to be free from the mnemonics by the language syntax (which HLA
> > doesn't do)
>
> C does not force you to be free from the Mnemonics, and nobody
> calls C an Assembler. And C has the _HUGE_ advantage on HLA,
> that, when doing inline Assembly, one knows what he is doing,
> because he can _SEE_ it.
I have bad news for you, but inline assembly is *not* a part of the C
programming language. So C does indeed force you to be free from the
mnemonics, because there's no way using the C language to use an
assembly mnemonic.
//\\\o//\\annabee
<happy...@hotmail.com> wrote:
>
> The difference is that with HLA, you *can* remove the extra code that
> the compiler adds. So there's no logical way to describe HLA as inline
> assembly because there's no embedding going on.
Are you drunk? Why use HLA, if it can be removed????
Julienne Walker
> Julienne Walker wrote:
> > On Jun 21, 2:36 pm, Herbert Kleebauer <k...@unibwm.de> wrote:
I'm not going to quote any thing because you clearly have no idea what
I'm talking about.
Betov
news:1182461776.2...@p77g2000hsh.googlegroups.com:
>> If you do not even know that MASM has embeeded Macros, and
>> therefore, disqualifies itself as an Assembler, this is not
>> my fault. That being said, MASM is generaly considered as an
>> Assembler, even though it does not output what you write,
>> because it is simply admitted (wrongly) to be one. Power of
>> tradition over logic.
>
> Just as a thought, hand waving. I was truly hoping you would at least
> try to make an entertaining argument, but with your track record, I
> really wasn't expecting much.
Outchhh... Is it my job to recommend you to state, for example,
a RET, inside a MASM Procedure, and to take a look at the
Disassembly? To analyse what it does with Stack Variables?
and so on?...
Well...
Betov.
Betov
news:1182461776.2...@p77g2000hsh.googlegroups.com:
> I have bad news for you, but inline assembly is *not* a part of the C
> programming language.
Of course, it is, in some way "out" of the Language, like
an Escape sequence. And then? How is it "bad news for me"?
> So C does indeed force you to be free from the
> mnemonics,
No. It does not, by the grace of Inline Asm.
> because there's no way using the C language to use an
> assembly mnemonic.
Which is a quite good thing, because it makes a clear
difference in between what is Assembly and what is not
Assembly. The perfect tool for learning Inline Assembly,
as opposed to HLA.
Betov.
Betov
news:1182462653.9...@m36g2000hse.googlegroups.com:
Whooo, Whooo, Whooo, Julienne. Personaly, i agrea on very few
points with Herbert, and we could very well be able to have
bloody debates together. But for sure, there is something that
i would never tell him, that is that he "has no idea about",
and be 100% sure that he has way more "ideas about" than you
will ever have.
Betov.
//\\\o//\\annabee
wrote:
> "Julienne Walker" wrote:
> : It [inline assembly] *has* to be embedded in the higher level language,
>
> That statement is wrong. It probably should get stated as:
> "Inline assembly *has* to get embedded in another language,..."
> but even that one can punch holes in.
>
> Explain please.
> Ok. <g>
>
> If an IF statement compiles directly to a CMP / Jcc macro, it ends up
> as assembly language. It requires the individual to know the particular
> the specific implications involved by the IF macro. The end result is
> that
> the IF simplifies things and the end user needs to worry less about the
> resulting flags (possibly).
>
> Higher and lower are opinionated words, sometimes, and maybe
> should be avoided. Many of the posts that Randy and others present
> involves their own special definitions of higher and lower (and no one
> should really care as one MACRO changes an assembly language
> compiler from a low level language to a high level language, even
> though that compiler is both!).
>
> If IF makes a language a high level language but IF safely recurses
> it's implementations in a low level language, and if the low-level
> language is assembly language, the end result is a low-level language
> that the developer knows evolved from a high-level language
> construct written in a low-level language as an "inline high-level
> language construct". If you and the compiler can safely recurse
> the definitions of high-level, low-level and IF, congratulations!
>
> That's all I have to say about that.
Very good post Jim.
If you generate yourself, the exact code, and that code does not change
behind your back, without you having the possibility of knowing about it,
and changing it to the extact sequence you can tolerate, then it is
assembly. Otherwise it is not.
Not even the one to one is a truly good _REAL_ argument. It is not if its
one to one, but whether it has the _possibility_ (ease of freedom) of one
to one. (exact what you want). -No program written by any programmer of
some size, is able to be 100% one to one, unless it is a trivial program.
All programmers must learn to accept some compromises, between time spent,
memory used, speeed, code reuse verses code bloat, calling verses macros,
copy/paste and etc. and time to study and test new approaches to do
things. E.g if one routine must serve 3 clients, and 3 sligthly diffrent
purposes, it must be generalizes somewhat. The other alternative is to
bloat the code by writing 3 sligthly diffrent routines. But at the benefit
of 3 less complicated to read once. Comprimises also for macros. Macros
expand and creates more code then routines. In some cases. like the if
macro, there is simply no good argument against, so long as you know what
your doing. In other cases, with longer macros, like the one I wrote in
the very beginning, and some that I still have left to change, they create
more code then would be best.
Aside from the weird fun, I find this whole discussion a bit rediclous.
And far from reality. Because, in the real life, we never can do 100% what
we think is the best. We can only do our own best, and only if we work
extremly hard on it. And sometimes, working extremly hard is just isnt
worth it. So in some situations, a compromise, even when regretted, can be
the _accurate_ way to go. But theese issues have really very short scope
outside discussion for its own sake. Because, even if a prog is written
100% in asm, if nobody wants it, cant use it for anything .... :))))
Anyway, I guess its ontopic here so whatever.....
;)
//\\\o//\\annabee
<happy...@hotmail.com> wrote:
> I have bad news for you, but inline assembly is *not* a part of the C
> programming language. So C does indeed force you to be free from the
> mnemonics, because there's no way using the C language to use an
> assembly mnemonic.
It so happens, that I seem to be reading your language better then you do.
Level 5: An HLL is a Compiler that _frees_ the programmer from
_having_ to deal with the Mnemonics.
What that so difficult ?
:))))
kistj...@excite.com
> Julienne Walker <happyfro...@hotmail.com> écrivaitnews:1182453491.2...@c77g2000hse.googlegroups.com:
>
> > If the definitions are so well known and fixed, you shouldn't have any
> > problem giving me a list that everyone agrees on
>
> Again ?! Well, here we go:
>
> Level 1: An Assembler is a Programming Tool that translates
> Processor Mnemonics based Instructions into Binary
> Code.
>
> Level 2: A Symbolic Assembler is an Assembler translating
> Data and Code Labels and references into Addresses
> and displacements
>
> Level 3: A Macro Assembler is a Symbolic Assembler offering
> Macros and Equates substitutions features.
>
> Level 4: An Assembly Compiler is a Macro Assembler that
*the appropriate word here is built-in. We do have the functionality
of macro expansion prior to assembly at our disposal.
> Level 5: An HLL is a Compiler that frees the programmer from
> having to deal with the Mnemonics.
>
> Level 6: A VHLL is an HLL offering buit-in features covering
> specific tasks.
>
hmm, let me see... last time I checked, HLA did still support the x86
instruction set natively. Therefore, it should be able to seamlessly
do the four levels our frenchie outlined. So let's check.
level 1? can do that
level 2? can do that
level 3? can do that
level 4? can do that
...and all without the requirement to invoke bookkeeping/helper code
or a runtime lib.
Conclusion: HLA qualifies as an assembler.
rand...@earthlink.net
> > > On Jun 21, 2:36 pm, Herbert Kleebauer <k...@unibwm.de> wrote:
>
> I'm not going to quote any thing because you clearly have no idea what
> I'm talking about.
Actually, a good part of the time he has no idea what he's talking
about, as well.
hLater,
Randy Hyde
rand...@earthlink.net
>
> It gets really old after a while, and it's been a VERY long while.
Jim, as much as you like to complain about these arguments, I do
notice that most of *your* posts are engaging in the very same, as
well as similar, religous arguments.
hLater,
Randy Hyde
//\\\o//\\annabee
Sure. Thats how he created the most useable assembler, ever seen on win32.
> hLater,
> Randy Hyde