HLA's src,dst operand syntax 
Author Message
 HLA's src,dst operand syntax

Randall,

I really don't like to talk in these "accusation" terms, but.. a very
sad thought crossed my mind.

HLA's src,dst operand syntax.. akward one.. whatever were your reasons
to choose it, they fall once you affirm that you wrote HLA to make
people's job of learning asm easier, because when they will have learnt
it, they will get extremely confused into using assembly (usual x86
assemblers), and will HAVE TO stick with HLA even just because of src,dst
syntax. So most of them won't have any wish to use an assembler, and will
stick with something else, HLA, which is a MLL/HLL language more oriented
to inline "asm" than other HLL's, yet it's NOT asm.

So what you're really concerned to is not teaching asm, it's only
teaching HLA and promoting it with any and all means..

Not too fair..



Sun, 03 Jul 2005 17:24:23 GMT  
 HLA's src,dst operand syntax

Quote:

> Randall,

> I really don't like to talk in these "accusation" terms, but.. a very
> sad thought crossed my mind.

> HLA's src,dst operand syntax.. akward one.. whatever were your reasons
> to choose it, they fall once you affirm that you wrote HLA to make
> people's job of learning asm easier, because when they will have learnt
> it, they will get extremely confused into using assembly

Since the beginning of time there have been
  op dest src(s)
  op src(s) dest
and even
  dest op src(s)
syntaces for assembly language. One cannot assert that all assembly
languages use the same conventions, it'a plainly not true.

Quote:
> (usual x86
> assemblers), and will HAVE TO stick with HLA even just because of
> src,dst syntax.

Does the fact that the first language I learnt, and used for many years,


and '%' as _prefices_ on variables to denote their type.

The answer's "no", by the way.

You seem to have the mindset of someone who either only ever wants to
program in one language.

Quote:
> So most of them won't have any wish to use an assembler, and will stick
> with something else, HLA, which is a MLL/HLL language more oriented to
> inline "asm" than other HLL's, yet it's NOT asm.

It's architecture dependent, to such an extent that there is a 1-1
correspondence between architectural features and HLA features on th whole
(for example registers and opcodes). I'd have thought that was
justification enough to call it an assembler.

Quote:
> So what you're really concerned to is not teaching asm, it's only
> teaching HLA and promoting it with any and all means..

If Randall were to have chosen one particular established convention, then
other people would have accused him of favoratism towards its originator.
i.e. no matter what he chose to do someoe would be able to criticise him
for his choice.

I admit he was 'brave' for creating a new syntax, but sometimes the field
needs a bit of a shake-up in order to prevent stagnation. If more people
become familiar with low-level proramming on the PC because HLA provides
more high-level features than other assemblers, then that would certainly
be a 'good thing' IMHO.

Once people are familiar with the architecture upon which they're
programming, the exact syntax of the assembler they use becomes only a
secondary issue, almost a 'religeous' one. (e.g. I still think the /one
true way/ to program x86 is using Zortech C's inline asm pragmas, but I
know this is puts me in quite a small minority.)

The main reason I have problems writing x86 nowadays is not the syntax of
the various solutions that are available to me, viz. gcc/gas, Nasm, HLA,
each of which has a _completely_ different syntax, but simply that I've
become unfamiliar with the architecture (or the architecture has become
unfamiliar to me, I've stayed where I was 8 years ago, and the
architecture's moved on).

Quote:
> Not too fair..

Exactly, but you're forgiven.

Phil



Sun, 03 Jul 2005 23:41:41 GMT  
 HLA's src,dst operand syntax

"Phil Carmody" mentioned:
[...]
| Since the beginning of time there have been
|   op dest src(s)
|   op src(s) dest
| and even
|   dest op src(s)
| syntaces for assembly language. One cannot assert that all assembly
| languages use the same conventions, it'a plainly not true.

I don't know about the text-oriented ASM/Compiler pairs,
but as I write code for many different CPUs,
I use equal syntax for all of them.

In the order:  LD(load) OPERATION, DESTINATION/SOURCE  
               ST(store)                SOURCE/DESINATION  

| It's architecture dependent, to such an extent that there is a 1-1
| correspondence between architectural features and HLA features on the whole
| (for example registers and opcodes). I'd have thought that was
| justification enough to call it an assembler.

I don't think the syntax order depends on the CPU's architecture.
You may write "MOV [whatever],EAX"
           or "ST EAX,[whatever]" which I prefer.

The doubled codes on IA-CPUs may be confusing,
           MOV EAX,ECX  = 8b c1  ="LD EAX,ECX"
           MOV EAX,ECX  = 89 c8  ="ST ECX,EAX"
So the IA-xx "MOV"-syntax mainly tries to use destination <- source order.

__
wolfgang



Mon, 04 Jul 2005 00:11:37 GMT  
 HLA's src,dst operand syntax

Quote:

> Randall,

> I really don't like to talk in these "accusation" terms, but.. a very
> sad thought crossed my mind....
> [...]

:)) Afraid of being censored at the Evil Board, Mike??? :))

