Hi Randy,

You seem to be busy. However, there's some great news for ya. But some suggestions too.

First the news:
1. I'm planning on a strategy to lure programmers using other languages to assembly and I want people here to support it.
2. I already implemented some of it and I am waiting for a proper response.

Now the suggestions:
1. I've tried using HLA but since I'm already accustomed to MASM and FASM, I'm find it difficult to migrate to it. Some of the reasons why and their solutions:

Reason 1:
HLA is dependent and not yet a "true assembler", but sort of a preprocessor.

Solution:
You could make HLA into a highly capable assembler first which also emits code for FASM and MASM. May be if you can help me out with some resources on how to build compilers, I would join you in maintaining it.

Reason 2:
Intel-style Syntax. I and many others would prefer "mov dest, src" over "mov src, dest."

Solution:
You could add a flag option to HLA that allows users to switch between the two so that those who have already learnt either of the two can write in their own style. I know there's the asm keyword, but still.

Reason 3:
Use of parentheses. To tell you a fact, this is one thing that annoys me most. I prefer the simple no-parentheses syntax of assembly. End-statement terminators (;)are OK.

Solution:
Make the parentheses optional please.

I don't think you may agree with me on these, but I would love to use HLA and these are some of the problems I've been facing migrating to it. I simply get way too many errors on my face when I miss those parentheses.

Regards,
Art
Posted on 2003-12-01 09:23:22 by art_sands
My biggest problem with HLA is its lack of windows example codes. The book on Windows assembly in HLA started out fine, but then switched to graphics without continuing the basic stuff most programmers use (complex dialogs, menus, etc.). It now seems to be halted all together now. Any plans to continue it?

The AoA book is fine, one of my better purchases, but I need a complete WPinHLA before anything else.

One remedy would be more example codes. Several HLA projects I'm working on are just dead now because I can't do something that would be simple using Java or even MASM (which I have switched to presently).

Solution:
You could make HLA into a highly capable assembler first which also emits code for FASM and MASM. May be if you can help me out with some resources on how to build compilers, I would join you in maintaining it.


I think this is planned for version 2.0 But further development for this also seems to be on the back-burner. But I don't blame Randy. A guy's gotta eat, you know.

Reason 2:
Intel-style Syntax. I and many others would prefer "mov dest, src" over "mov src, dest."


I actually like this syntax. More intuitive. But I agree that there should be an option for reversing it. Maybe a program switch like ?@stdasm :=ture; (false by default to maintain backward compatibility).


Reason 3:
Use of parentheses. To tell you a fact, this is one thing that annoys me most. I prefer the simple no-parentheses syntax of assembly. End-statement terminators (are OK.


After 100 instructions, we have at least 200 brackets, usually more. This annoyance also exists in FASM with its addressing mode. It would be nice to have brackets optional, but it's something I can live with.

HLA is already bloated at over 1.3 MB and a rather slow compiling speed compared to other compilers (it has to parse first, then call another assembler). At this point, anything added should be absolutely necessary.

I would prefer an HLA compiler written in HLA with a Windows front-end and one that assembles directly without having to parse to another language first. Perhaps during the re-write, such items as you mention above can be added in as a bonus.
Posted on 2003-12-01 11:14:20 by Kain

Intel-style Syntax. I and many others would prefer "mov dest, src" over "mov src, dest."


Not a bad idea, Gas does it. I would probably be double the work from Randy though. :grin:


Reason 3:
Use of parentheses. To tell you a fact, this is one thing that annoys me most. I prefer the simple no-parentheses syntax of assembly. End-statement terminators are OK.

Solution:
Make the parentheses optional please.


Maybe the intel style syntax wouldn't use parentheses.


My biggest problem with HLA is its lack of windows example codes. The book on Windows assembly in HLA started out fine, but then switched to graphics without continuing the basic stuff most programmers use (complex dialogs, menus, etc.). It now seems to be halted all together now. Any plans to continue it?


I don't think the lack of windows example code is a problem because it's
easy to convert masm code to HLA.


One remedy would be more example codes. Several HLA projects I'm working on are just dead now because I can't do something that would be simple using Java or even MASM (which I have switched to presently).


This is a problem and thats why we need HLA 2.0. If an assembler is not
written for HLA soon the beginners will use it to learn asm, then
move on to another assembler, a faster assembler.


HLA is already bloated at over 1.3 MB and a rather slow compiling speed compared to other compilers (it has to parse first, then call another assembler). At this point, anything added should be absolutely necessary.


This is an issue in HLA i think needs to be addressed immediately if HLA
is to be used for real work instead of being a tool to ease HLL
programmers into assembly language. Randy has said that all he needs to
do to get compile speeds comparable with masm is to rewrite the symbol
table routines in HLA so let's hope he's recognizes the importance of
this soon. :)
Posted on 2003-12-01 12:10:41 by Odyssey
I don't think the lack of windows example code is a problem because it's
easy to convert masm code to HLA.


