Is the ultimate goal for HLA to be a competitive language for commercial high performance software development ?
Posted on 2004-09-05 19:37:22 by DarkStar
Is the ultimate goal for HLA to be a competitive language for commercial high performance software development ?


The goal of HLA is to provide a tool to make learning and using assembly language as easy as possible. In addressing the "commercial high-performance software development" comment, I will only say this:

1. If a tool is *not* suitable for real-world use, it does not make a good educational tool. Students loathe wasting time learning how to use a tool if they cannot continue to use that tool once the class is over. If they don't think that a tool will serve them later, this diminishes the educational usage of the tool because they won't take the course seriously.

2. In order to develop the HLA Standard Library (the cornerstone of the HLA system's educational facilities), I needed some very sophisticated features, features necessary for "commercial high-performance software development". So from the very beginning HLA was designed to support sophisticated software development, without burdening the beginner with the extra complexities.

3. Over the past five years, there have been lots of suggestions from HLA users that have made their way into the language specifically to support application development. Indeed, HLA v2.0 is being written in HLA and it is definitely a complex "commercial quality high-performance" application. So HLA (v1.x) is certainly capable of this type of development.

But always keep in mind that the original goal of HLA, and the primary goal today, is to provide a convenient environment for learning assembly language. Arguements about whether HLA is an appropriate application development tool invariable run into the problem of whether assembly language is an appropriate development tool. Personally, I believe that it is for certain applications. Clearly it is inappropriate for others. The only comment I'll make about HLA vis-a-vis other assemblers is that I'm yet to see a 32-bit application you could write with one of these other assemblers that couldn't also be written with HLA. So if those other assemblers are suitable for writing apps, then so is HLA. Now HLA has some advanced features that other assemblers don't possess, so I could argue that HLA is *more* suitable. But that starts to get into personal opinion, and I'd simply prefer to leave it as "if other assemblers are appropriate, then so is HLA".
Cheers,
Randy Hyde
Posted on 2004-09-10 11:21:16 by rhyde
I work in an office enviroment where everything is about speed and reliability (Does the program do what it is suppose to do?). And although HLA seems to be the best option as far as "RAD" (RAD in the sense of learning asm and producing meaningful code.) asm lang goes, most business programmers tend to use RAD languages such as vb, delphi, java and all the other lang's in the .net platform. Whenever I complain to the software engineers in my company about a program runnning slow or sluggest they almost always give me one answer, "Get a faster computer, we simply don't have the time to optimize the code." I'm slightly paraphasing, but the point is... Is optimizing a program cost effective? With computer speed growing at such fast rates, a lot of the time it would save the company more money if they just upgrade the computers than spend the time to optimize the code.

As for the future of HLA, I think it has a good one. I'm learning it now so I can better understand the 80x86 architecture. I think HLA definitely has a niche since it does what Professor Hyde intended, to speed up the learning process of asm.

Just my 2 cents.
Posted on 2004-09-10 13:19:01 by daticus
I work in an office enviroment where everything is about speed and reliability (Does the program do what it is suppose to do?).

Traditionally, assembly language programs have fared poorly in environments where reliability is important. This is more the function of the programmer than the language, but assembly doesn't offer a whole lot when it comes to helping coders write reliable code (then again, neither does C, but that doesn't stop people from writing apps in C).


And although HLA seems to be the best option as far as "RAD" (RAD in the sense of learning asm and producing meaningful code.) asm lang goes, most business programmers tend to use RAD languages such as vb, delphi, java and all the other lang's in the .net platform.

Yep, 'cause they can usually develop a *whole* lot faster in those languages. Especially as they probably aren't expert assembly programmers.


Whenever I complain to the software engineers in my company about a program runnning slow or sluggest they almost always give me one answer, "Get a faster computer, we simply don't have the time to optimize the code."

The problem with that approach is that CPU performance improvements have been decellerating. Remember the good old adage "just wait two years and CPUs will be twice as fast"? Well, how long has it been now since (single-processor) CPUs have doubled in speed? It has been getting harder and harder to radically improve processor performance. So the days of lazy programmers relying on the hardware architectes to solve performance problems are over (unless there is a quantum leap in computer technology soon). From here on out, programmers are going to have to take resposibility to write better code.


I'm slightly paraphasing, but the point is... Is optimizing a program cost effective? With computer speed growing at such fast rates, a lot of the time it would save the company more money if they just upgrade the computers than spend the time to optimize the code.

That attitude (just get faster hardware) worked through the 1980's and 1990's. It's failing these days. As to whether it's cost-effective to optimize your code, that depends on how fast it needs to be. If the program fails because it's too slow, of course optimization is important. If it fails to sell because there is competition that is better because it's faster, well, that's a marketing decision.