Betov.

PS1. If the unjustified (AFAIK) reversed order was the only one thing...

PS2. Randy, you were right with the timing of the hard-decoding for
FPU Real10: They are 5 to 10 times slower than usual ones... Too bad ;).



Mon, 04 Jul 2005 03:15:47 GMT  
 HLA's src,dst operand syntax

Quote:


> > Randall,

> > I really don't like to talk in these "accusation" terms, but.. a very
> > sad thought crossed my mind....
> > [...]

> :)) Afraid of being censored at the Evil Board, Mike??? :))

???

Talk more explicitly please, I don't get what you mean.

Quote:
> Betov.

> PS1. If the unjustified (AFAIK) reversed order was the only one thing...



Mon, 04 Jul 2005 07:11:52 GMT  
 HLA's src,dst operand syntax


Quote:

> > Randall,

> > I really don't like to talk in these "accusation" terms, but.. a very
> > sad thought crossed my mind.

> > HLA's src,dst operand syntax.. akward one.. whatever were your reasons
> > to choose it, they fall once you affirm that you wrote HLA to make
> > people's job of learning asm easier, because when they will have learnt
> > it, they will get extremely confused into using assembly

> Since the beginning of time there have been
>   op dest src(s)
>   op src(s) dest
> and even
>   dest op src(s)
> syntaces for assembly language. One cannot assert that all assembly
> languages use the same conventions, it'a plainly not true.

<..big cut..>

This is not relevant in this case, because the x86 assemblers more
than typically use dst,src syntax (let away that it's the Intel
official one), and anyway that's the "standard".

So if you have to program in *assembly*, you will have to use that
syntax on a standard assembler.. unless you stick with HLA.

But then again this way you've promoted HLA, not assembly.. and Randy
said that HLA's aim was to introduce people to asm (ergo, to then let
them continue with the Real Thing (tm), assembly.. a very noble intent
for which Randy has been eventually rightly respected).

Now, if HLA was a multi-platform product (meant in "for many different
CPU's") I would have no problem with the src,dst syntax (besides that
it's awkward, and I've been programming for many, many CPU's, CISC and
RISC).. but HLA is only for the x86..

I think you're wrong when you say that one syntax is as good as another.
If somebody is a *beginner*, he/she will get used to a certain syntax..
and he/she will have no stimulus to change his/her habits.. expecially
if that means that he/she has to invert his/her mind (dst<->src), which
would be very stressing. Which beginner would then do that? Why?

So, I wonder, did Randy make HLA this way to promote asm, or just to
promote his HLA? Because forcing students to stick forever with HLA is
not that fair for somebody who wants to promote *asm*.

Now, promoting *asm* is certainly a thing that deserves the maximum
of respect, but promoting HLA in my opinion is like promoting yourself,
and certainly doesn't help the asm cause that much.

Sorry for the polemic.. but this is a thought that has tormented my sleep..



Mon, 04 Jul 2005 07:11:53 GMT  
 HLA's src,dst operand syntax

Quote:

>Since the beginning of time there have been
>  op dest src(s)
>  op src(s) dest
>and even
>  dest op src(s)
>syntaces for assembly language. One cannot assert that all assembly
>languages use the same conventions, it'a plainly not true.

As another variation, for those of us who write assembly for
Forth-based assemblers, it's often:  src dest op

Ed



Mon, 04 Jul 2005 08:19:41 GMT  
 HLA's src,dst operand syntax

Quote:

> Randall,

> I really don't like to talk in these "accusation" terms, but.. a very
> sad thought crossed my mind.

That's okay, many such thoughts crossed my mind during HLA's development :-)

Quote:

> HLA's src,dst operand syntax.. akward one..

Only to those who already know an Intel-syntax assembler like MASM.
HLA was not designed for this people, so it hardly matters.

Quote:
> whatever were your reasons
> to choose it, they fall once you affirm that you wrote HLA to make
> people's job of learning asm easier, because when they will have learnt
> it, they will get extremely confused into using assembly (usual x86
> assemblers), and will HAVE TO stick with HLA even just because of src,dst
> syntax.

Not really, they could also use Gas or TLA (if you can still find it) which uses the src,dest
syntax.

Quote:
> So most of them won't have any wish to use an assembler, and will
> stick with something else, HLA, which is a MLL/HLL language more oriented
> to inline "asm" than other HLL's, yet it's NOT asm.

