hla set up for the art of assembly
in [ASM]
|
From: santosh on 16 Jun 2008 14:37 Herbert Kleebauer wrote: > santosh wrote: >> Herbert Kleebauer wrote: > >> > Funny, that's like "No must use Java to learn C language". >> >> It seems that HLA has gathered considerable momentum in US based >> academic institutions for teaching assembly language. > > That's a contradiction in itself. It is not a contradiction to those institutions (and instructors) who are using it to teach assembly programming, and that is what matters. > But I suppose there are quite a few > instructors who dislike assembly programming as much as the students. > And therefore it's not surprising that "HLA has gathered considerable > momentum". It's a real clever marketing trick to use the word > "assembler" in HLA. This way the instructor and the students can claim > the have done assembly programming because otherwise there wouldn't be > the word "assembler" in "High Level Assembler". Are you saying that the following chapters from AoA are not about x86 assembly language? If so why? <http://webster.cs.ucr.edu/AoA/Linux/HTML/IntegerArithmetic.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/RealArithmetic.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/LowLevelControlStructs.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/AdvancedArithmetic.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/BitManipulation.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/StringInstructions.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/TheMMXInstructionSet.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/DataRepresentation.html> <http://webster.cs.ucr.edu/AoA/Linux/HTML/MemoryAccessandOrg.html> >> Most courses here >> are still based on MASM and DOS (for some reason, in nearly all >> assembler courses I have examined, the environment has invariably >> been MS DOS - an OS that's one foot from the grave as far as the >> average computer user is concerned. There is no reasonable reason I >> can think of for starting with DOS/MASM instead of, say, Linux/NASM, >> but that's how it is nearly everywhere.) > > There is a big reason to use DOS and not Windows/LINUX for learning > assembly programming. Assembly programming means to use the CPU and > not the OS to solve a problem. You not only have to understand that > there is (normally) no HL support from the CPU (like IF, ELSE, FOR, > WHILE...) but also no CPU instruction like OPEN, CLOSE, PRINTF or > DRAWLINE. > > So the best way would be to start with system without any software: > burn your program in an eprom and insert it instead of the BIOS ROM. > Now, this isn't practicable for a PC system, but for a few Cents you > can by a micro controller with CPU, RAM, FLASH and IO hardware on a > single chip. For a PC you need at least a minimal system which > supports keyboard input and screen output and a simple file system. > And that's exactly what DOS does. For learning application programming with assembly language the Linux and DOS API are equally usable. DOS is useful for doing system programming, self modifying code etc., but otherwise I fail to see why beginners to assembler are invariably introduced to DOS. > The problem is, that there are no DOS PC's available anymore (neither > at the university nor at home). It is really simple to load an empty PC with FreeDOS. > And the V86 virtual machine emulating > DOS in Windows isn't a replacement (you can't even access the debug > registers of CPU). I agree. And DOSEmu is also too buggy for some types of programming. >> So Herbert, you're swimming against the tide. > > ??? "> Most courses here are still based on MASM and DOS" I meant in the context of the US. >> Instead of chastising the > > chas�tise (chs-tz, chstz) > 1. To punish, as by beating. See Synonyms at punish. > 2. To criticize severely; rebuke. > 3. Archaic To purify. > > Now you add: > 4. To say the unloved truth. It is still unclear how much of what you say is the truth and how much is based on personal preferences. >> people who post here in ala, why not email your views and your >> rationale to the concerned instructor of the institutions that are >> currently using HLA in their assembly language courses? > > It's ok to not learn assembly programming. You can't be forced to > become an assembly program, either you like it or not. But it's > not ok to teach HLA programming and then claim you have taught > assembly programming. I sort of agree here. HLA is more than a simple assembly language. It's more even that a macro assembly language. It automatically adds instructions for exceptions and for procedure prologue and epilogue. And in conjunctions with the HLA standard library one can write non-trivial programs with a single x86 instruction anywhere. Conversely to write a "pure" assembly language program you need to take considerable steps (as explained in the "DoingUnits" whitepaper), that are not the default state of the compiler. It is difficult to neatly classify the HLA language. However a subset of the HLA language can be used to learn the x86 assembly language. Sure the syntax is different, but then that is so for all other assemblers too. One deficiency is that it doesn't support all the addressing modes allowed by the x86 processors, nor does it offer mnemonics for all the instructions supported by them, but again, many other so-called assemblers also share such deficiencies. So, clearly the HLA language is much more than a simple, conventional x86 assembly language, but I wouldn't say it is impossible to learn x86 assembler with it either. You just need to throw away the HLA standard library, turn off exception support, turn off automatic stack frame code, and stop using HLA's "high-level" data types and control structures. Not easy, but not impossible.
From: Frank Kotler on 16 Jun 2008 16:00 santosh wrote: > Frank Kotler wrote: > >> santosh wrote: >>> Frank Kotler wrote: >>> >>> <snip> >>> >>> Now now. You're all making poor Betov feel useless! >> Feel? >> >> Seriously, haven't heard from Betov, or Wannabee, not even Wilhelm for >> quite a while. Hope they're okay, one and all. > > Yes. BTW are following RosAsm development over at it's board/s? Seems to > have rather stalled in recent months. No new realease announcement from > Betov in quite a while. No. This *can* be a good thing. It could mean the assembler is working okay and doesn't need any urgent bugfixes. In this case, I'm afraid it means Betov has gotten dis"courage"d. As you can see at: http://www.rosasm.org/ He feels that ReactOS has been deliberately sabotaged. He has always said that he's "working for ReactOS" - a phrase that can be misinterpreted, but he means "as opposed to working for Windows", AFAIK. Having "lost" ReactOS, he looked into Linux (Ubuntu) and doesn't feel it's close to being ready for "Joe Idiot User" (aka "killing Micro$oft"). So he doesn't have an "acceptable" platform for the assembler/IDE he's put so much work into. I feel a lot of sympathy for his position. ReactOS, meanwhile, doesn't know it's dead, and is proceeding, if slowly, towards something suitable for "day to day use". http://www.reactos.org/en/index.html So *maybe* Betov is wrong, and ReactOS *will* someday be an open source OS for the masses. I hope so, but I fear Betov's right... >> Maybe I should have mentioned that the OS/2 guys who are talking about >> porting HLA are also talking about porting RosAsm. Still not an open >> source OS... > > Nice to hear that but is OS/2 much used at all still? Yep. :) In the form of eCS: http://www.ecomstation.com/ Well, I don't know if you'd call it "much". It's still "alive"... kinda. There are a couple of people monitoring the release announcements for the Nasm binaries. They get downloaded more than I'd "expect" real human users to do. Ummm, lemme look... 17 times, in the six days 2.03 has been up... You can get a free "demo CD" from the above link. I wasn't too impressed ('asn't got Nasm on it). Best, Frank
From: Bill Leary on 16 Jun 2008 19:56 <ronaldsorrell2005(a)yahoo.com> wrote in message news:6465ecc9-0e85-4cea-b928-a257a91fef07(a)25g2000hsx.googlegroups.com... > Now I have got the Hla working on vista, I still have to type in > the set path phrase and this is ok for now or until I learn more > about it and can manipulate it myself. Start -> Control Panel -> System -> Advanced System Settings -> Advanced Tab -> Environment Variables Find "path" in the System Variables section, select it, and hit "Edit". You can probably get away with just going to the end of the line, putting a semi-colon, then putting in the path to HLA. - Bill
From: Herbert Kleebauer on 17 Jun 2008 04:48 santosh wrote: > Herbert Kleebauer wrote: ^ > >> It seems that HLA has gathered considerable momentum in US based > >> academic institutions for teaching assembly language. > > > > That's a contradiction in itself. > > It is not a contradiction to those institutions (and instructors) who > are using it to teach assembly programming, and that is what matters. If you want to learn French but the teacher is teaching you German, then this isn't a contradiction if the teacher believes himself (or just wants to believe it) that he really is teaching French? > Are you saying that the following chapters from AoA are not about x86 > assembly language? If so why? > > <http://webster.cs.ucr.edu/AoA/Linux/HTML/IntegerArithmetic.html> Very assembler like: Note that HLA allows a form that lets you specify a constant. The 80x86 doesn't actually support a MUL or IMUL instruction that has a constant operand. HLA will take the constant you specify and create a "variable" in the special "const" segment in memory and initialize that variable with this value. Then HLA converts the instruction to the "(I)MUL( memory );" instruction. Generally, you won't need to use this special form since the INTMUL instruction will multiply a register by a constant. And I always thought the result (mod 2^n) for a n*n bit multiplication is the same for signed and unsigned numbers: If an overflow occurs (which is always a signed overflow, since intmul only multiplies signed integer values), then this instruction sets both ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Very assembler like: The 80x86 does not provide a separate instruction to compute the remainder of one number divided by another. The DIV and IDIV instructions automatically compute the remainder at the same time they compute the quotient. HLA, however, provides mnemonics (instructions) for the MOD and IMOD instructions. These special HLA instructions compile into the exact same code as their DIV and IDIV counterparts. The only difference is the "returns" value for the instruction (since these instructions return the remainder in a different location than the quotient). The MOD and IMOD instructions that HLA supports are > <http://webster.cs.ucr.edu/AoA/Linux/HTML/RealArithmetic.html> > <http://webster.cs.ucr.edu/AoA/Linux/HTML/LowLevelControlStructs.html> > <http://webster.cs.ucr.edu/AoA/Linux/HTML/AdvancedArithmetic.html> > <http://webster.cs.ucr.edu/AoA/Linux/HTML/BitManipulation.html> > <http://webster.cs.ucr.edu/AoA/Linux/HTML/StringInstructions.html> > <http://webster.cs.ucr.edu/AoA/Linux/HTML/TheMMXInstructionSet.html> > <http://webster.cs.ucr.edu/AoA/Linux/HTML/DataRepresentation.html> > <http://webster.cs.ucr.edu/AoA/Linux/HTML/MemoryAccessandOrg.html> Sorry, no time to read this all. > For learning application programming with assembly language the Linux > and DOS API are equally usable. DOS is useful for doing system > programming, self modifying code etc., but otherwise I fail to see why > beginners to assembler are invariably introduced to DOS. Learning assembly programming also means to understand what happens at the lowest system level. Therefore I suggest to start assembly programming with a simple 8 bit micro controller where there is only your program and nothing else. But if you use a PC, then there is a big difference whether you use a OS like Windows/Linux (where a few million instructions are already loaded into RAM and executed in a time sharing mode parallel to your own assembly code) or a simple OS like DOS (where, beside a few interrupt routines, no parts of the OS or other programs are executed once your program is started). > > The problem is, that there are no DOS PC's available anymore (neither > > at the university nor at home). > > It is really simple to load an empty PC with FreeDOS. But it's not so simple to install DOS on a PC with an already installed Windows (and NTFS file system). And even if it is possible, you will need a second Winows/Linux PC for the cross developement of the DOS programs (as a developement plattform for software DOS really is obsolete). > > And the V86 virtual machine emulating > > DOS in Windows isn't a replacement (you can't even access the debug > > registers of CPU). > > I agree. And DOSEmu is also too buggy for some types of programming. > > >> So Herbert, you're swimming against the tide. > > > > ??? "> Most courses here are still based on MASM and DOS" > > I meant in the context of the US. If "most courses in the US are still based on MASM and DOS", why I'm "swimming against the tide"? > > Now you add: > > 4. To say the unloved truth. > > It is still unclear how much of what you say is the truth and how much > is based on personal preferences. If it's not the truth, you should be able to prove it wrong. > > It's ok to not learn assembly programming. You can't be forced to > > become an assembly program, either you like it or not. But it's > > not ok to teach HLA programming and then claim you have taught > > assembly programming. > I sort of agree here. HLA is more than a simple assembly language. > However a subset of the HLA language can be used to learn the x86 > assembly language. You also can use a Cessna to drive on the highway. But I doubt this is the best way to learn how to drive a car. > So, clearly the HLA language is much more than a simple, conventional > x86 assembly language, but I wouldn't say it is impossible to learn x86 > assembler with it either. You just need to throw away the HLA standard > library, turn off exception support, turn off automatic stack frame > code, and stop using HLA's "high-level" data types and control > structures. Not easy, but not impossible. As Frank says, at least the operand order is the correct way. If you could get rid of the many "( )" and delete any existing AoA manual (so nobody knows about the non assembler features of HLA) you maybe really could use HLA as an assembler. But as Betov says, then HLA only passes the input code unmodified to the backend assembler (GAS also uses the correct order of the operands).
From: Wolfgang Kern on 17 Jun 2008 04:50
santosh replied to Herbert: .... > Are you saying that the following chapters from AoA are not about x86 > assembly language? If so why? I'd say because it is bound to the HLA-syntax and it contains too many easy misleading interpretations of what a CPU can do or not. Let me check on this (~1.5 MB docs)... > <http://webster.cs.ucr.edu/AoA/Linux/HTML/LowLevelControlStructs.html> I just picked an example out of the above: <>____________________ program labelDemo; #include( "stdlib.hhf" ); begin labelDemo; lbl1: lea( ebx, lbl1 ); lea( eax, lbl2 ); stdout.put( "&lbl1=$", ebx, " &lbl2=", eax, nl ); lbl2: end labelDemo; </>_______________ beside the redundant empty lines which makes it harder to read, the LEA here will lead to the often seen misunderstanding that MOV ebx,LBL1 would work any different than LEA ebx,[LBL1] > <http://webster.cs.ucr.edu/AoA/Linux/HTML/IntegerArithmetic.html> <quote;> The 80x86 doesn't actually support a MUL or IMUL instruction that has a constant operand. </> So how about IMUL 69... 6B... > <http://webster.cs.ucr.edu/AoA/Linux/HTML/AdvancedArithmetic.html> A boring 30 KB document. It could be said with fewer words to avoid confusion. > <http://webster.cs.ucr.edu/AoA/Linux/HTML/RealArithmetic.html> This seems to be OK for FPU. > <http://webster.cs.ucr.edu/AoA/Linux/HTML/BitManipulation.html> Now this above (44KB) document may even lead to much more confusion, because all required information could be said within four sentences. > <http://webster.cs.ucr.edu/AoA/Linux/HTML/StringInstructions.html> The cause for the regular posted "why wont it work?" ? I read it three times and couldn't find a single word about the involved segment registers nor that POPFD is priviledged. > <http://webster.cs.ucr.edu/AoA/Linux/HTML/TheMMXInstructionSet.html> I better let Rod point out all contradictions in the 11.6 above :) > <http://webster.cs.ucr.edu/AoA/Linux/HTML/DataRepresentation.html> This one looks OK, even again much too verbose, and I'd put it up front or into an appendix for the few who really haven't heard this before. > <http://webster.cs.ucr.edu/AoA/Linux/HTML/MemoryAccessandOrg.html> Maybe someone should clear up with chapter 2.3 ... .... >> So the best way would be to start with system without any software: >> burn your program in an eprom and insert it instead of the BIOS ROM. >> Now, this isn't practicable for a PC system, but for a few Cents you >> can by a micro controller with CPU, RAM, FLASH and IO hardware on a >> single chip. For a PC you need at least a minimal system which >> supports keyboard input and screen output and a simple file system. >> And that's exactly what DOS does. > For learning application programming with assembly language the Linux > and DOS API are equally usable. DOS is useful for doing system > programming, self modifying code etc., but otherwise I fail to see why > beginners to assembler are invariably introduced to DOS. I think the advantage of learning ASM in an unprotected environment is obvious for all who like to know all possibilities of a given CPU. >> The problem is, that there are no DOS PC's available anymore (neither >> at the university nor at home). > It is really simple to load an empty PC with FreeDOS. >> And the V86 virtual machine emulating DOS in Windows isn't a >> replacement (you can't even access the debug registers of CPU). > I agree. And DOSEmu is also too buggy for some types of programming. Me too agree, even Bochs show some problems ... .... > So, clearly the HLA language is much more than a simple, conventional > x86 assembly language, but I wouldn't say it is impossible to learn x86 > assembler with it either. Not impossible, but heavy detouring in my view. > You just need to throw away the HLA standard > library, turn off exception support, turn off automatic stack frame > code, and stop using HLA's "high-level" data types and control > structures. Not easy, but not impossible. And so you ended up with GAS ? :) __ wolfgang |