As for the future of HLA, I think it has a good one. I'm learning it now so I can better understand the 80x86 architecture. I think HLA definitely has a niche since it does what Professor Hyde intended, to speed up the learning process of asm.

Just my 2 cents.


Thanks for your 2 cents.
Cheers,
Randy Hyde
Posted on 2004-09-10 13:28:49 by rhyde
To be honest, as a newbie I find HLA intimidating.

First of all it has a completely different syntax than regular assembly.

Second, schools and unis use the traditional assembly in tests and in classes, which is problematic for many!

IMO the AoA book should have been written for the traditional assembly, teaching the student to write his own routines and such.

Some people like it because it looks too much like other HLLs, but I love ASM for what it is!

It's really hard (impossible) to find books that even come close to the level of your AoA, and because of that I'm at a loss!

Also, debugging applications becomes much more difficult too if you get used to the HLA synatx and don't know the traditional assembly.
Posted on 2004-09-19 12:56:48 by Caleb666
i'd take C over HLA anyday.
Posted on 2004-09-19 13:12:03 by Drocon
Well, HLA does have its advantages, but if you are writing a book on teaching people assembly, you do not shove HLA in their face, it looks like a dirty marketing trick :roll:

HLA is not that common and it forces you to learn HLA, which is not that similar to ASM.
Posted on 2004-09-19 14:26:45 by Caleb666

i'd take C over HLA anyday.


Not really surprised.A lot of people prefer HLLs to assembly.


Well, HLA does have its advantages, but if you are writing a book on teaching people assembly, you do not shove HLA in their face, it looks like a dirty marketing trick


Randy wrote AOA in the way he thought was the best way for people familiar with HLLs to learn assembly based on his experience teaching it. AOA is not the only assembly book in the world so if you have a problem with HLA then you don't have to read it. But it is possible to read HLA and use a different assembler.



HLA is not that common and it forces you to learn HLA, which is not that similar to ASM.


Maybe you know a different HLA or assembly language because HLA is assembly. The syntax is a just a little different but its really no big deal.
Posted on 2004-09-19 16:33:15 by Odyssey
Not really surprised.A lot of people prefer HLLs to assembly.

uh... i was being sarcastic?

HLA is bulky, and repeatedly boasts of it's "extensive support" for macros, like as if MASM weren't bad enough. the HLA Standard Library cringes in comparison to something like libc/msvcrt. I haven't bothered to see for myself, but i'm almost certain the code is statically linked and/or included into the executable, thus exe bloat, whereas all versions of Windows supports msvcrt by default, so everything can be dynamically linked.

HLA lacks an optimizer, therefore even code output from HLL like c/c++ is generally more optimized. MSVC6/7 both have impressive optimization routines (especially msvc7), and no other compiler compares with GCC in regards to optimization. and this was all just comparing HLA to a HLL.

as for assembler, HLA lacks flexibility, i would rather use TASM, or something WYSIWYG-ish, like NASM, to code something i need to be small/fast/optimized.
Posted on 2004-09-19 17:03:22 by Drocon

HLA is bulky, and repeatedly boasts of it's "extensive support" for macros, like as if MASM weren't bad enough.


What's wrong with having a powerful macro system. It's great when you need it but doesn't affect you when you don't.


the HLA Standard Library cringes in comparison to something like libc/msvcrt.


In what way? Have you looked at the hla standard library?


I haven't bothered to see for myself,

Yes a lot of HLA bashers don't even bother too see for themselves what HLA actually is.


but i'm almost certain the code is statically linked and/or included into the executable, thus exe bloat, whereas all versions of Windows supports msvcrt by default, so everything can be dynamically linked.


Yes when the hla standard library is used the code is statically linked but from experience is doesn't add a whole lot to the size of the executable. The standard library is optional however so if you don't want to use it you don't have to.


HLA lacks an optimizer, therefore even code output from HLL like c/c++ is generally more optimized. MSVC6/7 both have impressive optimization routines (especially msvc7), and no other compiler compares with GCC in regards to optimization.


Assemblers don't usually come with optimizers. Like, most assemblers the optimization is done by the programmer.


and this was all just comparing HLA to a HLL.


You've just indentified the problem with your argument. HLA is not an HLL.


as for assembler, HLA lacks flexibility, i would rather use TASM, or something WYSIWYG-ish, like NASM, to code something i need to be small/fast/optimized


Flexibility in terms of what? You can't write 16 bit code with it but besides that what do you mean?
Posted on 2004-09-19 17:49:17 by Odyssey
Drocon,

I like the idea of using C run-time DLLs but you must know there are not much members who desires to use those DLLs. A static library or a collection of cut&paste procedures can be more suitable for many of us.
Posted on 2004-09-20 04:50:44 by Vortex