============================================================= The High Level Assembly Frequently Asked Questions (FAQ) List ============================================================= This document describes the HLA (High Level Assembly) language. Many of these questions were asked in newsgroups or email, some questions are simply "anticipated" questions injected to help describe the HLA system. -------- Purpose and General Questions ---------------------- 1: q. Where do you get a copy of HLA a. http://webster.cs.ucr.edu Following the High Level Assembly links. 2: q. What is HLA? a. HLA is a high level assembly language. It uses a high level language like syntax (similar to Pascal, C/C++, and other HLLs) for variable declarations, procedure declarations, and procedure calls. It uses a modified assembly language syntax for the standard machine instructions. It also provides several high level language style control structures (if, while, repeat..until, etc.) that help you write much more readable code. 3: q. Doesn't the presence of HLL control structures technically make HLA a high level language? a. These control structures are similiar to those provide by MASM and TASM. So unless you're willing to call MASM and TASM high level languages, it doesn't make sense to call HLA a high level language. Definitely, though, HLA provides a syntax that is usually "higher level" that that provided by MASM or TASM (even in TASM's IDEAL mode). 4: q. HLA programs look like Pascal. Why didn't you make them look more like C/C++? a. Actually, they look more like Ada or Modula-2 than Pascal, but to answer the real question, Pascal is a much cleaner, easier to read language that C/C++. The intent was to create an assembly language that allows the creation of readable programs. The Pascal/Modula-2/Ada branch of the programming languages tree is generally acknowledged as producing more readable programs than the C/C++ branch. 5: q. But there are more C/C++ programmers today than Pascal programmers. Don't you think that using a C/C++ based syntax would have made HLA easier to learn by most people? a. No. HLA is only superficially related to Pascal. While Pascal programmers might have a tiny advantage when learning HLA, the majority of the learning effort is in other areas (like learning machine language) rather than learning Pascal's procedure declaration syntax vs. C/C++'s (about the only area where Pascal programmers have a real advantage). 6: q. Why is HLA necessary? What's wrong with MASM, TASM, GAS, or NASM? Do we really need another incompatible assembler out there? a. HLA was written with two purposes in mind: The first was to provide a tool that makes it very easy (or, at least, easier) to teach assembly language programming to University students. Experiences at UCR bear out the success of HLA's design (even with prototype/alpha code with tons of bugs and little documentation, students are producing better projects than past courses that used MASM). The second purpose was to provide a tool for very serious, code-quality-conscious programmers who want to write very powerful applications in assembly language (as opposed to the "DOS Hackers" who are still worrying about the fastest "sieve" program or the fastest integer to ASCII translation routine that can be written. What's wrong with MASM, TASM, GAS, and NASM? (a) Their very syntax encourages people to write unreadable programs (if you don't believe me, look at the code being posted to the net). (b) Their macro facilities are non-existent to moderate. They don't, for example support the creation of DSELs (domain specific embedded languages) very well. As to whether another incompatible assembler is good or bad, well, that toothpaste is already out of the tube and there is no putting it back. If you've got two incompatible assemblers, you may as well have three or four. Certainly, there was no good reason to attempt to make HLA compatible with an existing product. The whole point of HLA was to start fresh, not carry around a lot of old baggage from the late '70s (when Microsoft's first assemblers started appearing). 7: q. Is HLA intended for high level language programmers? a. Only in the sense that a HLL programmer who doesn't know assembly language will probably have an easier time learning HLA rather than, say, MASM. Otherwise, HLA is not intended for HLLs at all. While you can certainly write assembly language modules in HLA that link to other HLLs, HLA was specifically designed to let you write stand-alone application in assembly language under Win32 and Linux. 8: q. HLA looks like BASM in Delph. What relationship does it have to BASM? a. None whatsoever at all. Indeed, HLA only superficially looks like BASM. Most likely, this confusion exists because HLA looks like Pascal. 9: q. HLA looks like it will save your students a lot of effort learning. Since the amount of information learned is usually directly proportional to the effort extended in learning the subject, don't you feel you are shortchanging your students by letting them use an assembler that requires less effort to learn? a. If I had a fixed amount of material to teach and I stopped once the material was covered, this observation would be correct. However, in the University I have a fixed amount of time for teaching, not a fixed amount of material to cover. By making the learning process more efficient, I can cover more material and get farther along in the same amount of time. 10: q. Students writing code with IF, WHILE, and FOR statements aren't writing true assembly language code. They are missing much of what assembly is about at that point. This isn't teaching assembly, this is teaching another mid-level language like C. a. This is true. A good instructor will not allow students to continue using HLA's high level language control structures throughout the term. However, they come in very handy at the beginning of the term because they allow students to write meaningful programs using a programming paradigm they already understand before they've had time to assimilate the entire instruction set. 11: q. Does HLA run under DOS? a. No. It only runs under Win32 and Linux. 12: q. Does HLA run under Win 3.11? a. No. It only runs under Win32 and Linux. That would be Windows 95, 98, NT, 2000, and XP (and probably later versions as well). 13: q. Why didn't you write it so that it runs under DOS? a. DOS is truly dead at this point. Most die-hard assembly language programmers still work in DOS because DOS is easy to program in assembly language and there is a large amount of programming information associated with DOS. A major point of HLA is that it is intended to make Windows and Linux programming as easy as DOS in assembly language. Currently, HLA does a good job of this with console apps. 14: q. Does HLA support console application programming? a. Yes. Very well. The console module in the HLA Standard Library is especially powerful. 15: q. Does HLA support graphics/GUI Windows application programming? a. There is nothing in the language that prevents you from writing graphical applications. At the current time, however, the HLA Standard Library doesn't provide much support for GUI apps. This will change with time. 16: q. Do you provide an application framework like OWL, MFC, or VCL for use with HLA? a. See the above answer. 17: q. Is HLA Shareware? a. No. HLA is free. 18: q. Is HLA GPL'd? a. No. You are free to do whatever you want with it. GPL puts a lot of restrictions on the code that I don't particularly agree with. 19: q. Is HLA public domain? a. Yes. 20: q. Is the source code available? a. Yes. 21: q. Why not use the services of all the programmers on the net to test and debug your program, as has happened for Linux, NASM, and other Open Source projects? a. The HLA system is currently in excess of 100,000 lines of code. Part of this is due to inappropriate choice of programming language (FLEX/Bison), part of the size is due to sloppy coding, part of the size is due to the fact that HLA is a big language. I had to pull a lot of tricks with Flex and Bison in order to implement the language. The code is not easy to follow and easy to mess up if one isn't careful. It took me over four years to create this mess and I suspect it would take someone at least a year to figure out what I've done (never mind why I did it). OTOH, if you're willing to expend the effort, have at it. 22: q. Earlier you talked about writing readable code. Why didn't you follow your own advice on the HLA source? a. HLA is currently a prototype. A prototype is a program you write in order to test ideas out. I've been testing lots of ideas for over three years now. Many ideas have worked, many have failed, some have succeeded only through the application of brute force. However, the end result of all this experimentation is a grand kludge. The saying "always prepare to write your program twice, because you will..." certainly applies here. My prototype is the first version of the program. Version 2.0 will have to be a complete rewrite, applying what I've learned. 23: q. What are the other implications of a "prototype" piece of software? a. I don't have any problems changing the syntax of the language in such a way that it renders existing code uncompilable. I've done this on several occasions already, it will likely happen in the future. This often breaks existing programs. When version 2.0 comes out, the prototype process will be over and I will be far more respectful of people's existing source code when making major changes to HLA. 24: q. What is the current version? a. The current version changes so often that any attempt to specify it here would produce something that is completely out of date. Go to Webster and you can find the latest version there. 25: q. You keep calling HLA a compiler. Aren't translators for assembly language called assemblers? a. In general, yes; HLA should be called an assembler. However, the internal design is that of a compiler rather than an assembler. Combined with the fact that HLA produces assembly code, not object code, the label "compiler" just seems to be a better fit. 26: q. What do you need in order to use HLA? a. You need to be running a Win32 or Linux OS. You need the HLA distribution package. You need MASM and a 32-bit version of MS-link for Windows and Gas/ld for Linux. Windows users also need some Windows DLL libraries like Kernel32.lib. All of these files are available free on the Internet. 27: q. Does HLA work with TASM? a. Yes, though this support is provided only for Delphi users. Normal Windows users should use MASM. 28: q. Does HLA work with NASM? a. No. Feel free to modify the source code, though. The big problem is that NASM doesn't currently support object code optimization which HLA assumes the assembler provides. When this feature is added to NASM I am revisit this issue. However, since MASM is *still* free, this doesn't seem worth the effort. 29: q. MASM is a disgusting assembler. Why do you force us to use it? a. MASM, NASM, GAS, or TASM. The choice is irrelevant since HLA automatically emits the MASM code, runs MASM, and links the code to produce an executable. You don't write MASM code and you don't run MASM. So unless you simply hate Microsoft and don't want to run the software they are giving you for free "just because," you don't have to worry about what assembler you're using. If you really hate Microsoft, HLA can also generate Gas code, though this has not been tested under Windows (it is the default for Linux, however, so it has been tested in general). 30: q. Microsoft software is big and slow. Why force us to use it in order to use HLA? We'd prefer to use more efficient code. a. If you don't like MASM and LINK, you'll really hate HLA. MASM and LINK are faster than HLA. Remember, HLA is a prototype. No effort was made to make it efficient. 31: q. Does HLA support Linux? a. Yes. 32: q. Does HLA support protected mode instructions? a. Yes. They were added in HLA v1.33. 33: q. Can I write an OS with HLA? a. Of course you can. If you can write it in C, you can certainly write it in HLA. 34. q. Can I write 16-bit code with HLA? a. No. HLA is a 32-bit flat model assembler. While it supports certain segment-related instructions for OS designers, HLA is not intended for writing application programs that use 80x86 segments. 35. q. If I can't write 16-bit code with HLA, how do I write my OS' boot loader code. a. The same way you would in C: by using some other assembler! Bootloaders are trivial (only a few hundred lines of code), so using MASM, NASM, or some other assembler for this small piece of code shouldn't be an issue; you could also use the HLA #asm..#endasm sequence to embed MASM, TASM, or Gas code in your HLA program, though this hardly seems worthwhile. 36. q. What about support for FreeBSD or other OSes? a. Someday... 37. q. What about support for the AMD x86-64 chips? a. HLA v2.0 may support these devices if they become popular and I get one. 38. q. Does HLA support the entire instruction set? a. Mostly. There are a few instructions that HLA doesn't support because they're obsolete or because I don't have the latest and greatest chip so I can't test some instructions. Generally, though, if you have a neeed, email me and I'll add any missing instructions. Note that certain protected mode instructions were added as of HLA v1.33 and prior to that point I'd gotten very few complaints about their absence. 39. q. Will HLA support the IA-64 (Itanium, et. al.)? a. Probably not. That's a completely different instruction set (ignoring x86 emulation). However, if IA-64 takes over the world, then we'll see. 40. q. Isn't HLA a "fringe" product that very few people use? If someone learns HLA will they be at a disadvantage? a. In 1999 this may have been true. Since then hundreds and thousands of people have downloaded HLA and the HLA edition of The Art of Assembly Language Programming. You're in good company if you learn HLA. As another indication of HLA's popularity, Steve Hutch asked me to mirror his MASM32 package on Webster because of bandwidth problems on his website -- he had determined that a very large percentage of people downloading his package were being directed to his site by Webster (and most of those were probably downloading MASM32 for use with HLA directly from the HLA page). --------- Language Specific Questions ----------------------------- 1: q. Could you give an example of a simple HLA program? a. Here's the HelloWorld program: program helloWorld; #include( "stdlib.hhf" ); begin helloWorld; stdout.put( "Hello World" nl ); end helloWorld; 2: q. Wait a second! There aren't any real machine instructions here! This isn't assembly language. a. Okay, here's the version in "real" machine code, still using HLA: program helloWorld; #include( "stdlib.hhf" ); static hw: string := "Hello World" nl; begin helloWorld; push( hw ); call stdout.puts; end helloWorld; Feel better? HLA lets you specify HLL-like procedure calls and it will automatically push the parameters on the stack for you. This is very similiar to the "invoke" statement MASM and TASM (although I personally feel that HLA's syntax is cleaner, clearer, and easier to read). If you really like, you can always explicitly write the assembly instructions yourself. However, there is little benefit to doing so. 3: q. Isn't it inefficient to pass parameters on the stack? a. In some cases yes. But if the procedure you're calling expects parameters on the stack, whether the compiler pushes them or you push them, there is hardly any difference. 4: q. The statement <> hardly looks like machine code, explain this. a. Note that <> is no more a machine instruction than is the HLA declaration. Semantically, the two are equivalent and they generate nearly the same machine code (actually, HLA strings aren't simply zero- terminated arrays of characters; but ignoring that...). Syntactically, however, HLA turns out to be much easier to read. 5: q. Initialized data in the static section appears to be typed. What if I want to go wild and put untype, unstructured data into my program? a. Initialized data in the static section is indeed typed. You cannot initialize a string variable with a floating point numeric value (for example). However, HLA allows the creation of unstructured initialized data. Since most data is structured, you will rarely use this feature in the language. 6: q. Why the parentheses around the push operand? a. HLA instructions are "composable". This means that you can often supply one instruction as the operand of another instruction. For example, consider the following statements: mov( 0, eax ); mov( eax, ebx ); These could be rewritten as: mov( mov( 0, eax ), ebx ); The interior mov instruction returns its destination operand for use as the operand the instruction represents. That is, HLA substitutes "eax" for "mov( 0, eax )" in the statement above. This funny looking statement generates exactly the same two instructions as the two separate mov instructions above it. 7: q. This doesn't look very readable. a. No, it is not. This feature needs to be used with extreme care or you can quickly produce an unreadable mess. However, composition of instructions is *very* useful in certain special cases. 8: q. The operands are backwards in your examples. a. No they are not. You're simply used to Intel syntax whose operands are generally orderd "instr dest, src". HLA reverses this order to obtain "instr( src, dest )" which is a little more intuitive for most instructions. 9: q. What happens with those instructions where the src,dest ordering is not intuitive? a. HLA uses dest, src ordering. The two primary examples are "cmp( dest, src )" and "lea( dest, src )". 10: q. Wait, this is horrible! You're saying that you're inconsistent with the order of the operands? a. No. Intel was inconsistent with the operands. They got lea and cmp right, almost everything else was wrong; at least if you consider the English pronouciation of the instruction to provide the "inituitive" ordering. We generally say "move source to dest", not "move dest from source". Likewise, we normally say "compare dest to source" (I can't even rephrase this with the operands reversed, forgive me). I usually say "load a register with an effective address." Hence the HLA syntax. 11: q. Your choice of the lea operand order is really bad. What if we say "load effective address into register." a. Fine, you can say that. I don't and I wrote the assembler so I got to choose. 12: q. That makes your assembler harder to learn. a. I disagree, but if you're really hung up on this *one* instruction (to date, no one has complained about cmp), fret not; LEA actually allows you to reverse the operands since the instruction is unambiguous either way. 13: q. Why didn't you use "sea" to begin with. a. For pedagogical reasons, I wanted to stick with instruction mnemonics that were upwards compatible with Intel's. 14: q. Since HLA's syntax is so different than that of other assemblers, we won't be able to use existing texts or source code on the net (or in the bookstore). a. This used to be a problem, no longer. There are problem 5,000 pages of HLA-related documentation on Webster alone (including two versions of "The Art of Assembly Language Programming". In many respects, HLA is better documented that MASM (since most MASM texts cover on the basics of assembly language programming and the wide assortment of texts out there simply restate what other books are saying). 15: q. Looking though the HLA documentation suggests that HLA supports instructions like "mov(mem, mem);" and "mul( 10, ax );" These machine instructions do not exist on the 80x86. What's going on here. a. Although I made sure I supported almost all of the Intel instructions by name, by no means did I limit myself to only using Intel mnemonics. Once I covered the basic Intel instruction set, I took some liberties and added a few new instructions. mov( mem1, mem2 ), for example, compiles to push( mem1 ); pop( mem2 ); (this only supports 16- and 32-bit operands.) and, "mul( 10, eax );" compiles to static tempName:dword := 10; endstatic; mul( tempName, eax ); 16: q. Isn't compiling code like this inefficient? a. If you abuse it, yes, there can be some slight inefficiencies. No one is putting a gun to your head and forcing you to use these new instructions or syntaxes, however. 17: q. MASM has a nasty habit of changing instructions behind your back. HLA also seems to have this same problem. a. Yes and no. Once again, if you stick to straight Intel instructions, HLA emits exactly what you specify. However, HLA emits MASM assembly code, so MASM may do a number on your code afterwards. In general, I have plans of adding a data flow analyzer and an optimizer around version three of HLA. While I certainly intend to provide source level control of the optimizer, if you are offended by an assembler that plays with your source code, then HLA is not for you. On the other hand, if you would like to be able to write readable code and leave it up to the compiler to deal with instruction scheduling and peep-hole optimizations, HLA will be a big win. 18: q. Does HLA support decent macro facilities? a. Yes. HLA supports the best macro facilities of any programming language I have personally seen. The macro facilities are so powerful, you can easily extend the language with it. For example, the HLA Standard Library includes a macro that provides a C/C++ style switch statement. Try doing that (easily and effectively) in MASM. 19: q. What high level language statements does HLA support? a. if..then..elseif..else..endif, while..endwhile, for..endfor, forever..endfor, foreach..endfor, repeat..until, break, breakif, continue, continueif, context..exit/exitif..endcontext, and try..exception..endtry. 20: q. What about statements like stdout.put("hello world" nl ); a. These aren't actually statements in the HLA language. Instead, these types of statements are either procedure calls or macros provided by the HLA Standard Library. The HLA Standard Library, and the way it extends the HLA language, provides a good example of the power of HLA's macros and HLL syntax. 21: q. Why doesn't the statement if( ax == bx && cx < dx ) then ... endif; work properly? a. It does. If you're complaining about this, you're using a really old version of HLA. 22: q. MASM allows this in it's .if statement. a. Yes it does. That's why I added this feature in version 1.25 of HLA. 23: q. IF and other HLL control statements can generate inefficient code behind our backs. What if we want to use HLA's HLL control structures to write more readable code but still maintain effeciency? a. HLA provides another syntax that lets you implement arbitrary expressions by combining HLL syntax with low level syntax. The previous example could be written as: if (#{ cmp( ax, bx ); jne false; cmp( cx, dx ); jnb false; }#) then . . . endif; The false label corresponds to the code after the "then" section of the if statement (though not present, the "true" label would transfer control directly to the "then" portion of the if statement). 24: q. Does HLA support classes and object oriented programming? a. Yes. It provides a very powerful class mechanism along with static class procedures, dynamic methods, and dynamic iterators. HLA support inheritence and many other features found in C++ and Delphi. 25: q. Do HLA procedure allow overloading? a. Not directly. However, you can easily use macros to provide any procedure overloading that you need? 26: q. Does HLA support operator overloading? a. Uh, no. Assembly language in general does not support run-time arithmetic expressions (which is where operator overloading makes sense). Hence the notion of operator overloading is foreign to HLA. 27: q. Doesn't HLA's HLL statements make the language inefficient? a. Not really. First of all, keep in mind that you don't have to use them. If you don't use them, they certainly won't affect the efficiency of your program Second, keep in mind that most HLL control structures compile to a cmp, a conditional jump, and, perhaps, a jmp instruction. Since this is exactly the type of code you'd probably write yourself, there is very little efficiency loss. Having said this, I should point out that anyone who approaches assembly language programming with a HLL mindset cannot expect to write super efficient programs. In order to obtain the benefits of assembly language, you need to think in assembly language. Using the HLL control structures relieves you of the need to think in assembly language. ---------------- HLA Standard Library Questions --------------------- 1: q. How to I write a procedure that converts a number to an ASCII string for output? a. You don't. Instead you should call one of the many Standard Library routines that will solve this problem for you. 2: q. What is the HLA Standard Library? a. It is a set of procedures you can call in your HLA programs. There are literally hundreds of routines you can call to accomplish many common tasks (for example, printing a number). 3: q. What library routines are available? a. The list appears at the end of this document (it's long!). 4: q. What are the categories these routines fall into? a. There are several categories, here's the current list (growing each week, so this is probably out of date): args- Command line argument parsing. console- Console window/smart terminal support routines. conv- Numeric/string and other conversions. cset- Character set functions. excepts- Exception handling. hla- Various constants, etc., for HLA compile-time language support (e.g., DSELs). hll- Macros to implement additional HLL statements. math- Transcendental and logarithmic functions. memory- Memory allocation and deallocation. misctypes- Various miscellaneous data type declarations. patterns- Pattern matching library (sorta like Snobol4/Icon). rand- Random number generators and support routines. stdio- Console and file I/O routines. strings- String library. Tables- Tables (associative array) library. win32- Win32 API constants and declarations. linux- Linux API constants and declarations. x86- Constants associated with Intel chips. WIP (work in progress, more to come later, including the full routine listing).