OSNews

AtariCheck wrote:>>>>>>>>>
But, can you hook it up to the .Net library on Windows?
Probably not.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<
If you can link up any binary executable with .Net library code, then HLA will be no different. If this cannot be done, it would be a failing of .Net, not HLA (or 100s of other languages that emit object files that aren't MSIL).


AtariCheck also wrote:>>>>>>>>
I used to love assembly, but it's a bit hard to justify using this for anything other then as a learning tool.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<<

HLA has always been promoted as an educational tool. Though several die-hard programmers are writing large applications in assembly (myself included), I certainly don't expect large numbers of people to write huge apps solely in assembly language (I'll leave that fantasy to Rene "Betov" Tournois and his "assembly rebirth").

There is one large application that I've justified to write in HLA -- HLA v2.0. HLA v1.x (the current version) was written using Flex, Bison, and C (about 120,000-150,000 lines of source code). Using Flex and Bison turned out to be a mistake for many reasons, including (but not limited to): (1) HLA's grammar is not LALR, so I had to pull some incredible kludges and settle for some obscure defects when using these tools; (2) Flex and Bison are infamous for their inability to handle syntax errors in a nice fashion--not a great thing for a teaching tool; (3) Flex and Bison generate some *huge* tables and the assembler's executable file is quite large as a result. Also, the parser/scanner tables blow away the cache, producing a slower assembler than necessary. (4) The use of Flex and Bison limits the number of people who can work on the HLA source code (and not in a good way, see below).

Flex, Bison, and C were okay tools for prototyping the language. I always intended to completely rewrite HLA once the prototype was finished (which it basically has been for about a year). When I first started on HLA v2.0 several years ago, I briefly entertained using a different parser generator such as ANTLR. I quickly gave up on this because of a lack of big project experience with ANTLR. I couldn't guarantee that ANTLR wouldn't have its own source of problems, just as FLEX and Bison have had.

Because HLA is intended as a teaching tool, a high priority for HLA v2.0 was to improve error reporting and recovery. Ultimately, I chose to use a recurisve-descent predictive parser (with some hacks to handle the non-LL(1) aspects of the HLA grammar) because it's much easier to provide decent error reporting and recovery with a predictive parser.

At first, I was going to write HLA v2.0 in C. The advantage of doing so what that the code would be portable amongst OSes with little more than a recompile (assuming, of course, the code was carefully written). Ultimately, I chose to write HLA v2.0 in HLA. Why? For the simple reason that I want HLA programmers to be able to work on the HLA source code (and *only* HLA programmers). I seriously doubt that too many people outside of the HLA programming community would be interested in working on the HLA compiler, and everyone in the HLA community *knows* HLA, so using a different language would actually *reduce* the number of people who could work on the compiler (e.g., there are many HLA programmers who don't know C, so had I chosen C as the HLA implementation language I would have excluded those people).

Some might argue that implementing a large program in assembly language is crazy. People claim that assembly requires 10 times the effort of HLLs. Well, first of all this statement isn't true, and second of all, HLA contains HLL-like statements so if you're willing to work in a HLL on HLA source code, then just use the HLL-like control structures found in HLA and you enjoy most of the benefits of those HLLs in assembly. To date, I estimate that HLA v2.0 is about 50% complete (compared to the feature set in HLA v1.x). It is just over 100,000 lines of source code (including about 25,000 lines of machine-generated source code for the scanner). This compares quite favorably to the 120,000-150,000 lines of code in the current VHLL implementation of HLA v1.x. If I had to guess, I'd predict that HLA v2.0 will top out at under 200,000 lines of code. So it won't be signficantly larger (at least, if you believe those 10x figures people throw around) than the VHLL implementation. The resulting code will be quite a bit smaller (not as many large tables) and will run about two orders of magnitude faster (though this is due more to better algorithm design than the choice of assembly language).

I don't recommend that most other people should write their large business applications in assembly language, but HLA v2.0 demonstrates that many of the traditional complaints about productivity loss when using assembly language don't apply to high-level assemblers.

netpython wrote:>>>>>>>>>>>>>>>
I still prefer the good ol nasm and a text-editor.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<<<
You're not alone. NASM is the second most popular assembler on the PC today. The bottom line, though, is that people tend to prefer the first assembler they've learned and rarely get excited about switching to a new assembler later. There have only been a few mass defections from one assembler to another and such migrations generally occur for only two reasons:

1. The new assembler has a syntax that is very compatible with the old assembler (e.g., MASM->TASM, NASM->FASM)

2. The programmer switches to a new environment that doesn't support the old assembler (e.g., Windows/DOS->Linux).

When I released HLA v1.1 to the general public in Sept, 1999, I foolishly assumed that a lot of existing assembly programmers would switch from their existing assemblers to HLA because of HLA's massive feature set (far more features than MASM and TASM, for example). It only took me a short while to realize how wrong this statement was. Once people have taken the enourmous effort to learn a new assembler, they're rarely willing to switch to a new one (this is true of programming languages in general, which is why language wars are so common). For that reason, I don't encourage people who already know an assembler, such as NASM, to switch to HLA. If you already know assembly language, then you're not the target audience for HLA. I wrote HLA to help students in an assembly course learn assembly language as rapidly as possible. If you know NASM, I'll assume that you already know assembly language, so you've already achieved what I would want to help you achieve.

HLA *is* quite a bit more powerful than the other assemblers out there. I wrote HLA because MASM's macro facilities didn't quite cut it for me. Even today, no other assembler comes close to providing the language features you'll find in HLA (with due respect to Rene "Betov" Tournois' claim that "It's [RosAsm] hundred times better", RosAsm doesn't even hold a candle to HLA when it comes to assembly language features). However, the bottom line is that assembly language is sooooo marginalized today that the few people who actually do use it generally write short little functions that they call from a HLL. And as such, they never really advance to the level where they use the powerful features of *any* assembler. Lots of HLA users may *use* some advanced macros provided with the HLA Standard Library, but you don't see too many HLA users writing advanced macros of the level, for example, of the "stdout.put" macro. Even NASM or FASM users rarely write sophisticated macros that tax the abilities of their assemblers, so it's hard to imagine a typical NASM user wanting to switch to HLA because HLA offers more "power".
Cheers,
Randy Hyde