HLA mov syntax
jab3
What's the deal with your switching the syntax of MOV in HLA? I mean, I'm
enjoying learning assembly through your method (hla - after convincing
myself it may be worthwhile after all), especially since I used to program
in Pascal, and that seems to be a major influence over your language's
syntax.
However, I've dabbled with assembly before, and I noticed that you reversed
the syntax for MOV. Instead of mov(dest,src) - you have mov(src,dest).
What's up with that? Surely people will move from HLA to true assembly,
and when they do it will be confusing for them when they realize that
you've changed the syntax of some of the commands. I say this because
though I know the difference in the mov commands, I may not know some other
command you've changed around, and then when I move to true x86 assembly,
I'll have to re-learn the commands. May seem trivial, but is it even
necessary? Perhaps you find it more intuitive, but that's irrelevent it
seems to me. You call the instruction MOV the '80x86 MOV Instruction', but
it's not. It's your version of it. Is there somewhere in your book that
explains the actual syntax versus your syntax?
Granted, HLA is your language. But, from my understanding it's suppose to
re-present assembly via a higher-level language format. But does that mean
changing the commands around? Why then name it mov instead of move?
just curious and confused,
jab3
Randall Hyde
"jab3" <now...@foobar.com> wrote in message news:1Sqdnfmn6v4...@comcast.com...
> Randy -
>
> What's the deal with your switching the syntax of MOV in HLA? I mean, I'm
> enjoying learning assembly through your method (hla - after convincing
> myself it may be worthwhile after all), especially since I used to program
> in Pascal, and that seems to be a major influence over your language's
> syntax.
Several reasons.
Practical reasons first:
1. Most assemblers (i.e., leave the x86 world for a moment) use the <src, dest> syntax.
2. Students were constantly confusing the operand order when I taught the course
with MASM. The <src, dest> ordering was more natural to them given the
usual semantics of the English term "MOVE".
3. The statement now reads totally left to right rather than left, skip an operand, then go
back an operand.
4. HLA was designed for teaching assembly language to students who've never done
any assembly language programming before, so there is no pressure to adopt an existing
syntax just because they might be familiar with it.
Technical reasons second:
1. HLA's "instruction composition" scheme works *much* better with <src,dest> ordering
2. Evaluating source operands before destination operands in the parser produces more
intuitive results in boolean expressions for IF, WHILE, etc.
>
> However, I've dabbled with assembly before,
> and I noticed that you reversed
> the syntax for MOV. Instead of mov(dest,src) - you have mov(src,dest).
> What's up with that?
Therein is the problem.
HLA was not designed for people who know any prior assembly.
Had you never seen it, you wouldn't care.
> Surely people will move from HLA to true assembly,
Surely *some* people will. I think you'll find, though, that most people
will stick with HLA once they learn it. After all, there is very little that
you can do with any other assembler that you can't do with HLA. And there
is quite a bit you can do with HLA that can't be done (easily) with other
assemblers (e.g., object-oriented programming). In my experience (definitely
something I've learned with HLA), few people are willing to switch assemblers
once they master an assembler.
However, should someone choose to learn a different assembler after learning
HLA, what they're learning is *syntax* not semantics or programming paradigms.
Learning syntax is easy. Someone can pick up MASM, for example, in a week
or two after learning assembly programming well with HLA. It's about like
picking up C after you know Pascal.
> and when they do it will be confusing for them when they realize that
> you've changed the syntax of some of the commands. I say this because
> though I know the difference in the mov commands, I may not know some other
> command you've changed around, and then when I move to true x86 assembly,
> I'll have to re-learn the commands. May seem trivial, but is it even
> necessary?
No. It is not necessary. They can stick with HLA and it will satisfy all their needs :-)
If someone *has* to change, they'll find that it's no big deal. Certainly it is less
effort to go from HLA to MASM, for example, than to/from Gas. I did that
transition in a matter of days (because I had to for a project I was working on
under AIX).
> Perhaps you find it more intuitive, but that's irrelevent it
> seems to me. You call the instruction MOV the '80x86 MOV Instruction', but
> it's not. It's your version of it. Is there somewhere in your book that
> explains the actual syntax versus your syntax?
Well, it is *my* version.
But consider the other assemblers out there. Some of them may use the
<dest,src> ordering (not all of them!), but there are still syntactical differences
that trip you up. Take a look at NASM, FASM, RosASM, Gas, and even
TASM sometime. There are many *major* differences between these
assemblers. Someone who learns on any one of these assemblers is going
to run into problems when using a different assembler. This problem isn't
particular to HLA.
>
> Granted, HLA is your language. But, from my understanding it's suppose to
> re-present assembly via a higher-level language format. But does that mean
> changing the commands around? Why then name it mov instead of move?
With only a few exceptions, HLA uses Intel mnemonics for the instructions.
INTMUL is one exception. I've also created a couple of synonyms because
of HLA's instruction composition (e.g., imod and mod).
One of the main technical reasons I swapped the ordering was to support
HLA's instruction composition feature, which is a *big* feature in HLA's
high-level control structures.
> just curious and confused,
Believe me, the decision to swap the operands was not made lightly.
I fought the decision myself for many weeks during HLA's development.
I knew there would be a lot of complaints about this choice.
Finally, however, I made the decision to satisfy my core audience
(students who don't know assembly) rather than satisfy people who
already knew assembly (and are unlikely to switch to HLA in large
numbers anyway).
Cheers,
Randy Hyde
Frank Kotler
> With only a few exceptions, HLA uses Intel mnemonics for the instructions.
> INTMUL is one exception. I've also created a couple of synonyms because
> of HLA's instruction composition (e.g., imod and mod).
Have you *really* got FSTB as a synonym for FBSTP, or was that a typo?
Trying to figure out IMUL/INTMUL, the operand-ordering bit me. *Neither*
works with Intel operand-ordering! :)
But you're right, if someone learns HLA first, and then feels the need
to switch to a "real assembler", they'll think *Nasm* reversed the
operands! (I'm assuming they'd choose Nasm, okay? :)
Best,
Frank
Randall Hyde
"Frank Kotler" <fbko...@comcast.net> wrote in message news:7kcfb.206548$mp.1...@rwcrnsc51.ops.asp.att.net...
> Randall Hyde wrote:
>
> > With only a few exceptions, HLA uses Intel mnemonics for the instructions.
> > INTMUL is one exception. I've also created a couple of synonyms because
> > of HLA's instruction composition (e.g., imod and mod).
>
> Have you *really* got FSTB as a synonym for FBSTP, or was that a typo?
That was a typo, sorry.
>
> Trying to figure out IMUL/INTMUL, the operand-ordering bit me. *Neither*
> works with Intel operand-ordering! :)
Nope.
IMUL is the standard (original 8086) IMUL instruction that uses AL/AX/EAX
INTMUL is the one with multiple operands.
This was not a choice I made, but one forced on me by Bison - the productions
for Intel's IMUL instruction mess up Bison (shift/reduce and reduce/reduce conflicts).
>
> But you're right, if someone learns HLA first, and then feels the need
> to switch to a "real assembler", they'll think *Nasm* reversed the
> operands! (I'm assuming they'd choose Nasm, okay? :)
Yep.
Cheers,
Randy Hyde
jab3
>
> "jab3" <now...@foobar.com> wrote in message
> news:1Sqdnfmn6v4...@comcast.com...
>> Randy -
>>
>> What's the deal with your switching the syntax of MOV in HLA? I mean,
>> I'm enjoying learning assembly through your method (hla - after
>> convincing myself it may be worthwhile after all), especially since I
>> used to program in Pascal, and that seems to be a major influence over
>> your language's syntax.
>
> Several reasons.
> Practical reasons first:
> 1. Most assemblers (i.e., leave the x86 world for a moment) use the <src,
> dest> syntax
That I didn't know. As careful as I am about not assuming things about
computing, especially on the Usenet, I guess I assumed x86 because that
seems to be the architecture you are using for HLA. Granted, it is more
intuitive as <src,dest>. (except for me, since I'm so used to reading it as
<dest,src> :))
> 2. Students were constantly confusing the operand order when
> I taught the course
> with MASM. The <src, dest> ordering was more natural to them given the
> usual semantics of the English term "MOVE".
> 3. The statement now reads totally left to right rather than left, skip an
> operand, then go
> back an operand.
> 4. HLA was designed for teaching assembly language to students who've
> never done
> any assembly language programming before, so there is no pressure to
> adopt an existing syntax just because they might be familiar with it.
>
I understand, and that makes sense. I was just being particular about the
x86 syntax, forgetting the purpose of HLA. (which does rock, btw)
> Technical reasons second:
> 1. HLA's "instruction composition" scheme works *much* better with
> <src,dest> ordering
> 2. Evaluating source operands before destination
> operands in the parser produces more
> intuitive results in boolean expressions for IF, WHILE, etc.
>
Again, these seem like legitimate reasons for your decision, which obviously
(not that I doubted you ;) was well-thought out.
>
>>
>> However, I've dabbled with assembly before,
>> and I noticed that you reversed
>> the syntax for MOV. Instead of mov(dest,src) - you have mov(src,dest).
>> What's up with that?
>
> Therein is the problem.
> HLA was not designed for people who know any prior assembly.
> Had you never seen it, you wouldn't care.
>
True enough.
>> Surely people will move from HLA to true assembly,
>
> Surely *some* people will. I think you'll find, though, that most people
> will stick with HLA once they learn it. After all, there is very little
> that you can do with any other assembler that you can't do with HLA. And
> there is quite a bit you can do with HLA that can't be done (easily) with
> other assemblers (e.g., object-oriented programming). In my experience
> (definitely something I've learned with HLA), few people are willing to
> switch assemblers once they master an assembler.
Now this I have to....agree with. :) After continuing through the book
(on-line version), I'm realizing more and more that I really dig HLA.
Perhaps I'll try to learn a different assembler, "true" assembly, but I'm
really liking the HLA concept. I like the libraries to take away the
intimidation of just printing something on the screen. I also like the
conditionals and loops you have (and that you say eventually you will teach
us how to do it the 'real' way.) I especially like the
TRY/EXCEPTION/ENDTRY loop. You've created a very interesting language
here, it's sort of like a combinatin of Pascal, C, and x86 Assembly. It's
great! :) I'm thinking to myself - let's just learn HLA and use only
that. ;) But seriously, you have certainly closed (almost completely) the
gap between Assembly and C/other HLLs. Thank you, and hope you do continue
to improve/support it well into the future.
>
> However, should someone choose to learn a different assembler after
> learning HLA, what they're learning is *syntax* not semantics or
> programming paradigms. Learning syntax is easy. Someone can pick up MASM,
> for example, in a week
> or two after learning assembly programming well with HLA. It's about like
> picking up C after you know Pascal.
>
Ah, but those blasted pointers. :) Like I said, I used to program in Pascal
(when I was a youngun), and now I'm teaching myself C and now HLA.
Pointers are a beautiful like a rose. They can accomplish amazing things,
but they can also be prickly and sting. But they're worth it, I'm seeing.
And certainly important for Assembly I would guess, considering working
with memory addresses. (they <pntrs> don't scare me as much now as they
did when I was 13)
That's cool. I understand your reasoning better now. And thanks for
(hopefully) not thinking I was 'going off'/trying to flame you. I didn't
intend anything mean by it (I started worrying about how it may come across
after I posted it - some people interpret things differently on usenet. I
never know :)) I was just confused as to why you would do that, which to
me would be possibly confusing to other people down the road. However,
since you have much more experience in the matter than I - I thought I
would ask you. And you responsed with very specific and reasoned
explanations. Sounds good to me. :) Let's to the HLA tutor!
> Cheers,
> Randy Hyde
later,
jab3
Randall Hyde
>
> What's the deal with your switching the syntax of MOV in HLA?
One thing that I completely forgot to mention, but was reminded in a different
post, if someone doesn't like the (src,dest) syntax, you actually have the option
of changing it in HLA. HLA provides a facility that lets you take any reserved
word and turn it into an identifier. Then you can create a macro to do whatever
you wish with that instruction. E.g., here's the MOV instruction with (dest,src)
syntax:
#id( mov ); // Tell HLA to make "mov" an identifier rather than a reserved word.
#macro mov( dst, src );
~mov( src, dst ); // "~mov" says to use the original definition of "mov"
#endmacro
Now you can write "mov( mem, eax );" to store EAX into mem.
Of course, the *danger* to this approach is that it will totally confuse
someone who knows HLA :-)
Cheers,
Randy Hyde
JGCasey
"Randall Hyde" <rand...@earthlink.net> wrote in message
news:esqfb.670$Qy2...@newsread4.news.pas.earthlink.net...
why not the option mov(mem into eax) and mov (into mem, eax) ??
John Casey
Randall Hyde
"JGCasey" <kjc...@hotkey.net.au> wrote in message news:3f7e7...@news.iprimus.com.au...
>
> "Randall Hyde" <rand...@earthlink.net> wrote in message
> news:esqfb.670$Qy2...@newsread4.news.pas.earthlink.net...
>
>
> John Casey
>
Why the heck not!
As I've said in the past, HLA's macro facilities and compile-time language
are *very* powerful. I designed them *exactly* to handle stuff like this.
I don't talk much about pulling stunts like this because, quite frankly,
this is a very advanced use of HLA and I generally push HLA for use
by beginners rather than advanced programmers. However, I've often
said that one benefit to learning HLA as a beginner is that HLA *is* very
powerful and as that beginner matures into an intermediate or advanced
assembly programmer, HLA will continue to provide features that matches
the level of the programmer. So if someone really wants to create their
own syntax for the mov instruction as you've suggested here, it's perfectly
possible to do this (within reason, of course).
For example, here's a macro that does what you've requested:
/**************************************************88
program funny_moves;
#id( mov )
#id( into )
#macro mov( op1, op2 ):op1tkns, op2tkns, op_1, op_2, in_to;
?op1tkns := @tokenize( @string( op1 ), 0, {' '}, {} );
?op2tkns := @tokenize( @string( op2 ), 0, {' '}, {} );
?in_to := 0;
#if( @elements( op1tkns ) > 1 )
#if( op1tkns[0] <> "into" )
#error( "expected 'into <operand>' for operand #1" )
#endif
?in_to := 1;
?op_1 := op1tkns[1];
#else
?op_1 := op1tkns[0];
#endif
#if( @elements( op2tkns ) > 1 )
#if( in_to = 1 )
#error( "Both operands cannot have 'into' clause" )
#endif
#if( op2tkns[0] <> "into" )
#error( "expected 'into <operand>' for operand #2" )
#endif
?in_to := 2;
?op_2 := op2tkns[1];
#else
?op_2 := op2tkns[0];
#endif
#if( in_to != 1 )
// Default, or mov( op1, into op2 ); is std HLA syntax.
~mov( @text( op_1 ), @text( op_2 ));
#else
// mov( into op1, op2 ); -- uses dest,src
~mov( @text( op_2 ), @text( op_1 ));
#endif
#endmacro
begin funny_moves;
mov( eax, ebx );
mov( into eax, ebx );
mov( eax, into ebx );
end funny_moves;
/******************************************/
BTW, here's the MASM code that HLA generates for the
three mov instructions in the main program (cut and pasted
from the asm file):
mov ebx, eax
mov eax, ebx
mov ebx, eax
Of course, I'd recommend using some adjective other than
"into" as "into" is an actual machine instruction (interrupt if overflow).
But with the #id clause, you can still use into if you like.
If you're interested in more information about creating your
own statements in HLA, you might want to take a look
at the following:
http://webster.cs.ucr.edu/Page_hla/WhitePapers/while.html
http://webster.cs.ucr.edu/Page_hla/WhitePapers/if.html
http://webster.cs.ucr.edu/Page_hla/WhitePapers/LexAnalysis.pdf
You'll also want to read the chapters on HLA's compile-time language,
macros, and "Domain Specific Languages" in "The Art of Assembly Language", i.e.,
http://webster.cs.ucr.edu/Page_AoAWin/HTML/HLACompileTimeLanguage.html#1004662
http://webster.cs.ucr.edu/Page_AoAWin/HTML/Macros.html#998258
http://webster.cs.ucr.edu/Page_AoAWin/HTML/DSLs.html#1004605
Cheers,
Randy Hyde
Betov
news:3f7e7...@news.iprimus.com.au:
Why not the option: "Write Assembly". So, HLA would first
translate Assembly into HLA, and then HLA into Assembly.
Would be really great!
Betov.
wolfgang kern
Hi Randy!
[]
| > Trying to figure out IMUL/INTMUL, the operand-ordering bit me. *Neither*
| > works with Intel operand-ordering! :)
| Nope.
| IMUL is the standard (original 8086) IMUL instruction that uses AL/AX/EAX
| INTMUL is the one with multiple operands.
| This was not a choice I made, but one forced on me by Bison -
| the productions for Intel's IMUL instruction mess up Bison
| (shift/reduce and reduce/reduce conflicts).
I see four different IMUL versions
F6,F7/28 ;AX,DX:AX,EDX:EAX = AL,AX,EAX * rm(b,w,q)
0F AF rm ;reg1=reg2*[rm]q
69/rm/im ;rm*imm16/32
6B/rm/im8 ;rm*Sext imm8
Unfortunately there are only two unsigned integer MUL-versions:
F6,F7/20 MUL ;accu
B0 00 D5 n MULb ;AL=AH*n
the latter just set AL=0 and uses:
D5 n MULADDb ;AL=AL+AH*n (Intel vol.2 page 3.17)
btw: I disagree for most CPU's use "src,dest" notation,
the most distributed use "dest,src":
Intel/AMD,
Zilog
National NSC...
6502,
and even Motorola (HC11+ tools), and more...
__
wolfgang
Randall Hyde
"wolfgang kern" <now...@nevernet.at> wrote in message news:bmed1c$o72$1...@newsreader1.netway.at...
>
> btw: I disagree for most CPU's use "src,dest" notation,
> the most distributed use "dest,src":
> Intel/AMD,
> Zilog
Yep. 8080 based instruction sets (including the Z80, Z8000, and 8086) followed Intel's original lead.
> National NSC...
Their 8080 parts, yes. Take a look at the 32K processors.
> 6502,
> and even Motorola (HC11+ tools), and more...
These are one-address machines.
Consider all the RISC chips, 68K, and so on.
Consider the number of Gas assemblers out there.
Definitely, the larger number of assemblers use the src,dst organization.
Cheers,
Randy Hyde
> __
> wolfgang
>
>