Comments and recomendations (for Randal Hyde)

[MusicalMike]

I believe we talked before, basically, I taught myself assembly language using HLA and migrated over to pure MASM and am now happily coding assembly code. I now would like to ask some questions about HLA. Why did you decide to use a syntax like

Code Select Expand

xxx(operand1, operand2)

as apposed to

Code Select Expand

xxx operand1, operand2

and why are the flow control instructions like jmp an exception to this.

Also, I was wondering, What is the difference between the high level if, else statements in hla and in masm? In you book, you constantly warn us not to get addicted to these because they are not as good as using the cmp/jxx pair. However the people over at the MASM board tell use to always use the .if/.else etc macros. If there is a difference, why didn't you just make your high level statements just as efficient as the masm high level statements?

(A question I had to ask) Am I right to assume, you are a closet pascal coder? (Based on your choice of syntax for variable declairation ":=" amoung other things)

Finally, Are you planing on proposing HLA to ISO or ANSI, it would be a nice thing to try.

Ps. You did a great job writing AoA, and I am always quick to mention HLA to anyone I encounter who wishes to learn assembly language. Keep up the great work.

[Randall Hyde]

I believe we talked before, basically, I taught myself assembly language using HLA and migrated over to pure MASM and am now happily coding assembly code. I now would like to ask some questions about HLA. Why did you decide to use a syntax like

Code Select Expand

xxx(operand1, operand2)

as apposed to

Code Select Expand

xxx operand1, operand2

Because when teaching assembly language courses, the #2 error I found people making was assuming the source operand was first and the destination operand was second (as you would intuitively think when sounding out the MOV instruction). The #1 problem, btw, was attempting to use memory-to-memory operands with various instructions.

and why are the flow control instructions like jmp an exception to this.

???
JMP only has one operand. You can't swap it :-)
CMP and LEA *are* examples of exceptions. But again, the operand choice was dictated by how you normally read the instruction in English. You say "compare x to y" for example, so it make sense to have x as the first operand and y as the second.  As for the MOV instruction, I tried to make the whole thing intuitive. It doesn't always succeed, but it's better than the original Intel syntax (based on experience with students picking the stuff up).

Also, I was wondering, What is the difference between the high level if, else statements in hla and in masm?

Not much. MASM does a better job of optimization in certain cases, HLA provides a wider range of boolean expression types.

In you book, you constantly warn us not to get addicted to these because they are not as good as using the cmp/jxx pair. However the people over at the MASM board tell use to always use the .if/.else etc macros. If there is a difference, why didn't you just make your high level statements just as efficient as the masm high level statements?

the HLL control statements are *not* assembly language. When teaching assembly language, I'm not about to recommend a construct that is *not* assembly language. OTOH, the HLL control structures are clearly easier to read. Which is why the MASM board people recommend them. I won't suggest that this is bad, but once again if you're teaching *assembly* language you really need to teach assembly language. It's okay to use HLL-like control structures as a crutch early on in the reader's education (as I do), but you don't want to leave people with the impression that using these statements is "programming in assembly language."  Now once you gain experience and you understand the costs associated with using the HLL control structures, you can make an intelligent decision as to whether it's appropriate to use them (e.g., for better readability). But this is *not* a decision a beginner is going to be able to make.

(A question I had to ask) Am I right to assume, you are a closet pascal coder? (Based on your choice of syntax for variable declairation ":=" amoung other things)

No closet about it. I work everyday in Delphi, for example. And the Algol branch of programming languages is *much* better than the C branch. BTW, HLA is *far* closer to languages like Ada or Modula-2 than, say, Pascal. Also, you'll note that the compile-time language syntax is based more on the C preprocessor syntax than on anything Pascal ever had (or didn't have, as the case may be). The job of a language designer is to pick what works from all the different languages and apply them appropriately. That's what I've done in HLA's design.

Finally, Are you planing on proposing HLA to ISO or ANSI, it would be a nice thing to try.

I'm sure there would be zero interest in that. First of all, given the fractured assembly language community (with respect to syntax), it would be difficult getting an Intel syntax standardized, much less a non-standard syntax like HLA :-).

Ps. You did a great job writing AoA, and I am always quick to mention HLA to anyone I encounter who wishes to learn assembly language. Keep up the great work.