????

Why is HLA not an assembler because the operands are reversed?
There are far more assemblers out there (on other architectures) that use the
src, dest syntax than there are assemblers that use the dest,src syntax.
By your reckoning, anyone who learns Intel syntax would never be able to write
code on a different CPU if the assembler for that CPU uses src,dest syntax (which,
if my count is correct, most of them do).

Quote:

> So what you're really concerned to is not teaching asm, it's only
> teaching HLA and promoting it with any and all means..

> Not too fair..

Yeah, and I get people complaining that I rewrote AoA/32-bits as a vehicle to promote HLA
and that's not fair either :-).  The truth is, I designed and wrote HLA specifically to support AoA
and other assembly language documentation I was dreaming up, not the other way around.
And while I argue that once someone masters the assembly language programming paradigm with
HLA, picking up MASM/FASM/NASM/etc. syntax is a near no-brainer.  Any competent programmer
should be up and running with a different assembler within a week (or less).  On the other hand,
why do I care if they switch.  I didn't design HLA to serve as a MASM substitute.  While there are
some good reasons for learning MASM (or some other "dest,src" syntax assembler) once you know
HLA, the truth is that HLA does just about anything someone would want to do with an x86 assembler.
So why would they want to change?  Sure, maybe a job would require coding in MASM or maybe some
sample code appears in MASM, etc.  But I could make the same arguements for wanting to switch
from MASM to HLA.  E.g., had a book taught MASM and the reader wanted to access some HLA
code, they'd have to learn HLA.  Unlike a lot of other "free" assemblers that are available, HLA does
have one big advantage:  it has a very rich feature set.  Therefore, there is little need for someone to
even *want* to switch to one of these other assemblers as their expertise grows.  HLA, from a feature
set point of view, it far more  powerful than MASM/TASM, both of which are far more powerful than
Gas/NASM/FASM and other such assemblers.  So it's not like teaching them assembly language with
HLA "locks" them into some inferior product that they will quickly outgrow.  Quite the opposite, really.

BTW, there are several semantic reasons for choosing the "src,dest" syntax in addition to the pedagogical
reasons.  But unless you've *really* learned HLA (and especially the compile-time language), it's difficult
to understand the advantages of using the "src,dest" syntax.  As I've said many times in this newsgroup
(and comp.lang.asm.x86) many times over the past couple of years -- the decision to go with the "src,dest"
syntax was not make lightly.  I knew from day one that this criticism would pop up all the time.  However,
when I considered all the advantages, they outweighed sticking with the "dest, src" syntax that Intel chose
to use.
Randy Hyde



Mon, 04 Jul 2005 12:09:31 GMT  
 HLA's src,dst operand syntax


Quote:
> Talk more explicitly please, I don't get what you mean.

Ah! Then you are not the "Evil-Board's Mike" i thought about. Excuse me.

For the other things with HLA, all this discussion has already be done,
and the answers of Randy have always been the same. So, going on with
this is of very little use. As you may see in his actual answer, for
examples:

Quote:
>The truth is, I designed and wrote HLA specifically to support AoA
>and other assembly language documentation I was dreaming up, not the
>other way around.

... Not new, but yet so amaizing to me. I already answered to this,
in another thread: "Next time you are going to re-write it all for
supporting the 'ReadMe.txt' ;)"

Quote:
>the truth is that HLA does just about anything someone would want to
>do with an x86 assembler. So why would they want to change?
>Unlike a lot of other "free" assemblers that are available, HLA does
>have one big advantage:  it has a very rich feature set.  Therefore,
>there is little need for someone to even *want* to switch to one of
>these other assemblers as their expertise grows.

This is to say that Randy clearly hopes (he already said, that, in a
couple of years HLA will be the more -or one of the more- in use
Assembler) to win the actual competition between all the actual offers.
In my opinion, even if books are published with HLA, HLA has not any
tinier chance of success. The guys are not so stupid, and making up
their mind that HLA is not an Assembler at all, will take them just a
couple of days, even if they have bought the book(s).

Quote:
>unless you've *really* learned HLA (and especially the compile-time
>language), it's difficult to understand the advantages of using the
>"src,dest" syntax.

Is this an answer to the question? We have yet to hear any clear
explanation for *why* this has been choosen. The less obscure one
Randy ever gave, was that, when teaching to studient, he thought that
they learn faster this way than the other way round. He also thinks
that studients are the Asm programmers for tomorrow, what we have
*never* seen in the past, and i don't see any reason for what we
should ever see this in the futur, until the Open Source Mouvement
defeats the Market Companies...

Now, the syntax of HLA is nothing but a detail in the overall problem:

The real problem is with the Programming Philosophia. HLA, clearly
pushes to C-Like programming. This is to say:

- Procedures.
- Reusable Code.
- Libraries.
- Typings, and friends.
- ... and all the so called "features" that appear in such languages,
and that completely defeat the purpose and the massive advantages of
Asm on all other Languages.

When Randy says:

Quote:
>HLA, from a feature set point of view, it far more  powerful than
>MASM/TASM, both of which are far more powerful than Gas/NASM/FASM and
>other such assemblers.

To me, -who consider MASM/TASM more Compilers than Assemblers (because
of their internal Macros that are so much confusing people)-, this is
to be directely translated into:

- Gas/NASM/FASM and other such assemblers are Assemblers.
- MASM/TASM are Compilers.
- HLA is one another HLL, that is not powerfull enough to write a
complete Application without any Asm statement.

A real HLA will exist, the day when we will have an Assembler (a *real*
Assembler...) full featured with all the integrated tools, that any
actual HLL provides (Complete IDE/RAD, with integrated Editors, De{*filter*},
Click-and-run Wizards, and so on). This is what i am doing with SpAsm:

< http://www.*-*-*.com/ ;

So said, my HLA version will not compete with the other Assemblers, but
with the other HLL Languages. There will always be some room for one or
two real Low-Level-Assembler(s), like NASM or FASM, for OS programming,
for example. The wish of Randy, for winning all of the "Market Place:)"
is nothing but "self-power-realisation"... Hopefully, this will never
satisfy the needs and requirements of the users, because the ones who
need real low level for real low level programing will not like it, and
the ones who want an HLL alternative for Applications programming will
also not find, with Randy HLA, the tools and friendly features they may
hope in an evoluated programming tool. The time Randy spends at covering
all of existing Assemblers outputs, at covering Win32, plus Linux, plus...
is time he will not spend at developing these required tools, and, as
life has an end... (long life to you Randy ;) but i think that i will
be over with SpAsm Wizards -the very last implementation i will do for
SpAsm- when you will be writing the De{*filter*} for HLA V.2).

Betov.



Mon, 04 Jul 2005 18:49:38 GMT  
 HLA's src,dst operand syntax

Hi Randall, thanks for your honest reply.

Just wanted to clear one thing, in response to your reply:
The reason why I said that HLA is not asm is certainly not because of
the src,dst syntax (I can add GEMA to your list of src,dst assemblers,
BTW). The reason is that HLA is a compiler, and has high level control
structures which get compiled.. this is great, absolutely.. but it's not
asm and if then one of your students gets asked to write some x86 system
routine (e.g. a device driver) in MASM/TASM/FASM/NASM he'll have a very
hard time to do that, once he got used to HLA (which is a great language,
but it's not an assembler.. it's a HLL that gets compiled). IMHO this
could nullify in practice most of your (and of the student) efforts..
although I reckon that you've stressed many times that the HLL features
of HLA should be used just to learn, not to keep using them after. As
I said, I liked your reply.. it was an honest one.

Thanks.
Mike

PS: you stimulated in me technical curiosity:

Quote:
> BTW, there are several semantic reasons for choosing the "src,dest"
> syntax in addition to the pedagogical reasons.  But unless you've
> *really* learned HLA (and especially the compile-time language),
> it's difficult to understand the advantages of using the "src,dest"
> syntax.  As I've said many times in this newsgroup (and comp.lang.asm.x86)
> many times over the past couple of years -- the decision to go with the
> "src,dest" syntax was not make lightly.  I knew from day one that this
> criticism would pop up all the time.  However, when I considered all
> the advantages, they outweighed sticking with the "dest, src" syntax
> that Intel chose to use.

I'd like to read about the various pro's and con's of both solutions,
if you've some time to dedicate to this.


Tue, 05 Jul 2005 07:27:57 GMT  
 HLA's src,dst operand syntax

Quote:

> Hi Randall, thanks for your honest reply.

> Just wanted to clear one thing, in response to your reply:
> The reason why I said that HLA is not asm is certainly not because of
> the src,dst syntax (I can add GEMA to your list of src,dst assemblers,
> BTW). The reason is that HLA is a compiler, and has high level control
> structures which get compiled..

So do MASM and TASM.  Does that make them "not an assembler?"

Quote:
> this is great, absolutely.. but it's not
> asm and if then one of your students gets asked to write some x86 system
> routine (e.g. a device driver) in MASM/TASM/FASM/NASM he'll have a very
> hard time to do that, once he got used to HLA (which is a great language,
> but it's not an assembler.. it's a HLL that gets compiled). IMHO this
> could nullify in practice most of your (and of the student) efforts..
> although I reckon that you've stressed many times that the HLL features
> of HLA should be used just to learn, not to keep using them after. As
> I said, I liked your reply.. it was an honest one.

