hla set up for the art of assembly
in [ASM]
|
From: rhyde on 27 Jun 2008 20:37 On Jun 15, 11:43 pm, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > > "different"? Don't you mean similar? The point was that HLA's syntax is > much more like C and very different from any existing or obsolescent > assembler... x86 or not (i.e., even 6502 assembly was far closer to modern > x86 and NASM than HLA is...). So, it's easier to adapt from one assembler > to another. It'd be easier to adapt to C from HLA than from HLA to > (non-HLA) assembly. It'd be difficult to adapt to Pascal from HLA. MASM: mov eax, 0 HLA: mov( 0, eax ); C: eax = 0; Gee, other than the semicolon at the end of the line, it sure looks like HLA syntax is a whole lot closer to MASM than to C. Rinse and repeat for every other instruction in the instruction set. > > Randall has stated that HLA is _only_ a teaching tool (on numerous > occasions)... including to me when I suggested it could have a higher > purpose such as a general C assembler. Uh, please point out where I said that HLA is *only* a teaching tool. I've certainly said that it was created as a teaching tool, but there is absolutely no reason HLA cannot be used for other purposes. For example, I am currently developing software to control a TRIGA Reactor for General Atomics using HLA. And there are lots of other examples of real-world applications that demonstration HLA is useful for something beyond educational purposes. > Okay, so we have to call assembly: "real assembly" because of HLA being > promoted as assembly, but RH calls "real assembly": "straight assembly > language" because he knows HLA isn't "straight assembly language". HLA, like MASM and TASM, is a high-level assembly. When I talk about "straight assembly" (though I've never used that term), I use it in a derogatory manner -- as in "not as capable as the high-level assemblers (like HLA, MASM, and TASM)." > Maybe > we're miscommunicating with Randall... His use of "straight" also implies > HLA is "deviant" assembly at best, doesn't it? Yeah, just like MASM and TASM are "deviant" assemblers. Go have your argument with the MASM and TASM crowd and spare us. > You also have to question, > as I did of RH previously, how well someone is going to learn assembly if > not self-taught in their early teens... Teaching someone assembly at a such > a late stage isn't going to produce promising results. Complete B.S. > > Not sure how you came to that conclusion from my statements. I prefer C, > followed by assembly. All other languages I've tried have limitations or > push additional problems onto the programmer. You can speak for yourself and, perhaps, your limited ability to use other languages. You most certainly cannot make such sweeping generalizations and claim that apply to everyone. > Like I said, it could be useful as a C syntax compatible assembler. You claim to know C. You claim it is your favorite language. But you claim that it's syntax is based on C. This doesn't make sense. > But, I > see no reason why a non-C programmer would embrace HLA... Do you? Anymore than a C programmer would embrace C? Again, you are dead wrong about HLA being based on C syntax. About the *only* thing it has in common with C (that is unique to C, and not available in languages like Pascal, Ada, Modula-2, etc) is conditional compilation via the #if statement, the #include statement, and comment syntax. And even the syntax of most of those is significantly different from C that they wouldn't be sufficient motivation for a C programmer to "embrace" HLA (on syntax principles alone). Certainly it is the case that HLA's compile-time language and declaration syntax is similar to HLLs (Pascal/Ada/Modula-2, btw, not C). This is certainly a positive thing as it means that someone learning assembly language via HLA will have an easier time of it. > Don't > you think it's too different from other assemblers? And that makes it different from any other assembler (which is too different from all the others), how? Is Gas "too different"? I'm sure MASM users feel that NASM is "too different". Bottom line is that a mov instruction is a mov instruction. Whether it's written as "mov eax, 0" or "mov( 0, eax );" what difference does this really make? As for the HLL-like statements, what's the difference between MASM/TASM: .if eax == 0 . . . .endif and HLA: if( eax = 0 ) then . . . endif; (BTW, which one looks closer to 'C' to you?) > Don't you think it's > similar to C? Though neither of the above HLL-like statements look like C, I'd argue that the MASM code is more similar to C. > Don't you think it's too different from Pascal? Try Modula-2. You'd get a lot closer. > Don't you > think it's syntax deviates too much from that already standardized by Intel > (and/or AMD) and Microsoft for x86 assembly? I do. MASM/TASM are the only two assemblers that come close to using the syntax "standardized" by Intel. Yet the code example above suggests that they use a "C" syntax by your argument. > > > Is it because HLA provides an easy > > entry-point for outsiders to join the sacred ranks of the ASM-cadre?? > > Are you saying HLA is easier than NASM for assembly? Perhaps he is not, but I am. And I'm one of the few people who've ever frequented this newsgroup that actually has experience teaching assembly language to 1000s of beginners. > > From the HLA examples I've seen, I'd have to wholeheartedly disagree with > you. They're far closer to C and don't have a nice clean syntax like NASM. So what is it that makes NASM syntax so "clean"? The absence of parentheses? The operand order? Please explain how any of *that* makes any difference whatsoever at all. The advantages of HLA are easily summed up as follows: 1) The presence of HLL-like control structures ("not pure assembly") allow beginners to start coding immediately, writing useful programs. This is particularly useful in courses that have a time limit (e.g., 10 weeks). The sooner someone starts coding, the more they're going to learn. 2) The presence of the HLA Standard Library. 3) The Art of Assembly language. > I'm not saying poor syntax is an exceptionally bad thing - I do just fine > with GNU AS and GCC's inline assembly. But, the poor syntax wastes my time, > creates confusion, leads to errors, etc. Interesting. It is exactly HLA's syntax that helps catch a lot of errors. You see people complaining all the time, for example, about type checking in assemblers like MASM, TASM, and HLA. Yet type- checking clearly helps catch errors. Certainly, you are not used to HLA's syntax. And you have a vested interest in NASM. However, the fact that you don't know HLA (and its syntax) hardly qualifies as "proof" that it is a "poor" syntax. Granted, it causes you confusion because you don't know it, and reading HLA syntax wastes your time because you don't know it, but the same exact thing can be said about NASM syntax with respect to someone who doesn't know NASM. > > I still recall a friend who wouldn't stop talking about LISP. Months and > months of LISP...! Six to eight months later, I very reluctantly asked > about LISP. He wasn't raving anymore. He was upset: "Lost In Stupid > Parenthesis"... mumble... mumble... He wanted to make simple change to his > code, but he couldn't figure it out. I then learned he'd been trying to fix > the problem for about week. Last I heard, he had to rewrite it all - to fix > one simple problem. This is just one of many examples about the problems > that arise from poor syntax. And you think that people programming in NASM don't suffer from such problems? Pick any other assembler if you don't like NASM. Truth is, most people who spend six to eight months programming in HLA really like it. If you don't believe me, visit the AoA/HLA Yahoo programming group some time. > FORTH, while free from syntax error messages, > is another language where insufficient context from lack of syntax can be > confusing. It's frequently quite difficult to understand - it's not much > more than an AST. A couple of nested IF-ELSE-THEN's will do it for most > people (There's no real way to tell which ELSE block goes with which IF > without rewriting the code in an indented style since there is no syntax.). > The lack of variables for others (Hey, they're _all_ on the stack... > Typesystem? What typesystem? That'll knock a few C heads for a loop!). Basically, all you're saying is that if you don't know the language real well, it's confusing and a source of errors. No surprise there. But if you're going to knock all these languages (HLA included), wouldn't it be better for you to *learn* the language first so you have an informed opinion? Forth and LISP are great languages for their intended purpose. Just like most programming languages out there. The fact that *you* don't know a language doesn't mean that the syntax is bad or that the language is prone to errors; that's more a indictment of your capabilities with the language rather than the language itself. hLater, Randy Hyde
From: Chuck Crayne on 28 Jun 2008 00:46 On Fri, 27 Jun 2008 17:37:20 -0700 (PDT) "rhyde(a)cs.ucr.edu" <rhyde(a)cs.ucr.edu> wrote: > 2) The presence of the HLA Standard Library. I do not think you are giving yourself enough credit for the massive amount of work you have put into this library, as it is the one indisputable feature which none of the other x86 assemblers can match. In fact, the primary frustration which I have with NASM is that I have to maintain my own include headers, not only for calls to the system libraries, but even for such simple things as the kernel calls. And, of course, now that I am working almost, but not entirely, in 64-bit mode, I have to maintain two separate sets of headers. There is no doubt in my mind that your willingness to take this burden off the backs of beginning programmers makes their task far easier, especially if they are interested in learning assembler for any modern OS. Unfortunately, however, those of us who are early adopters cannot use HLA, because it will not generate 64-bit code, and I fear that your library is so comprehensive that the task of converting it to the x86_64 architecture will not be completed for many years. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: H. Peter Anvin on 28 Jun 2008 17:28 Chuck Crayne wrote: > > In fact, the primary frustration which I have with NASM is that I have > to maintain my own include headers, not only for calls to the > system libraries, but even for such simple things as the kernel calls. > And, of course, now that I am working almost, but not entirely, in > 64-bit mode, I have to maintain two separate sets of headers. > Depending on the platform, there are some techniques one can use to obtain things like constants out of an available set of C headers. Perl is an excellent tool for these sorts of transformations. The biggest things with this is determining what your exact goals are (platform? semantics? direct system calls or using the system library?) Keep in mind most systems *have* a standard library already. On Unix platforms it's called "libc" and on Windows it's called, I believe, msvcrt.dll. -hpa
From: Rod Pemberton on 2 Jul 2008 20:09 <rhyde(a)cs.ucr.edu> wrote in message news:60c7a2f2-a566-4119-a757-d23e6e7db4cc(a)g16g2000pri.googlegroups.com... > On Jun 15, 11:43 pm, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> > wrote: > > "different"? Don't you mean similar? The point was that HLA's syntax is > > much more like C and very different from any existing or obsolescent > > assembler... x86 or not (i.e., even 6502 assembly was far closer to modern > > x86 and NASM than HLA is...). So, it's easier to adapt from one assembler > > to another. It'd be easier to adapt to C from HLA than from HLA to > > (non-HLA) assembly. It'd be difficult to adapt to Pascal from HLA. > Sorry, gone for a few days... > > MASM: > > mov eax, 0 > > HLA: > > mov( 0, eax ); That's the exact syntax of procedure call in C... And, assembly for C could be setup this way - using HLA. > C: > eax = 0; Not even close... That sets some variable named eax to 0. To set register eax to zero, you'd have to use inline assembly in C. > Gee, other than the semicolon at the end of the line, it sure looks > like HLA syntax is a whole lot closer to MASM than to C. Rinse and > repeat for every other instruction in the instruction set. That's just because you misrepresent how C uses assembly. > > Randall has stated that HLA is _only_ a teaching tool (on numerous > > occasions)... including to me when I suggested it could have a higher > > purpose such as a general C assembler. > > Uh, please point out where I said that HLA is *only* a teaching tool. I guess I should've posted a link... But, did you not read the quote of you? Go to Google Groups, use their advanced search, search for you, HLA, and "teaching tool". Read all of the posts... > I've certainly said that it was created as a teaching tool, but there > is absolutely no reason HLA cannot be used for other purposes. For > example, I am currently developing software to control a TRIGA Reactor > for General Atomics using HLA. And there are lots of other examples of > real-world applications that demonstration HLA is useful for something > beyond educational purposes. Nothing wrong with that. But, HLA would be better used elsewhere in another form. > > Okay, so we have to call assembly: "real assembly" because of HLA being > > promoted as assembly, but RH calls "real assembly": "straight assembly > > language" because he knows HLA isn't "straight assembly language". > > HLA, like MASM and TASM, is a high-level assembly. When I talk about > "straight assembly" (though I've never used that term), Okay, that's enough of the _LIES_ from you. Here's the link to the statement I quoted from clax on 3/20/00 where you use "straight assembly language": http://groups.google.com/group/comp.lang.asm.x86/msg/e57ed41f7da122ac > I use it in a > derogatory manner -- as in "not as capable as the high-level > assemblers (like HLA, MASM, and TASM)." Fog of war...? > > You also have to question, > > as I did of RH previously, how well someone is going to learn assembly if > > not self-taught in their early teens... Teaching someone assembly at a such > > a late stage isn't going to produce promising results. > > Complete B.S. I have yet to see a living counter example. I've worked with many of the CS programmers our educational system creates. You only get to see the good students grades destroyed by the curve after the fraternity boys cheat by studying your old tests... if you even bother. > > Not sure how you came to that conclusion from my statements. I prefer C, > > followed by assembly. All other languages I've tried have limitations or > > push additional problems onto the programmer. > > You can speak for yourself and, perhaps, your limited ability to use > other languages. Having programmed in over fourteen languages, having learned many languages in academia, in corporate environments, and self-taught, I don't consider my ability to program to be that limited. > You most certainly cannot make such sweeping > generalizations and claim that [sic, they] apply to everyone. Some people prefer switches for programming assembly too... One day, ask your class how many of them _want_ to use switches. Ask how many of them _want_ to keep track of where a variable is (register, memory, stack). It doesn't make my statement any less false because you perceive it as a "sweeping generalization" or some simplification of the issue. > > Like I said, it could be useful as a C syntax compatible assembler. > > You claim to know C. You claim it is your favorite language. But you > claim that it's syntax is based on C. This doesn't make sense. Well, it does for those who know C. > > But, I > > see no reason why a non-C programmer would embrace HLA... Do you? > > Anymore than a C programmer would embrace C? [Randall replies to incorrect statement... context now further below.] > Again, you are dead wrong about HLA being based on C syntax. About the > *only* thing it has in common with C (that is unique to C, and not > available in languages like Pascal, Ada, Modula-2, etc) is conditional > compilation via the #if statement, the #include statement, and comment > syntax. And even the syntax of most of those is significantly > different from C that they wouldn't be sufficient motivation for a C > programmer to "embrace" HLA (on syntax principles alone). > > Certainly it is the case that HLA's compile-time language and > declaration syntax is similar to HLLs (Pascal/Ada/Modula-2, btw, not > C). This is certainly a positive thing as it means that someone > learning assembly language via HLA will have an easier time of it. > I think you'll need to learn C before you can make such a claims. Pick up a copy of Harbison and Steele's "C: A Reference Manual." > > Don't > > you think it's too different from other assemblers? > > And that makes it different from any other assembler (which is too > different from all the others), how? > Is Gas "too different"? > I'm sure MASM users feel that NASM is "too different". > > Bottom line is that a mov instruction is a mov instruction. Whether > it's written as "mov eax, 0" or "mov( 0, eax );" what difference does > this really make? The first won't compile in C. The second will. "mov();" is a procedure call. "0" is value for an integer or float, etc. "eax" is a symbol. > As for the HLL-like statements, what's the difference between > > MASM/TASM: > > .if eax == 0 > ... > .endif > > > and > HLA: > > if( eax = 0 ) then > ... > endif; > > (BTW, which one looks closer to 'C' to you?) The latter... missing block parens, unecessary endif, wrong equality operator. The former uses the correct equality operator, but also has similar issues. > > Don't you think it's > > similar to C? > > Though neither of the above HLL-like statements look like C, I'd argue > that the MASM code is more similar to C. > > > Don't you think it's too different from Pascal? > > Try Modula-2. You'd get a lot closer. > > > Don't you > > think it's syntax deviates too much from that already standardized by Intel > > (and/or AMD) and Microsoft for x86 assembly? I do. > > MASM/TASM are the only two assemblers that come close to using the > syntax "standardized" by Intel. I'd say NASM is closer. > Yet the code example above suggests > that they use a "C" syntax Your misconceptions... > by your argument. .... by your argument. > > > Is it because HLA provides an easy > > > entry-point for outsiders to join the sacred ranks of the ASM-cadre?? > > > > Are you saying HLA is easier than NASM for assembly? > > Perhaps he is not, but I am. Worthless comment. Whatever... > And I'm one of the few people who've ever frequented this newsgroup > that actually has experience teaching assembly language to 1000s of > beginners. Like I've said before: 1) self-taught assembly by mid-teens 2) or generally clueless HLA doesn't help here. They'll still have to learn "non-HLA" assembly sometime. > > From the HLA examples I've seen, I'd have to wholeheartedly disagree with > > you. They're far closer to C and don't have a nice clean syntax like NASM. > > So what is it that makes NASM syntax so "clean"? > The absence of parentheses? The operand order? Please explain how any > of *that* makes any difference whatsoever at all. Odd syntax that Intel never standardized... > The advantages of HLA are easily summed up as follows: > > 1) The presence of HLL-like control structures ("not pure assembly") > allow beginners to start coding immediately, writing useful programs. > This is particularly useful in courses that have a time limit (e.g., > 10 weeks). The sooner someone starts coding, the more they're going to > learn. Although you've now accepted that HLA is useful outside academia, you still can't see beyond it's primary purpose (teaching tool), can you? > 2) The presence of the HLA Standard Library. I don't tend to use libraries with assembly, but for those who do this is likely worthwhile - especially if it compiles for NASM. Even more so if it supports GAS, MASM, TASM, ... > 3) The Art of Assembly language. Self-promotion... > > I'm not saying poor syntax is an exceptionally bad thing - I do just fine > > with GNU AS and GCC's inline assembly. But, the poor syntax wastes my time, > > creates confusion, leads to errors, etc. > > Interesting. It is exactly HLA's syntax that helps catch a lot of > errors. You see people complaining all the time, for example, about > type checking in assemblers like MASM, TASM, and HLA. Yet type- > checking clearly helps catch errors. It's true that type checking catches errors. But, that doesn't mean that type checking is the best solution or desirable. You only have to look at C. Void pointers and type checking prevents a number of incorrect assignments and pointer dereferences, but they also force programmers to work around the C type system for low level programming. As a beginner, that may be a positive, but as an expert that's a negative. > Certainly, you are not used to HLA's syntax. And you have a vested > interest in NASM. No, I have no vested interest - except as perceived by you... As I stated, I've used GAS too (and WASM). However, I wouldn't recommend GAS as a teaching tool due to it's syntax. They need to know real x86 assembler first, before learning GAS. > However, the fact that you don't know HLA (and its > syntax) hardly qualifies as "proof" that it is a "poor" syntax. > Granted, it causes you confusion because you don't know it, and > reading HLA syntax wastes your time because you don't know it, but the > same exact thing can be said about NASM syntax with respect to someone > who doesn't know NASM. .... [LISP syntax issues] > > And you think that people programming in NASM don't suffer from such > problems? Lack of complete and upto date documentation, especially on using NASM preprocessor is the only major issue I see. But, I haven't used a recent version of NASM lately. Feel free to expound your thoughts on it's defects... I'm sure Chuck and Frank are interested in "correcting" the issues. > Pick any other assembler if you don't like NASM. Truth is, > most people who spend six to eight months programming in HLA really > like it. What's your point? If it takes HLA users six to eight months to learn the basics of assembly, you're definately doing something wrong. (i.e., learning too late... etc.) BASIC programmers really like BASIC. FORTH programmers really like FORTH. LOGO programmers really like LOGO. Are you saying we should all use LOGO - when Brian Harvey (UC Berk.) has demonstrated LOGO is just as functional as LISP? What about LISP for an OS? Or, are you saying we should restrict each language to an arbitrarily decided best use: LOGO to graphics, BASIC, AWK, PERL, and SNOBOL for string processing, C to low level and general programming, FORTH to direct stack manipulation, memory constrained systems, and astronomy, COBOL for business, LISP for binary trees, HLA as a teaching tool and nuclear reactors? > > FORTH, while free from syntax error messages, > > is another language where insufficient context from lack of syntax can be > > confusing. It's frequently quite difficult to understand - it's not much > > more than an AST. A couple of nested IF-ELSE-THEN's will do it for most > > people (There's no real way to tell which ELSE block goes with which IF > > without rewriting the code in an indented style since there is no syntax.). > > The lack of variables for others (Hey, they're _all_ on the stack... > > Typesystem? What typesystem? That'll knock a few C heads for a loop!). > > Basically, all you're saying is that if you don't know the language > real well, it's confusing and a source of errors. Idiot! What I said was I know quite a few languages really well and they aren't suitable for use as a teaching tool... and they even cause problems for experts in the language. > No surprise there. 1) you've lied - proved above 2) you're stuck on self-promotion of HLA as an assembly teaching tool - although you now accept it as useful elsewhere (for money?) 3) you consistently demonstrate virtually zero understanding of other languages besides HLA, except Modula-2 > Forth and LISP are great languages for > their intended purpose. "for their intended purpose"... Wow! How interesting... Could you point out what/when/where Charles Moore what said the "intended purpose" of FORTH is/was? I'd really like to see that! Please post your response to comp.lang.forth too. FORTH may have been created with a specific purpose in mind - but I have yet to read any statement where the creator chose to restrict the language's purpose. Are you saying everyone who uses LISP should limit it's use to "lambda calculus" and never use it for binary trees or parsing? Rod Pemberton
From: Frank Kotler on 3 Jul 2008 00:24
Rod Pemberton wrote: .... > [LISP syntax issues] >> And you think that people programming in NASM don't suffer from such >> problems? > > Lack of complete and upto date documentation, especially on using NASM > preprocessor is the only major issue I see. But, I haven't used a recent > version of NASM lately. We saved a copy for ya, Rod! http://sourceforge.net/project/showfiles.php?group_id=6208 Best, Frank |