Not so easy. I've tried on several occasions and just got stomped. I posted one example of this earlier on this forum where I couldn't get a richedit control to load up text. My program gets stuck in an infinite loop at the stream-in procedure. Masm-HLA addressing don't translate directly it seems, there must be something wrong with my pointers, I just can't find what.

I've had problems with complex dialogs also. Easy enough in masm, roadblock (at least for me) in hla.
Posted on 2003-12-01 17:20:33 by Kain
Originally posted by art_sands
Hi Randy,

You seem to be busy. However, there's some great news for ya. But some suggestions too.

Been out of town...



First the news:
1. I'm planning on a strategy to lure programmers using other languages to assembly and I want people here to support it.
2. I already implemented some of it and I am waiting for a proper response.


Fantastic.



Now the suggestions:
1. I've tried using HLA but since I'm already accustomed to MASM and FASM, I'm find it difficult to migrate to it. Some of the reasons why and their solutions:

Reason 1:
HLA is dependent and not yet a "true assembler", but sort of a preprocessor.


HLA v2.0 will solve this problem. But then again, to the average user, what does it matter? Other than initial installation, who cares that HLA emits assembly to be processed by some other assembler? For example, GCC works *exactly* this way (it generates Gas code). GCC users don't really care.

There are some *big* advantages to the source code translation -- specifically you get an automatic conversion from HLA to MASM, Fasm, Tasm, Gas, etc. Even in HLA v2.0, which will support "direct to object code assembly", this feature will still be available as a lot of people really like it.


Solution:
You could make HLA into a highly capable assembler first which also emits code for FASM and MASM. May be if you can help me out with some resources on how to build compilers, I would join you in maintaining it.


HLA v1.x is a *prototype*. It has been kludged as far as I want to take it (indeed, much farther than I ever intended to take it). I'm not real interested in having people maintain it. I'll maintain it with respect to eliminating bugs at this point, but the real work to be done now is HLA v2.0. HLA v2.0 is a complete rewrite of the whole assembler (in HLA, btw). That's the code base that I'll openly encourage other people to work on.


Reason 2:
Intel-style Syntax. I and many others would prefer "mov dest, src" over "mov src, dest."