For educational purposes, the IF/WHILE/REPEAT..UNTIL/etc. exist only
so students can get some practical work done during the first few weeks of an
assembly course.  Consider this: a typical University quarter is 10 weeks long.
In such a course, an instructor is expected to teach machine organization (i.e.,
numeric represenation, "baby" computer architecture, boolean logic, etc.) as well
as assembly language.  An instructor who is serious about making sure the students
know the material before they leave the course does not simply tell the students
on the first day of class "Hey, read chapters one through five and write me a program
that converts integers to strings and outputs them, by Friday."  Indeed, I generally
found (back in the days when I was teaching with MASM) that you couldn't get into
any real programming in assembly until about the fourth or fifth week.  There is too much
prerequisite material to cover first (take a look at the 16-bit edition of AoA and then
assume each chapter takes a week to cover, maybe two for chapter three since it's
so long).  That means the students get *five* weeks of programming experience in
assembly language.  Keeping in mind that these students usually have three other courses
and most of them don't want to be in the assembly course, and University regulations typically
allot *10 hours per week* to each course (including lectures, lab, and homework),
you can imagine that having a course that doesn't really get to the meat of the material
until the course is half-way over is a problem.

The thing about HLA is that students get to leverage their existing knowledge right away.
An assembly course almost always has a prerequisite course involving C/C++ or Pascal,
so the fact that HLA uses a syntax reminescent of these languages gives those students
a head start.  You might think it's worthless that they're learning about IFs and WHILEs, etc.,
in an assembly course, but the truth is, they're *not* learning this.  The assumption is that
they already know it.  The few things they have to learn when using these HLL-like statements
is stuff like you can't compare two memory locations directly (i.e., you have to move one value
into a register first) -- exactly the kind of stuff they need to know when they eventually learn
about the CMP instruction.  Of course, IFs and WHILEs and REPEAT..UNTILs do not a
program make.  They've got to learn about variable declarations, registers, etc.  So during the
first week of the course, students can write realistic "assembly" programs using the knowledge
about the x86 they've picked up.  AND THE BEST WAY TO LEARN ASSEMBLY IS BY
PROGRAMMING.  Granted, they're not learning about CMP and conditional jumps yet.  But
they are learning about registers, memory locations, and a small handful of instructions like MOV,
ADD, SUB, etc.  By the time the fifth week rolls around and my previous students are just starting
to write some simple assembly code, the HLA students are writing fairly sophisticated programs.
The bottom line is that at the end of the quarter, the HLA students were writing far more complex
programs *in pure assembly language* than the MASM students were doing.  The fact that
HLA supports statements like IF/WHILE/etc. is irrelevent.  The students weren't using those
statements.

Of course, MASM also supports .if, .while, etc., so why not use MASM instead of HLA?
Well, the truth is, HLA wasn't written to supply IF statements for assembly language programmers.
HLA was written to provide a *much* more powerful macro facility than MASM provides so
that I could provide a "friendlier" face to the "UCR Standard Library for 80x86 Assembly
Language Programmers" (which became the HLA Standard Library in the HLA system).

The other nice thing about HLA is that it provides nicer-looking variable, constant, and type
declarations than you find in typical assemblers (i.e., it uses a Pascal-like syntax).  But variable
declarations have nothing to do with machine code, so it's hard to claim that HLA isn't an
"assembler" just because it lets you declare a variable using "b:byte;" rather than "b db ?" :-)
Anyone who has ever used a high level language before will probably agree that declarations
of the form:

    c:byte[16];

are much nicer than

    c db 16 dup (?)

(that "?" is there for a good reason :-)).

I'm not even willing to discount the fact that HLA supports HLL-like control statements.
Often in NASM and FASM threads you'll see programmers lamenting the fact that these
assemblers don't support IFs and WHILEs like MASM and TASM.  There have been several
macro packages written for these assemblers that attempt to provide this facility.  Alas, the
result is quite weak.  NASM's and FASM's authors can make all the claims they want about
code bloat and how true assembly programmers don't really want that stuff.  My attitude,
pure and simple, is that those who don't want that feature in HLA don't have to use it.
But those who do want to use it, it's nice that the assembler provides it so you don't have
to deal with weak simulation attempts in the macro package.

Of course, when BethTools finally arrives, then we'll have a decent language whose macro
facilities let you truly create HLL-like statements using only the macro subsystem
(HLA's macros are actually powerful enough to do this today, but the implementation of
HLL statements like IF and WHILE would take a tremendous amount of work [assuming
HLA's JF and JT weren't available] and processing the statements would be very slow
in HLA v1.x).
Randy Hyde



