After a false start, HLA v1.42 (for Windows) is now available.
Read all about the modifications at

http://webster.cs.ucr.edu/Page_hla/0_hla_dnld.html

The two most important features worth mentioning here
are an experimental FASM code generator and the fact
that I've sped up symbol table searches in namespace by
an order of magnitude.

I'm currently working on the Linux version. I hope to have that
up in the next day or so.

Cheers,
Randy Hyde
Posted on 2003-03-18 21:50:06 by rhyde
Hi Randy,

There seems to be a problem downloading the executables :

The requested URL /Page_hla/1_42Release/1_42HLA.ZIP was not found on this server.
Posted on 2003-03-18 22:25:25 by donkey

Hi Randy,

There seems to be a problem downloading the executables :

The requested URL /Page_hla/1_42Release/1_42HLA.ZIP was not found on this server.


Yikes, should all be lower case.
http://webster.cs.ucr.edu/Page_hla/1_42Release/1_42hla.zip
I'll fix that tomorrow. In the meantime, just type in this URL.
Randy Hyde
Posted on 2003-03-18 22:55:35 by rhyde
All the work you are doing is taking its toll.
Posted on 2003-03-18 23:04:39 by Odyssey

All the work you are doing is taking its toll.


Actually, once again UCR is changing the access policy and I'm
having to learn new ways to upload files. It screws me up
every time they do this (constant battle with the hackers, I guess).
Cheers,
Randy Hyde
Posted on 2003-03-18 23:24:28 by rhyde
I have been some questions about Fasm output generation. I had to try different commandline options before I figuered out how to get HLA to generate Fasm output. First I tried hla -fasm hw.hla because I got a message saying something about masm output form being chosen. I then tried hla -sf -fasm hw.hla. This worked but in a strange way. When I included the stdout header file alone the exe file generated was about 5kb but when I included stdlib.hhf instead the size jumped to 19 kb. I found a way around this though. I created the object file first using hla -sf hw.hla then linked it with hla hw.obj. The exe size was 5kb.What I would like to know is this the right way to generate Fasm output?
Posted on 2003-03-19 06:04:52 by Odyssey

I have been some questions about Fasm output generation. I had to try different commandline options before I figuered out how to get HLA to generate Fasm output. First I tried hla -fasm hw.hla because I got a message saying something about masm output form being chosen. I then tried hla -sf -fasm hw.hla. This worked but in a strange way. When I included the stdout header file alone the exe file generated was about 5kb but when I included stdlib.hhf instead the size jumped to 19 kb. I found a way around this though. I created the object file first using hla -sf hw.hla then linked it with hla hw.obj. The exe size was 5kb.What I would like to know is this the right way to generate Fasm output?


Well, the correct way to generate FASM output is to use the -sf command line option.
If you also want FASM to assemble the file for you, then you need to place the -fasm
option *after* the -sf on the command line.

However, what you're really asking is how to produce the smallest possible executable
and that's a different question altogether.
First of all, any linkage with the HLA Standard Library is going to to produce relatively
large executables compared to a straight FASM assembly file. The reason is two-fold.
First of all, the HLA standard library routines call one another, so linking in something
simple like 'stdout.put("Hello World" nl ):' links in stdout.put, which links in fileio.puts,
which also links in a couple of other support routines as well. In addition, those support routines also have some storage variables (a BSS segment) and some static variables (a DATA segment). Plus you've got the Win32 API interface segment and a code segment. Regardless of the size on the disk, the executable is going to require about 16K of memory (this is true *regardless* of the assembler you're using if you wind up using four sections/segments in the program). What FASM does is pack (as best I can tell), is pack these sections together. This makes for small EXE files, but it actually slows down program loading and execution. It's irrelevant for small programs (like hello world) where moving around two or three blocks that are smaller that 4K is a trivial thing to to. However, as the executable files get larger and you have large blocks of static and bss objects, *not* having those sections aligned on 4K boundaries in the object file can get very expensive. That's why Microsoft tools (and HLA) generally opt for sections that have a minimum size of 4Kbytes - to keep those sections aligned on 4K boundaries. It makes "hello world" programs look bad, but for larger programs, wasting up to 4K per segment is a small price to pay for much better performance.

If you really want the world's smallest HLA "Hello World" program, you need to take a look at the following White Paper I've written:

http://webster.cs.ucr.edu/Page_hla/WhitePapers/DoingUnits.html