Thanks,
Randy Hyde

[MusicalMike]

Thanks, by the way, Nothing against Algol, but I am also a c++ programer, and as far as I am concerned, Long Live C++.

[Randall Hyde]

Thanks, by the way, Nothing against Algol, but I am also a c++ programer, and as far as I am concerned, Long Live C++.

But the real question is, "Have you carefully studied the advantages and disadvantages of different programming languages?" It's easy to say that C++ is great if the number of languages you've learned is limited to those in the C family (e.g., C, C++, C#, Java, and a fair number of popular "scripting" languages). But if you've really studied what makes programming languages good or bad, you begin to see a lot of problems with the design of the C++ language (like how many different ways they can use the CONST or STATIC keywords...).

I'd like to say that the C pre-processor is one of the best things the C language contributed to language design. However, C's macro facilities are actually a subset of PL/I's (on which the C preprocessor is obviously based), so even there C didn't contribute too much.  C++ may be popular these days, but it's hardly an example of a well-designed programming language. Too many kludges had to be added to the thing after the fact.  Now this is true of *most* programming languages (including, for example, Pascal which didn't support strings well in its initial design), but C++ is generally recognized as a kludge of a design.  Fortunately (for C++ users), there is a lot of momentum behind the language. But it's already clear that C++'s star is dimming. The momentum is definitely headed to other "languages du jour" (as Hutch puts it). Java, C#, or various interpretive languages like Python and Ruby are really splitting the programming community apart. Indeed, C++ may be the last major language that a majority of programmers ever used; the future seems to be far more fragmented.  And a large part of the reason that this has happened is because C++ is just too complex for most people. Yep, people like yourself can spend lots of time mastering it and then, of course, want to stick with it forever. (Sound familiar? It's just like assembly in that regard.) But the world is moving on, I'm afraid.

As for HLA, certainly some ideas from the C branch are present (the syntax for the compile-time language, for example, is based on some C stuff and the class syntax is C++ influenced). You won't see me overloading CONST or STATIC three ways from Sunday, however :-)

Cheers,
Randy Hyde

[MusicalMike]

Its obvious they don't call you a well reguarded expert in programming for nothing. The fact is though, I do infact have experience with non c-like languages. They include Pascal (very briefly), OCAML, SML, BASIC, and FORTRAN (also very briefly). First of all lets look at string support. As you said in your book AoA, Pascal doesn't use 0 termination for strings. It prefixes the string with an indication of its length. (I believe you also modeled hla string support after this). I am not sure about the rest of those languages in reguard to this, but as you probably know c++ uses null termination, which is also the representation of strings expected by most of the windows api functions. This basicly means that using the windows API from PASCAL becomes difficult. I am aware however that Delphi is capable of writing native Win32 programs. What I would like to know is, 1 how do the wonderful guys at borland manage to get this to work, and 2. in the end isn't the implimentation for the Win32 api a lot cleaner in c++? A lot of languages (including many modern languages) don't have suport for pointers or dirrect memory access. C++ can dirrectly access memory, you can even use indexed memory addressing in c++ if you so care to do so, (along with many other complex addressing modes I might add). About the most impressive argument one can make about writing in c/c++ is that its low level nature combined wiith its high level syntax makes system level programing considerably easier. C++ code also has every other programming language barrowing assembly language beat in the execution speed department. There is an old joke about c. It goes, "C is the high level programing language that combines the power of assembler, with the ease of use of assembler", (the joke implies that c is so hard to use that you might as well use assembly hense the humor).  Most modern languages require virtual machines. This brings me into the subject of managed c++ which is a very good proof that the C++ Star is not fading. (Not yet anyway).

Granted, the syntax of curly braces and semi-colens is hard to get used to at first, but after a while, it becomes second nature. The fact is, C++ isn't going away any time soon. The only way it will is if something better comes along. Why do you think noone writes comercial software in assembly language? Because they can get along fine in c++. Personally, I would love to see someone write a programming language that is easier to use than c++, but just as good performance wise. Perhaps BASIC with pointer support. (That will be the day).