Tue, 05 Jul 2005 10:49:29 GMT  
 HLA's src,dst operand syntax

Quote:

> >The truth is, I designed and wrote HLA specifically to support AoA
> >and other assembly language documentation I was dreaming up, not the
> >other way around.

> ... Not new, but yet so amaizing to me. I already answered to this,
> in another thread: "Next time you are going to re-write it all for
> supporting the 'ReadMe.txt' ;)"

Since you've never taught assembly language at the University level,
and are proud of the fact that you don't know, refuse to learn, and would
never use a High Level Language, it's not surprising you would be amazed
by this.  If it makes you feel any better, I did not design HLA for people like you.
I did entertain, at one time, the fantasy that I was writing HLA for advanced
assembly language programmers like myself (since, even ignoring HLA's
HLL-like control structures, HLA's macro facilities and compile-time language
are a quantum leap above what MASM provides, which is much better than
most other assemblers out there, even if it was created by Microsoft :-)).
However, the bottom line is that once someone masters one assembler, they're
very unlikely to change to another one unless the syntax is almost identical to
the one they've learned (e.g., lots of people jumped from MASM to TASM
and there is a small amount of migration from NASM to FASM).
Immediately after the release of HLA, I realised that very few advanced assembly
programmers were willing to switch;  most of the assembly programmers from
my generation (i.e., those programming in assembly in the late 1970's and early 1980's)
don't even use assembly that much any more, so bothering to learn a new assembler
for the little use they'd get from it makes no sense. I'm certainly not out to impress
the NASM hacker who thinks it's truly great that NASM forces them to specify the
displacement size of their instructions.  I'm not even interested in impressing the
assembly hackers who frequent this newsgroup with their loud (and often ill-informed)
opinions.  HLA was designed, conceived, and created for students who are taking
an assembly language programming course.  Even without reasonable pedagogical material,
HLA is beginning to see a lot of use in Universities (this I know, because I get emails from
instructors all the time requesting the use of AoA/32 bits).  That's what HLA was designed
for, and it's succeeding quite well at that (e.g., how many Universities are choosing SpAsm
over HLA?).

Quote:

> >the truth is that HLA does just about anything someone would want to
> >do with an x86 assembler. So why would they want to change?

> >Unlike a lot of other "free" assemblers that are available, HLA does
> >have one big advantage:  it has a very rich feature set.  Therefore,
> >there is little need for someone to even *want* to switch to one of
> >these other assemblers as their expertise grows.

> This is to say that Randy clearly hopes (he already said, that, in a
> couple of years HLA will be the more -or one of the more- in use
> Assembler) to win the actual competition between all the actual offers.
> In my opinion, even if books are published with HLA, HLA has not any
> tinier chance of success. The guys are not so stupid, and making up
> their mind that HLA is not an Assembler at all, will take them just a
> couple of days, even if they have bought the book(s).

Actually, I agree with your statement 100%.  HLA has not any tinier chance
of success.  What it has is a *much* greater chance of success.
I've got a bit of experience in this area, you see.  HLA is not the first assembler
I've written and released.  About 23 years ago I wrote (and sold) an assembler
for the Apple II by the name of LISA (Lazer's Interactive Symbolic Assembler).
The sales were kind of low until I wrote a book on 6502 assembly language
programming ("Using 6502", published by Datamost) and then the sales of LISA
skyrocketed.  Experience with HLA and AoA/32-bits suggests the same pattern.
There was very little interest in HLA (other than threads complaining about it) until
the first couple of sections of the 32-bit edition of AoA started appearing on
Webster.  Immediately, the number of HLA users jumped from the tens to the
hundreds.  Today, I'd estimate the number of people who've started learning and
using assembly language in the thousands (of course, this is a crude estimate based
simply on the number of emails I get each week, the number of schools that use HLA,
and so on, so it could be off either way..).  But still, despite Webster's popularity, I'd
still estimate that most people who decide they want to learn assembly language (or most
instructors who have to teach an assembly course) go to the book store before they
go searching for a site like Webster.  So when AoA appears in print within a few months
here, I expect another leap in the user base.  Maybe you're right;  it might not happen.
But my experience suggests otherwise.

Quote:

> >unless you've *really* learned HLA (and especially the compile-time
> >language), it's difficult to understand the advantages of using the
> >"src,dest" syntax.

> Is this an answer to the question? We have yet to hear any clear
> explanation for *why* this has been choosen. The less obscure one
> Randy ever gave, was that, when teaching to studient, he thought that
> they learn faster this way than the other way round.