You can do this today using macros and the #rw/#id compile-time statements.
But there are good reasons for the src,dest organization; not the least of which AoA uses that syntax. Also, beginners (who've never seen x86 assembly before) find it more readable. And there are some consistency reasons for this, as well. But like I said... feel free to change it if you like. HLA v1.x has that capability today.



Solution:
You could add a flag option to HLA that allows users to switch between the two so that those who have already learnt either of the two can write in their own style. I know there's the asm keyword, but still.

Or you could just #include the macro set :-)


Reason 3:
Use of parentheses. To tell you a fact, this is one thing that annoys me most. I prefer the simple no-parentheses syntax of assembly. End-statement terminators (;)are OK.

Solution:
Make the parentheses optional please.


The parentheses are one of the things that make HLA programs more readable that standard assembly code. My apologies for those who aren't touch typists, but (from a language design point of view) HLA's functional notation has a lot of things going for it.

There is nothing you can do about this in HLA v1.x. In HLA v2.0 I'm working on a special kind of macro called a "template" that *may* solve this problem for you. However, I've not put enough thought into templates to convince myself they're going to work as well as I'd like, so we'll have to see how it turns out.



I don't think you may agree with me on these, but I would love to use HLA and these are some of the problems I've been facing migrating to it. I simply get way too many errors on my face when I miss those parentheses.


But that's just a syntax issue and after using HLA for a little while you'll start to get used to it. There are *many* benefits to those parentheses. Readability is just one.

FWIW, HLA v2.0 is coming along. I'm working on the compile-time language stuff right now (#if, #while, etc.). Currently, declarations are in pretty good shape, the lexer is done, and the expression evaluator is in great shape. When I finish the compile-time language, the code will handle most everything except the actual machine instructions. At that time, I'm going to make the source code available because the code at that point will make a solid foundation for anyone wanting to write an assembler (i.e., fast lexer, symbol table management, compile-time language & macros, and declarations). Someone who wants to write an "intel-syntax" assembler (whatever that is) would only have to supply the code to assemble the machine instructions to produce a complete assembler (even more powerful than HLA v1.x, in fact).

I'm still a couple of months away from this point, but it is coming soon.

BTW, based on the tests I've run thus far, the HLA v2.0 code is *much* faster than most other assemblers I've benchmarked (e.g., processing 25,000 const declarations in a sample file I wrote took over 90 seconds with HLA v1.x and only 0.3 seconds with the HLA v2.0 code).

Cheers,
Randy Hyde
Posted on 2003-12-01 18:24:38 by rhyde
Originally posted by Kain
My biggest problem with HLA is its lack of windows example codes. The book on Windows assembly in HLA started out fine, but then switched to graphics without continuing the basic stuff most programmers use (complex dialogs, menus, etc.). It now seems to be halted all together now. Any plans to continue it?

Yes.
There are three reasons it is currently halted: (1) I'm getting material back from my publisher on my next book: "Write Great Code" and that book must take precedence. (2) I'm doing some contract work in the evenings, which is eating up a lot of free time. (3) I'm trying to make a small amount of progress on HLA v2.0 which has been halted for about two years.


The AoA book is fine, one of my better purchases, but I need a complete WPinHLA before anything else.

Hope to get back to work on in soon.


One remedy would be more example codes. Several HLA projects I'm working on are just dead now because I can't do something that would be simple using Java or even MASM (which I have switched to presently).

Feel free to ask if you're stuck on something.



HLA is already bloated at over 1.3 MB and a rather slow compiling speed compared to other compilers (it has to parse first, then call another assembler). At this point, anything added should be absolutely necessary.

At this point, I'm loathe to add anything new. I'm even loathe to clean up the code ("if it works, don't fix it..."). I have, in the past, gone in and cleaned stuff up, but this invariably introduces new defects. Right now, the effort is better spent on HLA v2.0.

As noted in an earlier post in this thread, HLA v2.0 is looking to be *much* faster than other assemblers. It does without saying that it blows HLA v1.x away. On declarations, I'm getting 100,000 lines/second assembly time. Optimization is the only "time bottleneck" left in the code I've yet to write. So I expect HLA v2.0 to remain one of the faster assemblers around.

BTW, HLA v2.0 will have replaceable code generators. So it will be easy to write your own code generator (binary or assembly output). Originally, I was going to drop the "assembly" output of HLA; but this turns out to be a *very* popular feature of HLA, so HLA v2.0 will have some code generator modules that generate assembly (as well as native object modules for various OSes).



I would prefer an HLA compiler written in HLA with a Windows front-end and one that assembles directly without having to parse to another language first. Perhaps during the re-write, such items as you mention above can be added in as a bonus.


HLA v2.0, which is written in HLA, will create an in-memory intermediate format. The replaceable code generator modules will read this data structure and produce whatever output is selected. I intend to supply PE/COFF, ELF, MASM, Gas, FASM, NASM, and TASM code generator modules fairly early on. Eventually, there will be others, as well.
Cheers,
Randy Hyde
Posted on 2003-12-01 18:34:34 by rhyde

FWIW, HLA v2.0 is coming along


Great news :) music to my ears. Been waiting for this for years :grin:


As noted in an earlier post in this thread, HLA v2.0 is looking to be *much* faster than other assemblers. It does without saying that it blows HLA v1.x away. On declarations, I'm getting 100,000 lines/second assembly time. Optimization is the only "time bottleneck" left in the code I've yet to write. So I expect HLA v2.0 to remain one of the faster assemblers around.

:alright:

I'm really excited about HLA 2.0, glad to hear work is being done on it and if it delivers what it promises I think it could be a killer app for assembly. :)
Posted on 2003-12-01 18:40:52 by Odyssey


This is an issue in HLA i think needs to be addressed immediately if HLA
is to be used for real work instead of being a tool to ease HLL
programmers into assembly language. Randy has said that all he needs to
do to get compile speeds comparable with masm is to rewrite the symbol
table routines in HLA so let's hope he's recognizes the importance of
this soon. :)