By the way as far as that comment you made about the CONST and STATIC keywards, last I checked, CONST solely meant that the variable you applied it to couldn't change value (or if used for a function argument, meant that constant values could be passed to the function), and the static keyword always means that the variable will remain in memory even after the function in which it was declaired terminates. The only real complaint I have about c++ is the way typedefs work, basicly, the win32 typedef char BYTE has this most annoying property. You can not interchange a char array for a byte array implicitly and a lot of plumbing code is necessary to make the cast work as you'd want it to. The other thing is, I find typechecking on pointers to be more trouble than its worth. Particularly when I am writing low level code, I am in situations where data types which are only different by their size are represented with types such as typedef int * LPDWORD, and other things like that, and that goes back to a previous complaint. writing reinterpret_cast<bla>(bla) all the time gets tedious. However, for what I gain by writing in c++, I consider it to be worth it.

O one more thing, Personally, even though java is a c based language, I think it sucks. Microsoft should really redesign c# so it can write native code.

[Randall Hyde]

Its obvious they don't call you a well reguarded expert in programming for nothing. The fact is though, I do infact have experience with non c-like languages. They include Pascal (very briefly), OCAML, SML, BASIC, and FORTRAN (also very briefly). First of all lets look at string support. As you said in your book AoA, Pascal doesn't use 0 termination for strings. It prefixes the string with an indication of its length. (I believe you also modeled hla string support after this). I am not sure about the rest of those languages in reguard to this, but as you probably know c++ uses null termination, which is also the representation of strings expected by most of the windows api functions. This basicly means that using the windows API from PASCAL becomes difficult. I am aware however that Delphi is capable of writing native Win32 programs. What I would like to know is, 1 how do the wonderful guys at borland manage to get this to work, and 2. in the end isn't the implimentation for the Win32 api a lot cleaner in c++?

It's very easy to make length-prefixed strings conform to C conventions - in addition to a prefix length, you also stick an extra zero byte at the end of the string (not counted in the length). This is exactly what HLA and Delphi do, for example. So conversion from HLA/Delphi strings to zstrings is trivial. Going in the other direction (converting zstrings to length-prefixed) is a bit more work, but the *few* Win32 API functions that generate strings (as opposed to simply using an existing string) usually return the length of the generated string as the function's result (or in a pass-by-reference parameter). Not not trivial, it's pretty easy to convert such a C string to a length-prefixed string. Microsoft knew what they were doing in this regard. They realized that *many* different languages would be used to write Win32 apps, and they allowed for this.

Code Select Expand


A lot of languages (including many modern languages) don't have suport for pointers or dirrect memory access. C++ can dirrectly access memory, you can even use indexed memory addressing in c++ if you so care to do so, (along with many other complex addressing modes I might add). About the most impressive argument one can make about writing in c/c++ is that its low level nature combined wiith its high level syntax makes system level programing considerably easier.
[quote][/quote]
Sure. But the same is true in most "algol-like" language *implementations*. You can do this in any modern Pascal (e.g., Delphi), Ada, and so on. Indeed, it isn't until you start getting into the higher-level languages that this facility goes away (e.g., Java).  Of course, there are advantages and disavantages to both approaches. Sure, C (and other HLLs at the lower end of the scale) let you do crazy things with pointers, but that facility is also responsible for a large percentage of errors in applications written in those languages :-)

[quote]
C++ code also has every other programming language barrowing assembly language beat in the execution speed department. There is an old joke about c. It goes, "C is the high level programing language that combines the power of assembler, with the ease of use of assembler", (the joke implies that c is so hard to use that you might as well use assembly hense the humor).  Most modern languages require virtual machines. This brings me into the subject of managed c++ which is a very good proof that the C++ Star is not fading. (Not yet anyway).
[/quote]
I disagree. In my opinion C++ *has* peaked and newer programmers are going with higher-level languages such as Java and C#. Inertia makes C++ look good still, but the number of students learning Java as their first programming language pretty much guarantees that the next generation (indeed, the generation appearing now) will be using other languages.

[quote]
Granted, the syntax of curly braces and semi-colens is hard to get used to at first, but after a while, it becomes second nature.
[/quote]
Curly braces and semicolons have nothing to do with it. C++ is a horribly complex language (how many different ways can they use CONST and STATIC, for example?).  It is difficult to learn. It is difficult to master (and how many people master it completely?). It is difficult to remember. From a language design perspective, it's a total kludge (shades of PL/I!). While I can understand why someone who has put forth the effort to master C++ may be enamoured with the feature set, the truth is that C++ has grown out of control and has fallen out of favor with the academic crowd for this reason. And since the academic crowd are the ones teaching the new generations of programmers, guess what?