This explains how you can take control of the code generation and linkage process and reduce the size of your code.

One question you've asked, that this article will answer, is why the code you've linked including only stdout.hhf is so much smaller than the code that you linked when including the whole HLA standard library. The answer is simple: exceptions. If you include the excepts.hhf header file (which stdlib.hhf automatically includes), this notifies the HLA compiler to link in a full exception handler. That full exception handler includes nice English messages (i.e., text strings appearing in the code segment) for the several dozen HLA exceptions. If you don't include excepts.hla, then HLA links in an abbreviated "catch-all" exception handler with only a single error message. The size of all those strings you've linked in is the major reason for the file size differences. You'll definitely want to take a look at the above article for more details on the "overhead" associated with using HLA.

BTW, my apologies for not documenting the -sf and -fasm command line parameters.
I noticed that myself earlier today (nor did I document the new -p and -obj command line parameters or the hlatemp environment variable). I've corrected this already and the explanation will appear with HLA v1.43 (which I put up as soon as I correct another couple of errors I found in HLA today).
Cheers,
Randy Hyde
Posted on 2003-03-19 20:41:54 by rhyde
I have a simple hello world program that includes stdlib.hhf. When I compile using masm its 5kb but with Fasm it is 19kb. Why is this?
Posted on 2003-03-19 21:29:12 by Odyssey

I have a simple hello world program that includes stdlib.hhf. When I compile using masm its 5kb but with Fasm it is 19kb. Why is this?


You must only be including stdout.hhf, not stdlib.hhf in the MASM code.
Including stdlib.hhf sets a flag during compilation that tells HLA to link in the full exception handling package (including tons of error message text, which is largely responsible for
the larger size of the programs). For details on how to control this, see
http://webster.cs.ucr.edu/Page_hla/WhitePapers/DoingUnits.html
In particular, take a look at the section labelled "Why Is HelloWorld So Big?"
Cheers,
Randy Hyde
Posted on 2003-03-25 21:00:22 by rhyde
Ooops,
Wrong reference in my last post.
Although "Why is the Hello World Program So Big?"
is illuminating, it doesn't describe the issue with exceptions.
See the section titled "Overhead Associated with Exceptions"
in the same document.
Cheers,
Randy Hyde
Posted on 2003-03-25 21:03:22 by rhyde
No its the same program. I compiled it with masm using hla hw.hla and fasm with hla -sf -fasm hw.hla. With masm hw.exe = 5kb, with fasm hw.exe = 19kb.
Posted on 2003-03-25 21:06:09 by Odyssey

No its the same program. I compiled it with masm using hla hw.hla and fasm with hla -sf -fasm hw.hla. With masm hw.exe = 5kb, with fasm hw.exe = 19kb.


Hmmm....
Something's weird. I just tried it and got 16K for MASM and 32K for FASM.
Here's what I suspect (though it doesn't begin to explain the 16K difference):
MASM doesn't really support BSS sections, while FASM does. When you compile
with FASM, but link with libraries assembled with MASM, you probably get some
interesting interactions in the object code output file because of the BSS issue.
I have yet to rework all the makefiles so I can compile the HLA Standard Library
with FASM (FASM output, after all, is experimental right now :-) ). I suspect that
when I get around to doing this, we'll see a big difference in the object code
emission. But that's just a theory at this point.

BTW, if I drop the stdlib.hhf include and include stdio.hhf and stdout.hhf instead,
both compiles come in at 16K, which is what I'd expect under Win2K with the
version of MS-link that I'm using. If you're getting 5K, you're probably using a
different linker than me or operating under win98.
Cheers,
Randy Hyde
Posted on 2003-03-25 22:25:09 by rhyde
I am using windows 98 and the linker that comes with the masm32 package.
Posted on 2003-03-26 04:55:24 by Odyssey
I suggest you to change your page background to fushia, it will probably be easier to read... :rolleyes:
Posted on 2003-03-26 12:46:05 by JCP
:confused:
What page background?
Posted on 2003-03-26 13:00:30 by Odyssey
The one in the original message of this thread : I can't read anything !
Posted on 2003-03-26 13:03:57 by JCP
How would I go about doing that?
Posted on 2003-03-26 13:22:00 by Odyssey
It was for Randall...
Posted on 2003-03-26 13:55:35 by JCP
My bad :grin: I was wondering if you accidently posted the message in the wrong thread.
Posted on 2003-03-26 15:01:48 by Odyssey