During a recent compile of "HLA Adventure", I discovered something unusual. The compiler took over 5 or 6 minutes to compile the file "west.hla", which is the main source for the game.
Someone over at the masmforum.com board suggested it was because somewhere in my source I was using initialized arrays (rather than global arrays). Could this contribute to a slower compiling time by HLA/MASM?
I haven't looked at the assembly source for my game in ages (the source code to the game -- as well as the game itself -- can be found at):
http://members.tripod.com/~panks/hlaadv.html
or
http://www.geocities.com/dunric/westfront.html
(just scroll down to "12. HLA Adventure" under "DOS/Windows games")
Just for fun, I uploaded version 2.08 of "HLA Adventure" for anyone who is interested. I spent about 15 minutes reworking and balancing the fighting engine. I also fixed an usual bug whereby someone might enter:
>dfsgfdssfd hobbit
and the game would kick the player into a random room, like so:
Intersection
You are facing an intersection in the forest. Paths head
off in four directions here. To the south, the forest becomes
oppressive and dark. To the east, there is far more sunlight.
There is a portal here, pulsating white light.
Exits: <north,south,east,west>
wolf
>
Oh yeah, that brings up another addition. I also added "portals" around the game whereby the player can "teleport" between them. Interesting concept I thought of while in a lucid dream state the other night. Sometimes the zen of nothing is better than the zen of everything. ;)
Back to sleep I go. :)
Sincerely,
Paul Allen Panks (also known as "dunric" or "pappy")
dunric@yahoo.com
ICQ# 12234336
Someone over at the masmforum.com board suggested it was because somewhere in my source I was using initialized arrays (rather than global arrays). Could this contribute to a slower compiling time by HLA/MASM?
I haven't looked at the assembly source for my game in ages (the source code to the game -- as well as the game itself -- can be found at):
http://members.tripod.com/~panks/hlaadv.html
or
http://www.geocities.com/dunric/westfront.html
(just scroll down to "12. HLA Adventure" under "DOS/Windows games")
Just for fun, I uploaded version 2.08 of "HLA Adventure" for anyone who is interested. I spent about 15 minutes reworking and balancing the fighting engine. I also fixed an usual bug whereby someone might enter:
>dfsgfdssfd hobbit
and the game would kick the player into a random room, like so:
Intersection
You are facing an intersection in the forest. Paths head
off in four directions here. To the south, the forest becomes
oppressive and dark. To the east, there is far more sunlight.
There is a portal here, pulsating white light.
Exits: <north,south,east,west>
wolf
>
Oh yeah, that brings up another addition. I also added "portals" around the game whereby the player can "teleport" between them. Interesting concept I thought of while in a lucid dream state the other night. Sometimes the zen of nothing is better than the zen of everything. ;)
Back to sleep I go. :)
Sincerely,
Paul Allen Panks (also known as "dunric" or "pappy")
dunric@yahoo.com
ICQ# 12234336
Hi Paul,
This paragraph from AoA gives an explanation:
http://webster.cs.ucr.edu/Page_AoAWin/HTML/Arraysa3.html#1010610
Regards,GJ
Someone over at the masmforum.com board suggested it was because somewhere in my source I was using initialized arrays (rather than global arrays). Could this contribute to a slower compiling time by HLA/MASM?
This paragraph from AoA gives an explanation:
http://webster.cs.ucr.edu/Page_AoAWin/HTML/Arraysa3.html#1010610
Regards,GJ
Cool, thanks Joe. That's right on with what others suggested. I think I'll try out MASM v6.11, and see if that improves the compile times. Waiting five minutes for a compile permits a coffee break and then some. About the only thing longer was waiting for the Commodore 64 BASIC interpreter to process decimal-to-hex numbers or Machine Language from BASIC. Wow, that was long!
I do have several other adventures if anyone is interested. Although not written in HLA, they follow the same gameplay rules as "HLA Adventure":
http://www.geocities.com/dunric/westfront.html
You can even find some C64/128 adventure games I wrote for play on the VICE or other Commodore emulators out there. In 9 years I've programmed more than I ever thought I would. Getting a Commodore 128 in 1985 did the trick. ;)
Sincerely,
Paul Panks
dunric@yahoo.com
I do have several other adventures if anyone is interested. Although not written in HLA, they follow the same gameplay rules as "HLA Adventure":
http://www.geocities.com/dunric/westfront.html
You can even find some C64/128 adventure games I wrote for play on the VICE or other Commodore emulators out there. In 9 years I've programmed more than I ever thought I would. Getting a Commodore 128 in 1985 did the trick. ;)
Sincerely,
Paul Panks
dunric@yahoo.com
During a recent compile of "HLA Adventure", I discovered something unusual. The compiler took over 5 or 6 minutes to compile the file "west.hla", which is the main source for the game.
Someone over at the masmforum.com board suggested it was because somewhere in my source I was using initialized arrays (rather than global arrays). Could this contribute to a slower compiling time by HLA/MASM?
I
Sincerely,
Paul Allen Panks (also known as "dunric" or "pappy")
dunric@yahoo.com
ICQ# 12234336
I am almost sure that the problem is not static arrays, but the fact that you've got so many
invocations of the stdout.put macro in your source file (I count a little bit better than 1,500
invocations of this macro).
Each invocation of stdout.put expands to approximately 400-500 lines of code (more, if you've got
multiple parameters, which you usually do).
Here's what HLA v1.49 reports for the number of lines and compile time-
HLA (High Level Assembler)
Released to the public domain by Randall Hyde.
Version Version 1.49 build 8101 (prototype)
Win32 COFF output
Using MASM assembler
MASM output
Files:
1: west.hla
Compiling 'west.hla' to 'west.asm'
using command line
HLA (High Level Assembler) Parser
Released to the public domain by Randall Hyde.
Version Version 1.49 build 8099 (prototype)
File: west.hla
Output Path: ""
Compiling "west.hla" to "west.asm"
Compilation complete, 1545291 lines, 305.908 seconds, 5051 lines/second
Ouch! One and a half *Million* lines of code!
It's not surprising it took over five minutes to compile on my 2GHz machine at work.
Also note that 5051 lines/second compilation rate is about half what HLA normally
does; again, this is a result of the fact that the stdout.put macro contains a lot of
compile-time statements that HLA must interpret during compilation.
Scanning through your code, I immediately notice two things that you can do to
dramatically speed up compilation.
First of all, in many of your calls to stdout.put, you write code like the following:
stdout.put( "some line of text", nl ); // Notice the comma between the string and "nl".
When stdout.put has "n" parameters, it winds up expanding to n*(400 to 500) lines of
code. So this simple call typically expands to between 800 and 1,000 lines of code.
As it turns out, there is no need to supply stdout.put with two parameters here.
The "nl" identifier is an HLA TEXT object, which means HLA expands nl to the text sequence
"#$d #$a" whenever it encounters "nl" in the source file; i.e., the above is equivalent to:
stdout.put( "some line of text", #$d #$a );
Whenever HLA sees two adajent strings (or characters, or combinations of the two) it combines
them into a single string, hence the "#$d #$a" above gets concatenated to form a single
string containing the two characters <cr><lf>.
However, we could also write this statement as follows:
stdout.put( "some line of text" nl ); // Note that there is no comma here.
Now, HLA will concatenate that <cr><lf> sequence to the end of the string and, voila, you have
only one operand instead of two. So HLA only has to compile *half* the number of statements inside
the stdout.put macro.
Next Problem:
When you want to print multiple lines of text, there is no need to call stdout.put for each
line of text - just create a single string with all the lines of text you want displayed. This is a classic
example of "thinking in assembly" rather than thinking in a HLL.
E.g.,
stdout.put( "line 1" nl );
stdout.put( "line 2" nl );
stdout.put( "line 3" nl );
becomes:
stdout.put
(
"line 1" nl
"line 2" nl
"line 3" nl
);
Note that this is still just *one* operand and *one* string because HLA concatenates
all adjacent strings (without any other intervening symbols) into a single string.
I would even argue that this scheme is *more readable* than a long sequence of stdout.put
invocations (much less clutter). Because most of your stdout.put calls are part of a multiline
sequence printing "room" descriptions, I think you'll find that by using the two tricks I've given
you so far, you'll speed up compilation by an order of magnitude.
Also note: by using a single call to stdout.put, you'll reduce the size of your executable
program by a fair amount because you'll have only one call to stdout.put rather than multiple
invocations.
The final improvement you can make is to note that most of the time you invoke stdout.put,
all you're doing is printing a single string (at least, once you follow the suggestions above).
That means you can skip the use of the stdout.put macro entirely and just call the stdout.puts
function (which stdout.put winds up calling for you). This means that HLA only has to process
a single statement rather than 400-500 statements to compile this single statement.
So if you go in and modify the stdout.put statements as I've just described, I think you'll find
that compilation times drop down to the sub-20 second range, or so (depends on how many other
macros you're processing).
Cheers,
Randy Hyde