[quote]
The fact is, C++ isn't going away any time soon.
[/quote]
True, but neither is assembly language, FORTRAN, COBOL, or C. What will happen, however, is that newer generations of programmers will be learning a different language.

[quote]
The only way it will is if something better comes along.
[/quote]
In many people's minds, that would be Java. In others', it's C#. Or one of the scripting languages like Python or Ruby.

[quote]
Why do you think noone writes comercial software in assembly language?
[/quote]
Too hard to learn, too hard to master, too much work to use. All the same reasons (though, granted, on a smaller scale) that plague C++.


[quote]
Because they can get along fine in c++.
[/quote]
But they can do even better in Java, etc...

[quote]
Personally, I would love to see someone write a programming language that is easier to use than c++, but just as good performance wise. Perhaps BASIC with pointer support. (That will be the day).
[/quote]
I think you'll find that with each generation of programmers, people care less and less about performance. Why do you think assembly died?  You just happened to become satisfied with the performance you get from C++. Some programmers are not so satisfied, which is why they continue to use assembly. Some don't need the performance you require, and are happy with Java or Ruby.

[quote]
By the way as far as that comment you made about the CONST and STATIC keywards, last I checked, CONST solely meant that the variable you applied it to couldn't change value (or if used for a function argument, meant that constant values could be passed to the function),
[/quote]
CONST is used in a lot of different places than in variable declarations.

[quote]
and the static keyword always means that the variable will remain in memory even after the function in which it was declaired terminates.
[/quote]
Or that the name has file locality. Or that the method is shared amongst all instances of a class. etc. VERY BAD language design to overload keywords in this fashion.

[quote]
The only real complaint I have about c++ is the way typedefs work, basicly, the win32 typedef char BYTE has this most annoying property. You can not interchange a char array for a byte array implicitly and a lot of plumbing code is necessary to make the cast work as you'd want it to.
[/quote]
Some would consider this an appropriate action. If you want BYTE and unsigned char to be synonymous, use a #define...


[quote]
O one more thing, Personally, even though java is a c based language, I think it sucks. Microsoft should really redesign c# so it can write native code.
[/quote]
Well, I don't particularly care for Java or C# either, but a *lot* of people disagree with our opinions.  Clearly, I feel that Algol-based languages are better than C-based languages, so I'm not a big fan of *any* language that uses C as a basis for its syntax.
Cheers,


[MusicalMike]

Wow, I threw all my best arguments out there and you matched them blow for blow. The fact remains though, in fact I believe you said so yourself; in the dos days, writing in assembly language gave you 10 times the performance and speed of c++ or other HLLs, but when windows came along that factor was reduced dramaticly from 10 to 2. The fact is, (and any professional game programmer will tel you this) you just CAN NOT get away with trying to write a highly graphical game in a HLL, Ive tried it, and I had to optomize the hell out of it before I could get it to run fast enough where you DIDN'T see the screen refresh itself. I did that in C#. I ended up redoing it in managed c++ (I didn't know Win32 Programming that well at the time). And guess what, Java and C# are still slugs compared to Native C++. Guess what, the programmers may be willing to settle for less performance and easier code, but the person buying the game just doesn't want to see the screen refreshing the whole time. The fact is, I have nothing against High level languages, however they better darn well provide high performance code. I don't care if its c++, fortran, SML, CAML, OCAML, pearl, javascript, cobol, ada, basic, java, pascal, fourth, small talk, algol, ruby, c#, or even APL!!!. If Visual Basic generated native code that could compete with the speed of c++, Id do all my coding in BASIC. Hope to hear from you.

Ps. Please don't remind me about the ever growing Java camp, I hate java so much.

[Sevag.K]

I think Java is a great idea, just not for performance.

What the world of assembly is sorely lacking is a platform-independent GUI such as the one available in Java.  I tried starting a project of consolidating just Windows and Linux GUI, but the sheer task is so daunting, I couldn't even figure out what would be the best approach for such a beast.