Try searching on Google.  I've explained it a couple of times.
Try searching for keywords like "Instruction composition".

Quote:
> He also thinks
> that studients are the Asm programmers for tomorrow, what we have
> *never* seen in the past, and i don't see any reason for what we
> should ever see this in the futur, until the Open Source Mouvement
> defeats the Market Companies...

Uh....
The vast majority of today's programmers were yesterday's students.
There are a handful of self-taught hackers out there, but I'll gladly give
up that crowd to SpAsm.  Until Microsoft came along, Universities almost
always led the commercial marketplace by four years.  Whatever language
the Universities were teaching became the "big" language about four years later
(as those students started graduating).  Universities were the ones that made
Pascal popular, C popular, C++ popular, and so on.  Universities were
also the ones that made Unix and Linux popular (you don't think that the
Open Source Movement came out of the commercial environment, do you?)
The fact that Borland and Microsoft made lots of great licensing deals is
one of the major reasons MASM and TASM became so popular.
Quite honestly, I think you're way off base when you suggest that today's
students aren't tomorrow's programmers (assembly or otherwise).
If this turns out to be true, and tomorrow's assembly programmers are
only going to be the self-taught hackers of today, then assembly language
is truly dead.

Quote:

> Now, the syntax of HLA is nothing but a detail in the overall problem:

> The real problem is with the Programming Philosophia. HLA, clearly
> pushes to C-Like programming. This is to say:

> - Procedures.
> - Reusable Code.
> - Libraries.
> - Typings, and friends.
> - ... and all the so called "features" that appear in such languages,
> and that completely defeat the purpose and the massive advantages of
> Asm on all other Languages.

I will let this statement stand on it's own and allow those reading your
post to judge how seriously they should take you on the basis of this
truly ludicrous statement.

Quote:
> When Randy says:

> >HLA, from a feature set point of view, it far more  powerful than
> >MASM/TASM, both of which are far more powerful than Gas/NASM/FASM and
> >other such assemblers.

> To me, -who consider MASM/TASM more Compilers than Assemblers (because
> of their internal Macros that are so much confusing people)-, this is
> to be directely translated into:
> - Gas/NASM/FASM and other such assemblers are Assemblers.
> - MASM/TASM are Compilers.
> - HLA is one another HLL, that is not powerfull enough to write a
> complete Application without any Asm statement.

HLA *is* a compiler for an assembly language.
Whether or not a translator is an "assembler" or a "compiler" is really an issue of
implementation, not of the language it processes.  HLA is a compiler because it
translates the HLA assembly statements into a lower-level source code which
is then assembled by a traditional assembler like MASM.
I could very easily write a compiler for the SpAsm language that translates
SpAsm code into MASM source code for further processing.  Would this make
SpAsm a "high-level language"?  Not at all.  The point is, the implementation
is irrelevent.  HLA is an assembly language, though the HLA v1.x system uses
a compiler implementation.  MASM and TASM are definitely assemblers, since
they generate object code directly.  Of course, you might claim that they're not
since they don't generate executables directly, but then, you've demonstrated that
you've got a peculiar notion of what an assembler is, anyway.

Quote:

> A real HLA will exist, the day when we will have an Assembler (a *real*
> Assembler...) full featured with all the integrated tools, that any
> actual HLL provides (Complete IDE/RAD, with integrated Editors, De{*filter*},
> Click-and-run Wizards, and so on). This is what i am doing with SpAsm:

Hmmm...
So the fact that you've got an IDE makes an assembler high level?
That's a  peculiar definition.  I suggest you take a look at Solomon's text
on assembler's and loaders.  It provides a workable definition for "high level
assemblers" (that predates HLA) and it doesn't say anything at all about
IDEs (indeed, it talks about programs in the 1960's as being high level assemblers).

I do like the idea that you pooh-pooh HLL-like control structures as not being
true assemblers, but embrace automatic code generators (i.e., wizards).
I like the idea that you think libraries stick, but "click and run wizards" and
RAD are okay.  Personally, I truly like
...

read more »



Tue, 05 Jul 2005 11:36:00 GMT  
 HLA's src,dst operand syntax


[...]

Randy, you sell very well your thing by pushing your expertise level on
others, and HLA "powerfull features" on other Assemblers. :)

About "how many Universities use SpAsm", well, i hope... as few as possible.
I only got one request, up to now, and i answered to the teacher that i was
not interrested with this, at all. Also, i regulary do my best in order to
keep away from any "official-like" reuse or publication, for example, by
writing vulgar jokes, like the one at the end of my explanations about
"Xor linked Lists":

Quote:
>"...
>Though, another real advantage is to show other programmers how great your
>knowledge is, when you have no more interesting things to show (i mean, for
>example, if you have a small {*filter*})."