Speed will get addressed, but size isn't an issue in my mind.
Though HLA v2.0 will not have the huge parser and lexer tables that Flex/Bison have generated for HLA v1.x, HLA v2.0 still has a lot of data. And that's what consumes most of the disk space. Currently, for example, HLA v2.0 is about 30,000 lines of code and the exe file is around 240K. Most of the space is large data tables. Mainly because I'm trading off space for faster performance in HLA v2.0. (Who really cares if the assembler is 1.5 MB? People do care if it runs slowly.) Above and beyond the EXE file size, HLA consumes a *lot* of memory. I was very generous with symbol table fields, I use memory-mapped files, I'm not afraid to use memory-hungry data structures that produce faster results than memory-frugal structures (When the average new machine ships with 256 MB of RAM, I'm not concerned that a complex assembly with HLA v2.0 might, conceivably, consume up to 16MB of RAM during operation, that just isn't an issue to me; I do, however, want HLA to be one of the fastest assemblers around and I'm not afraid to trade off RAM for speed).
Cheers,
Randy Hyde
Posted on 2003-12-01 18:42:45 by rhyde

I do, however, want HLA to be one of the fastest assemblers around and I'm not afraid to trade off RAM for speed).


I don't care if the assembler is 5 mb as long as it as fast or faster than masm. :)


I'm still a couple of months away from this point, but it is coming soon.

Months away sounds better than years away. :)

HLA 2.0 will be the final nail in masm's coffin :grin:
Posted on 2003-12-01 18:50:44 by Odyssey
WOOOOOHOOOOO!!!

(singin)

ha ha ha, ha ha ha....i'm waitin for hla ta come home....coz thats whats gonna spin...the world round-n-round-n-round.

Hey Randy,

i'm sorta impatient. Can't wait, can't wait. No, gotta wait, gotta wait! Alright I'm waitin.

Don't make it years, or even months. Days is much better....lol. Take your time. Enjoy!

Oh, Size concerns: btw try using "UPX --best hla.exe". that might help. Jeremy Collakes PECompact is good too, but i don't use it. PE Rebuilder is cool too. You can distribute the package using a self-extracting exe made from a 7zip compressed archive. I've tried em and they occupy 30-70% less space than ordinary zip files. Or you can give cab files a hand (LZW compression). For the documentation, use an HTML cleaner (HTML tidy) and compressor (coz nobody amongst us is ever gonna read the HTML behind the documentation). For text files, don't replace tabs with spaces. And use Cascading Style Sheets for the documentation. Compress the docs into a CHM file and distribute (FAR from HelpWare is good for this plus it also searches and replaces text in files.) There's lots more to keep sizes low. I surely don't wanna make this very big...lol

Regards,
Art
Posted on 2003-12-01 19:04:48 by art_sands
Well, that's some great news. When I heard you say elsewhere that you hoped to get hla 2 done sometime before you died, I steeled myself for years of wait.


HLA v2.0, which is written in HLA, will create an in-memory intermediate format. The replaceable code generator modules will read this data structure and produce whatever output is selected. I intend to supply PE/COFF, ELF, MASM, Gas, FASM, NASM, and TASM code generator modules fairly early on. Eventually, there will be others, as well.


Will HLA 2.0 be a command line tool like its predesessor?
Posted on 2003-12-01 21:10:18 by Kain
What??? :confused:

Hey Randy,

DONT DIE!! I want HLA V10.

Regards,
Art:grin:
Posted on 2003-12-01 21:39:45 by art_sands
I saw him on techtv, he didn't look that old :grin:
Posted on 2003-12-01 22:03:29 by Odyssey
Originally posted by art_sands
hla ta come home....coz thats whats gonna spin...the world round-n-round-n-round.


Oh, Size concerns: btw try using "UPX --best hla.exe". that might help. Jeremy Collakes PECompact is good too, but i don't use it. PE Rebuilder is cool too. You can distribute the package using a self-extracting exe made from a 7zip compressed archive. I've tried em and they occupy 30-70% less space than ordinary zip files. Or you can give cab files a hand (LZW compression). For the documentation, use an HTML cleaner (HTML tidy) and compressor (coz nobody amongst us is ever gonna read the HTML behind the documentation). For text files, don't replace tabs with spaces. And use Cascading Style Sheets for the documentation. Compress the docs into a CHM file and distribute (FAR from HelpWare is good for this plus it also searches and replaces text in files.) There's lots more to keep sizes low. I surely don't wanna make this very big...lol

Regards,
Art