[MusicalMike]

The reason for this is it simply can't be done. Assembly it self isn't portable. Even Basic Console IO can't be accomplished in Assembly Unless there is an underlying OS that provides the necessary system routines. There fore Graphical IO also sufferes the same problem. What you are asking for is a standard assembly language library, which must be reimplimented on every system that does equivilant tasks using the system routines available ohn what ever system you are currently implimenting it in. Seems like a non-issue but you must remember, every micro-processer has its own assembly language, and every opperating system has its own system routines which provide varying levels of functionality. Many very old OSs were incapable of graphical IO. The fact is, on such a low level, you can't necessarily count on the necessary system routines being there. Take a look at .NET for instance, the .net framework was origonally a big wrapper library around a good portion of the win32 api. Now they are trying to make it portable in other OSs much the same way Swing Does with java. As you probably know, they have been trying to do this with little or no success for years now. Its just not going to happen any time soon. I have been working with Win32 for a long enough time where I know there are certain things that would prove difficult to emulate on Multiple OSs, and thats because, there are too many cases where you can't impliment just the GUI portion of the API without implimenting many other things. A good example of this is the concept of filling out a WNDCLASS structure, registering it, calling CreateWindow, assigning the result to an HWND, making a call to show window, and then starting a message loop. Thats the basic idea of a windows application. However stuff like the RegisterClass function is too specific to windows and trying ti impliment it on other OSs would require modification of the OSs itself to accomidate it (as I said, not every OS provides the same System Routines).

[Sevag.K]

Support for multiple microprocessors is theoretically possible through the use of GAS which is already supported on most (vs. other assemblers) systems, but I actaully meant to support only x/86 based OSes.  It's still not an easy task.

My GUI project (which is pretty much dead in the water before it got far) origianly involved writing wrappers for the Windows GUI.  But I ran into the same problems you mention above.

I think if this is to work, one has to use only the native drawing objects of each system and write the GUI from scratch, sort of the way Java does with its class libraries.

[MusicalMike]

I figured that was what you were trying to do. The problem is, there are specific functions in the windows API specifically designed to handle the creation, display, and processing of windows. All of these are API functions, and all calls to them are ultimately execute code in the windows kernal. There fore, you have two options. One, rewrite all other OSs to include these functions to satisfy the presious few people who actually want to write GUI apps in Assembly (personally I believe assembly should only be used to code performance critical sub routines, not to be used to entire applications; or at the very least for console based apps). The other is to have every single api function necessarily coded in include files, and use them. The problem with the first option is, ITS JUST NOT GOING TO HAPPEN. The problem with the second option is a bit more subtile. In windows, those api functions apear only once in memory, and that is the memory in which kernal32.dll is loaded. Same with the drawing code (which tends to be humongous). If we were to include these functions in every exe that used this wrapper library, the result would be humoungous exe files bloated by all the drawing code that would step all over eachother when concurently loaded into memory. Not prety, not affective, and not worth the trouble. Its an interesting idea, but GUI wrapper librarys that work on multiple OSs just is not posible. Don't even try to do it. It just won't work.

[Sevag.K]

Take a look at wxWidgets.  That project provieds a set of libraries that provide a cross-platform GUI interface and the executables produced aren't much bigger than one would expect from a program that includes functions that normally reside in the system kernel.  Sure, there is bloat, but it's managable bloat.

The problem with wxWindows is that it is written in C++ and that language is mind-boggling for me.  I just can't figure out how to convert the headers to interface with it.  I don't quiet know which way they went with wxWindows (wrappers,  native-drawing or something else), but I was rather impressed by how far they have come, and all the GUI widgets that are possible with it.

www.wxwindows.org

[MusicalMike]

I have never delt with wxWidgets before, or heard of them for that matter. However those projects are typicly only implimented on windows, one or two versions of unix, and mac. Certain versions of Linix have their own api functions for handling gui opperations (for lack of a better term). MAC believe it or not uses a very similar archetecture for the section of its api that deals with GUI. This accounts for the small size, and all thats needed is a bit of conditional compilation to top it off.