... that, (added to my very approximative english) should definitively keep
them away. :)) Nevertheless, given some noticable irregularities in the
downloads statistics, i have some awfull doubts...

About studient being the tomorrow Assembly programmers, all i can say is
that, as far as i can know, *none* of the actual important guys, who have
made Win32 Assembly possible, was individuals. I am not sure about all my
infos, but, i think that Iczelion is a doctor (medical), Ron Thomas worked
in Chimical (retired now), Test Departement works in a state "bureau" (i
don't know the exact english word, for this), ... and so on. Sorry, i was
not with this pionniers group, because, at that time, i was building houses,
but, ... *you*???... (yes, personnal attack, but i clearly remember that,
when i got back to programming, the doors were already widely open, and that
you were yet with AoA 16. True or false, teacher?).

If we had wait for your holy Universities for forcing the closed Doors, we
would yet being told that, Win32 being a C interface, it can *not* be
programmed in Assembly. The Universities and the like are co-responsible
of the death of Assembly ("Co" implying the Market rules, which is another
story), not co-responsible of its possible rebirth.

About your publishing strategy, i think it is possible you are right. May be
one day, i will have users requests asking me why SpAsm syntax is
incompatible
with HLA :)

About your answers to Mike, generally speacking, while you are questionned
about the nature of HLA and about your choices validations, i notice that
all you do is:

- pushing your own teaching expertise level.
- promoting your production by some way of "officialisation" (Universities
validations // Publishers interrest // and so on). This is to say,
validations by people who have none idea about what asm could ever be,
and that are just impressed by the 'seriousness' color and style of your
production.

To me, this is not a serious discussion. The only thing that interrest me,
would be about technical considerations:

* Ease of use.
* Speed
* Readability
* Efficiency
* ...

... all things that i can *mesure*. For example, coming back to the lower
stage of the effective syntax, we are yet waiting for a clear answer (I have
already asked you this 1 or 2 year(s) ago) about *why*, in HLA,

Quote:
> push eax

becomes:

Quote:
> push( eax );

Question 1: Is your pre-parser able to detect an end of line.

Your previous answer: We may have more than one statement on one line.

My follow-up questions: Where, in any HLA Source of yours, may i see
a Multi-Instructions Line? Why is the *last* statement to be semi-
colon ended???

In SpAsm syntax, Multi-Instructions Line are allowed, and no char is
required for ending a Line (out of the usual CR/LF).

Question 2: Why parenthesis?

When seing things like:

Quote:
> and( $bf, (type byte [esp]));

i have to apologize that i am stuck, when considering that, after having
define such a fancyfull and over-typing syntax, you may yet reproach to
NASM and SpAsm that they "forces them to specify the displacement size of
their instructions" (!!!???...). In SpAsm default syntax, upper statement,
(if i understand what "$bf" means...), would be something like:

Quote:
> and B$esp 0F

12 chars instead of 29. Who forces who to write what? Which formulation
is the more or less readable? These are things that i can understand,
and that we can discuss about. I think that you and me perfectely know
what "readability" means (though we may differ on details...), that both
of us know that 29-12=17. If you can't provide any sensible answer to such
simple and basic facts, discussing about why Libraries, reusable-Code and
Typings defeat the purpose and power of Assembly, or discussing about the
compatibility of Low Level Assembly with Click-and-Go Interface and Wizards,
are not the soon coming up threads.

Friendly, Betov.



Tue, 05 Jul 2005 20:10:18 GMT  
 HLA's src,dst operand syntax

BTW: what is the "Evil board", exactly?



Wed, 06 Jul 2005 07:39:35 GMT  
 HLA's src,dst operand syntax

Quote:

> BTW: what is the "Evil board", exactly?

 < http://board.win32asmcommunity.net/ >

Betov



Wed, 06 Jul 2005 16:36:37 GMT  
 
 [ 79 post ]  Go to page: [1] [2] [3] [4] [5] [6]

 Relevant Pages 

1. SRC: xshow - sortalike 'more' but i

2. HLA Syntax highlighting?

3. Syntax error in asm using hla

4. HLA - Updated Syntax Highlighting for Ultraedit32

5. HLA - Updated Syntax Highlighting file for Ultraedit32

6. HLA Syntax Highlighting file for UltraEdit32

7. Error: operands given don't match any known 386 instruction

8. bug in 7.0b3: string operands in expr don't work

9. There is an 'U'|'X'|'W'|'Z'|'-' in an arithmetic operand

10. Who's using HP DST?

11. Problem using ObjectShare's DST

12. New i386 and SRC RPM's for Numerical Python Version 14

 

 
Powered by phpBB® Forum Software