Actually, it *is* possible to clean up a lot of the empty space in the EXE with nothing more than the Microsoft Linker. For example, were I to declare large uninitialized arrays in the STORAGE section rather than the STATIC section, all the space consumed by those arrays would be shaved from the EXE file (with a placeholder that tells the loader to allocate the storage when the program loads from memory). However, you take a *big* performance hit for doing this. If your EXE file is basically a memory image (after relocation), then Windows and use the virtual memory subsystem to quickly load pages (4096 bytes) from the file directly into memory. However, if you pull tricks to shrink the EXE file down, Windows can no longer do this. It has to read and interpret blocks of data in the EXE file, swap blocks of memory (including read-only code) to a different swap file, stuff like that, during execution. This results in much slower performance during execution. It also means that before the program runs, the loader has to load the entire file into memory, rather than being able to read only a "working set" of pages directly from the executable file. All in all, you take a *big* performance hit for this. Of course, once the file is loaded into memory (and swapped to the new swap file) things are fine. But the startup costs are huge (a couple of seconds for a decent sized program). Considering that HLA v2.0 will wind up compiling fairly large files very quickly, it would turn out that Windows would spend more time *loading* HLA into memory than actually doing any real work.

This is why I get rather amused at all the people who try to write 600 byte Hello World programs. They simply don't realize the performance hit they're taking when they try to compact code that way (not that it matters for a Hello World program, but for real applications, it most certainly does).

Cheers,
Randy Hyde
Posted on 2003-12-02 12:42:59 by rhyde
Originally posted by Kain


Will HLA 2.0 be a command line tool like its predesessor?


Yes. However, it is being designed to integrate better with IDEs.

If you look at the original "road map" I created for HLA, you'll find that
I planned on an IDE for v3.0. One step at a time...
Cheers,
Randy Hyde
Posted on 2003-12-02 12:44:36 by rhyde
Hi Randy,

I'm really looking forward to try you new version of HLA! Keep up the good work! ;)

Best regards,
Tommy
Posted on 2003-12-02 12:50:35 by Tommy



Yes. However, it is being designed to integrate better with IDEs.

If you look at the original "road map" I created for HLA, you'll find that
I planned on an IDE for v3.0. One step at a time...
Cheers,
Randy Hyde


A further curiosity if you will. Will it have the same switches as the current version?

If not and you have already mapped the new switches, can you provide a list?
Posted on 2003-12-02 15:24:22 by Kain



A further curiosity if you will. Will it have the same switches as the current version?

If not and you have already mapped the new switches, can you provide a list?


Haven't gotten anywhere *near* that far. Command line processing will be one of the last things I do.

There will, clearly, be some new switches added (e.g., for object code output in COFF or ELF format as well as an option to produce a listing). I might get tempted to tidy things up a bit, but most of the options should survive in one form or another.

Note that if I *do* change them around a bit (breaking makefiles the world over), it wouldn't be that hard to modify the "hla.c" file in HLA v1.x to call HLA and translate the command line options appropriately (in much the same way the HLA.EXE program currently translates command line options for HLAPARSE.EXE).
Cheers,
Randy Hyde
Posted on 2003-12-02 19:58:05 by rhyde
Oh hi randy,

About the exe compression, i was saying that you should only compress it *to distribute it*. I haven't used Collake's stuff, so i don't know about it, but UPX also unpacks the executable to its prior state. Normal zip compression does not achieve the levels that UPX is able to achieve with executables. Once the files are on the users' computers, they can be automatically unpacked by UPX (perhaps in the setup), which I think is freely distributable.

Also, i think UPX claims to not affect performance, even though I don't recommend it, but you should test UPX-compressed executable performances with normal performances.

That should solve the *distribution* size concerns. Thanks for replying.

Regards,
Art
Posted on 2003-12-05 04:48:07 by Art Sands

Oh hi randy,

About the exe compression, i was saying that you should only compress it *to distribute it*. I haven't used Collake's stuff, so i don't know about it, but UPX also unpacks the executable to its prior state. Normal zip compression does not achieve the levels that UPX is able to achieve with executables. Once the files are on the users' computers, they can be automatically unpacked by UPX (perhaps in the setup), which I think is freely distributable.

Also, i think UPX claims to not affect performance, even though I don't recommend it, but you should test UPX-compressed executable performances with normal performances.

That should solve the *distribution* size concerns. Thanks for replying.

Regards,
Art


The installation program I use already does compression- might not be the greatest compression available, but it isn't something I can use without switching to another installation system (and whether that other one would be any better is questionable). For the installation program, a self-extracting .EXE is necessary (some people don't have an unzipper program). As for the other modules, I'm leery of saving a few bytes if the cost is the need for the user to download a different unzipping program. If winzip or pkunzip and unpackage the file produced, that's one thing. But if it takes a special unpacking program, you've put one more roadblock between the user and HLA.

However, keep me informed. If something *substantially* better does come along (or is available), I can make a secondary set of files available for people who have the ability to deal with such files and want to save some time on downloads.
Cheers,
Randy Hyde
Posted on 2003-12-05 09:27:07 by rhyde