By the way, I just have to say this. I am a c++ programmer. As such I feel its my duty to tell you this. C++ is very easy to understand, but you need to completely change your mind set especially if you come from a java background. First thing you have to do is, forget about everything you know about programming (barrowing the concept of if/else branching statements, for and while loops, and switch statements) and take everything you read on or study reguarding C++ for face value. C++ is a procedural language as well as an Object Oriented one so it will not feel the same as java. You also need to learn about pointers. Pointers are variables that contain nothing more than the address of the data it "points" to. Header files are nothing more than include files. Oh, and by the way, don't byte off more than you can chew with learning c++, do not attempts to write Win32 GUI applications after lesson 2. First, achieve full mastery of the standard c/c++ libraries. By then you will be able to understand the language. Then you go to http://msdn.microsoft.com/library/en-us/winprog/winprog/windows_api_start_page.asp . This site contains comprehensive documentation on the windows api, and can be used to get you started with GUI apps in Windows. You will find that you can achieve levesl of control over the computer that rivals that of assembly language from c++ at this point. As a programmer, you should enjoy chalanges. Learning c++ is a chalange, but it is not as hard as they make it out to be. You want to know the truth, I am only 16 years old. I have only 3 years of programming experience. I can guarintee you, I am probably the last programmer you will meet who is learning assembly language after 3 years of experience. I am not saying this to brag, but you can do anything you put your mind to.

[Evenbit]

Support for multiple microprocessors is theoretically possible through the use of GAS which is already supported on most (vs. other assemblers) systems, but I actaully meant to support only x/86 based OSes.  It's still not an easy task.

My GUI project (which is pretty much dead in the water before it got far) origianly involved writing wrappers for the Windows GUI.  But I ran into the same problems you mention above.

I think if this is to work, one has to use only the native drawing objects of each system and write the GUI from scratch, sort of the way Java does with its class libraries.

Why not just make use of existing cross-platform solutions like wxWindows and kin?  Just because you are working in ASM is not a reason to be constantly re-inventing the wheel for every issue that you want your programs to address....

EDIT:  Oops!  I should have read the rest of the thread before openning my mouth...  I see now that you did consider an open-platform framework...


Nathan.

[Evenbit]

[snip]

By the way, I just have to say this. I am a c++ programmer. As such I feel its my duty to tell you this. C++ is very easy to understand, but you need to completely change your mind set especially if you come from a java background. First thing you have to do is, forget about everything you know about programming (barrowing the concept of if/else branching statements, for and while loops, and switch statements) and take everything you read on or study reguarding C++ for face value. C++ is a procedural language as well as an Object Oriented one so it will not feel the same as java. You also need to learn about pointers. Pointers are variables that contain nothing more than the address of the data it "points" to. Header files are nothing more than include files. Oh, and by the way, don't byte off more than you can chew with learning c++, do not attempts to write Win32 GUI applications after lesson 2. First, achieve full mastery of the standard c/c++ libraries. By then you will be able to understand the language. Then you go to http://msdn.microsoft.com/library/en-us/winprog/winprog/windows_api_start_page.asp . This site contains comprehensive documentation on the windows api, and can be used to get you started with GUI apps in Windows. You will find that you can achieve levesl of control over the computer that rivals that of assembly language from c++ at this point. As a programmer, you should enjoy chalanges. Learning c++ is a chalange, but it is not as hard as they make it out to be. You want to know the truth, I am only 16 years old. I have only 3 years of programming experience. I can guarintee you, I am probably the last programmer you will meet who is learning assembly language after 3 years of experience. I am not saying this to brag, but you can do anything you put your mind to.

Well that is a great achievement for you to master the Win32 api and the C/C++ libraries at such a young age, but what Sevag is talking about is not learning C/C++ in order to use wxWidgets -- he's talking about the difficulty of calling the wxWidgets libraries from assembly.  Those header files have to be converted to provide ASM prototypes and data structures.  And if some of those functions (I haven't looked) are expecting C++ objects to be passed as parameters -- that complicates things.

What Randal said earlier about a trend toward high-level interpreted languages (Java, Python, Ruby...) is correct.  They will never match the performance of ASM (and aren't likely to be used to write an Operating System or a FPS game), but when programmer productivity is premium, these languages fit the bill.  C/C++ is joining Assembly in the back seat... to be mostly used by hobbiests and specialists.

Nathan.