Hi Randy,

Welcome to the board. When I saw your name in the newest member notification I had a feeling that there would be an HLA forum soon. I have to admit that I have never used HLA but I just downloaded your package to take a look and could see alot of places where it would be useful. There are times when MASM can get a bit bogged down with complexity (I.E. string manipulation) that HLA appears to handle well. So, after all that here's my question...

Is there an IDE that you know of for HLA in the style of KetilO's RadASM package ?

Donkey
Posted on 2003-01-13 09:09:17 by donkey
To me, an IDE means an environment that supports
editing, compiling/assembling, and *debugging* all in the same
environment. Alas, there is no debugger that supports HLA v1.x (AFAIK).
This is mainly due to the way HLA compiles its code (generating assembly
output rather than object code, with embedded symbolic information).
As such, I am personally of the opinion that a true IDE is going to have to
wait for HLA v2.0 (when HLA will generate object code directly).

In the meantime, if you just want to edit/compile/run from the same environment,
there are several editors on the market (both commercial and freeware) that let
you set them up to do exactly this. I personally use Codewright, which is an
excellent system; I know dozens of people who use UltraEdit-32 as well.
And every time I post a response to this question, there are usually a few
more replies of the form "I've got it working with such-and-such editor" as well
(maybe we'll see some of those messages here, who knows?).

In the original HLA documentation I'd once written an HLA "road map" describing
what HLA v2.0, HLA v3.0, etc. was going to do. Way back in 1997 when I was
first planning how all this was going to work, I'd decided that object code generation
would come with HLA v2.0 and a full IDE would come out with HLA v3.0.
Since then, a couple of things have gotten in the way of HLA's progress.
First of all, the HLA language today (v1.42 is in progress) is *far* larger than
I expected it to become (e.g., a Linux version wasn't in the plan until well after
v2.0). Also, I've been abducted by a publisher to get "The Art of Assembly Language
Programming" in publishable form plus contracts for a couple of other books,
all of which are getting in the way of getting real work done.
Even HLA v1.x is getting in the way of getting v2.0 done! I swore HLA v1.40 would
contain the last major changes, but I'm bowing to pressure from a couple of different
sources to get a FASM code generator for HLA available. Maybe once that is complete
I can get back to work on HLA v2.0 (of course, there are those two or three other
book projects I've contracted for that are still in the way).

To make a long story short, I've given up on the original road map.
*IF* I can get HLA v2.0 done before I die, then the likelihood of a decent IDE
for HLA becomes a real possibility :-) Until then, I've learned better than to make
promises :-(
Randy Hyde
Posted on 2003-01-13 21:03:14 by rhyde
AoA in published form? 16 or 32? Either way, sounds like a book I'd buy.


Thanks,
Shawn Bullock,
_Shawn
Posted on 2003-01-13 22:52:50 by _Shawn
Definitely the 32-bit version.
There is no market for a DOS book these days :-)
Posted on 2003-01-14 21:42:45 by rhyde
I am so far not familiar with HLA but if it is a bridge between programming at the Basic level and asm then i tip my hat to you Randall Hyde.

I programmed in Basic and Qbasic for years.

Then i didn't even have a computer for some years. When i got on line and found Masm32 it was the best package but i was lost because the difference between something such as Qbasic and Masm32 is extreme.

I think if HLA is such a bridge between the two then well done.

Many new programmers won't have to go through the headache that i did.

:alright:

And i'm gonna check out HLA too.
Posted on 2003-01-14 22:20:12 by IwasTitan

I am so far not familiar with HLA but if it is a bridge between programming at the Basic level and asm then i tip my hat to you Randall Hyde.

I programmed in Basic and Qbasic for years.

...
I think if HLA is such a bridge between the two then well done.



Well, the main influences where Pascal and C, but of course
most modern imperative languages are so similar to one another
that just about anyone who takes a look at HLA will recognize something.

Although it is perfectly possible to use HLA as a "medium-level language"
that sits somewhere between "pure" assembly and C, the intent of
the HLL-like statements (such as IF, WHILE, FOR, etc.) was really to
provide a crutch for HLL programmers so they could begin writing assembly
code as rapidly as possible before mastering enough of the instruction set
to do all the things they're able to do in a HLL. Although many programmers
(myself included) often use HLA as though it were some sort of high level
language, that's really not the intent. So keep this in mind if you decide to
learn assembly using HLA -- the high level control structures are a means
to an end, not an end in and of themselves. Be sure you fully learn the
"low-level programming paradigm" for it you do not, then you cannot
really call yourself an assembly language programmer.

A side note: HLA often gets unfairly critisized for being some sort of
"high level language", not a "real" assembler. The truth is, however,
that HLA doesn't really provide much in the way of control structures
that you won't find in MASM or TASM. So I find such comments
ill-informed, to say the least. There is very little you can do with MASM
that cannot also be done with HLA (e.g., writing 16-bit code for DOS is a good
example of something you cannot do in HLA that can be done with MASM).
So don't let anyone try and convince you that HLA isn't a "real" assembler.
Randy Hyde
Posted on 2003-01-14 22:50:31 by rhyde
The impression I received from reading AoA/HLA related PDFs is that HLA is more of a teaching tool than anything else, gapping the bridge between human readable code and machine code and easing the student in until they are comfortable with assembly more native to the term.
Posted on 2003-01-16 09:05:26 by SpooK
OK..real NEWbie here, with a few questions..hopefully I have read enough that these questions will not backfire on me..LOL..

Firstly I would like to thank all the wonderfull code warriors for your ground work and helping to make .asm and .hla quite simple to understand through your guides and tutorials..

I have installed hla before and am now after a few months returning to it..my install of hla, went fine using the install.pdf..with one exception..I cannot seem to get ML.exe to link my .hla files..I seem to get the eroneous error of..


LINK : fatal error LNK1181: cannot open input file "kernel32.lib"
Error returned by link = 1181


I have tried everything I know but still cannot..any suggestions..I am using win2K and have reset my variable paths many times..they are correct but yet nothing..

_Shawn, is the hla installer still available..I hate to think I have a simple install problem, so I will try hla install over again using your hla installer..

Randyll, do you think reading both AoA and the hla version at the same time will assist in my learning of assembly..

Wizzard
Posted on 2003-01-16 16:19:12 by Wizzard
Wissard,

I haven't created an installer in a while. It's a real pain in the neck. Takes about 1 1/2 hours to get all the files in synch and make sure I have it correctly, all the Merge Modules and so on.

If anyone here has Wise For Windows Installer 3.52 I'm more than will to give the files over so someoneelse can make an installer. Until then, I'm pressed for time.

I have 2 more months to complete a real-time Reconcilation Engine on a 10 Terabyte cluster of databases with about 5,000 users simultaneous at any given time of the 8 hours work day, plus 3 considering time-zone differences. As you can imagine, real-time isn't so difficult when using Message Queues and so on, but it's the fact that I'm filtering through 10 Terabytes and it'll increase to 100 TB over the next 3 years.

In case you're wondering, I work for an Application Service Provider (one of the few successful ones) and so we're hosting the data of some of the largest corporations in the particular industry that we're serving. So the data needed compounds with each new client.

But... I suppose I'll get around to it when my crunch is over.


Thanks,
_Shawn
Posted on 2003-01-16 16:26:11 by _Shawn

I have installed hla before and am now after a few months returning to it..my install of hla, went fine using the install.pdf..with one exception..I cannot seem to get ML.exe to link my .hla files..I seem to get the eroneous error of..


LINK : fatal error LNK1181: cannot open input file "kernel32.lib"
Error returned by link = 1181


I have tried everything I know but still cannot..any suggestions..I am using win2K and have reset my variable paths many times..they are correct but yet nothing..
Assuming security permissions are not involved. Either the file does not exist, or the environment variable that LINK uses to find .lib files is set incorrectly. Inspecting VCVARS32.BAT (from VC) suggests that LINK uses the LIB environment variable.

I'm assuming you're not using Visual Studio. In Win2k, NT, and XP, permanent environment variables are part of Advanced System Properties. One way to get to these options is Control Panel -> System -> Advanced. There should be a button for Environment Variables there. Application-specific environment variables normally go in the User section. You can put your LIB=xxx there.

It may also be possible that Win2k and XP can get environment variables from the AUTOEXEC.BAT file. (backward compatibility with 9x).

If it still doesn't work, make sure you have the 32-bit (Incremental) linker rather than the 16-bit (Segmented) linker. They are both named LINK.EXE.
Posted on 2003-01-16 21:03:09 by tenkey
just to update all who may have yhis problem in the future..

I cleaned the install drive..and loaded masm32 and hla..following all install instructions I could still not get through my LINK ERROR..so I tried the new version of LINK.exe and needed to add these dll's to the root hla file for it to work properly..

msvcr70.dll
mspdp70ll
mspdp50.dll

I have a few development enviormenrs running so I will not rule out foul play froma any of the other assemblers and such..thanks for your help and comments..

Wizzard
Posted on 2003-01-17 22:12:57 by Wizzard

The impression I received from reading AoA/HLA related PDFs is that HLA is more of a teaching tool than anything else, gapping the bridge between human readable code and machine code and easing the student in until they are comfortable with assembly more native to the term.


But what prevents the serious use of HLA once assembly is mastered?
This is a common misconception, that somehow HLA has all these "baby"
features to get assembly language programmers up to speed and then
they have to go somewhere else to do "real" assembly.

In actuality, HLA is *far* more powerful than most other x86 assemblers
when viewed as a production-use tool. Throw away the high level
control statements and you've still got an extremely powerful assembler
that outshines other products. About the only thing that HLA does not
do that an assembler like MASM will do is 16-bit coding (I elected not
to support the 16-bit addressing modes and segmentation because I
intended HLA to be used specifically under modern, 32-bit operating
systems). Even on the few instructions that HLA does not support
(e.g., it doesn't current support any of the AMD-specific instructions, simply
because I don't have an AMD system to test it on), you can use
HLA's #ASM..#ENDASM directives to inject "in-line assembly" directly into
the source code that HLA produces.

Beyond that, the "high-level" features that HLA supports are either
based on stuff that appears in assemblers like MASM (e.g., the use of
procedure directives, automatic parameter passing ,
automatic code generation for constructing activation records ,
records/structures and unions , classes , etc.).
HLA certainly introduces a few new things you don't find in traditional
assemblers (like iterators and thunks plus a phenomenal compile-time
language), but such features are hardly for newcomers to assembly language.

One thing that does confuse people who casually glance at HLA source code
is the presence of statements like the following:\

stdout.put( "Hello World, i=", i, " j=", j, nl );

However, this is not a "statement" in the HLA language. Rather, it is
simply a macro provided in the HLA Standard Library that expands to
some calls to various routines in the HLA Standard Library.
Some critics claim that such statements "prove" that HLA is not real assembly.
This is hogwash. I've written several similar macros for MASM (check
out the "UCR Standard Library for 80x86 Assembly Language Programmers v2.0"
on Webster at http://webster.cs.ucr.edu). Granted, HLA's macro facilities
are quite a bit more powerful than MASM's (indeed, that's why I wrote HLA
in the first place, MASM's macro facilities were just a bit too weak to do what
I wanted to do with the UCR Stdlib v2.0), but this makes the product *more*
suitable for advanced programmers, not less.

Almost everything else in the language is pure syntax intended to make
HLA easier to learn and use than other assemblers, but such features
hardly make the assembler less suitable for advanced programmers.

Having made the statement above, I would comment that in one sense,
HLA is *inappropriate* for advanced assembly programmers. Because
advanced assembly programmers already know an assembly language
and have some strong expectations about what an assembler should
look like. Regardless of the features HLA supports, the fact that its
syntax is radically different than a traditional assembler is going to
create problems for them (witness your post). However, someone
who learns assembly language with HLA and rises to the level of an
advanced programmer would complain bitterly about the lack of power
found in other assemblers. There have been several comments about
HLA made to the effect that "It may be great to learn with, but they're
going to have to learn a 'real' assembler anyway..." (as your post tends
to suggest). The truth is, there are few reasons why anyone would
ever have to shift from HLA to some other assembler once they master
HLA. At one time, a very strong argument could have been made that
"They'll have to learn MASM (or TASM) anyway, since that's what all
the code in the world has been written in." A couple of years ago,
that statement was true; today, MASM and TASM are in decline and
the crowds that would have gone with one of those two assemblers in
the past are spreading themselves out across several assemblers
(FASM, NASM, Gas, HLA, etc.). So the same problem exists *no matter
which assembler you start with*. This is a real problem; and one I
intend to address sometime later this year by writing a "universal
guide to assembly language" that provides a parallel reference guide
to several of the more popular assemblers out there ("This is how you
do it in MASM, this is how you do it in NASM, this is how you do it in
HLA, etc...").

Randy Hyde
P.S., Of course, if you feel that HLA has some real limitations, feel free
to post the specific issues you have and I'll be happy to discuss them
with you. In general, though, I usually lump nebulous posts like this
one into the category of "this doesn't look like what I'm used to and
I don't want to spend a lot of time learning this, so I'm not interested."
Posted on 2003-01-19 16:29:12 by rhyde

OK..real NEWbie here, with a few questions..hopefully I have read enough that these questions will not backfire on me..LOL..

Firstly I would like to thank all the wonderfull code warriors for your ground work and helping to make .asm and .hla quite simple to understand through your guides and tutorials..

I have installed hla before and am now after a few months returning to it..my install of hla, went fine using the install.pdf..with one exception..I cannot seem to get ML.exe to link my .hla files..I seem to get the eroneous error of..


LINK : fatal error LNK1181: cannot open input file "kernel32.lib"
Error returned by link = 1181


I have tried everything I know but still cannot..any suggestions..I am using win2K and have reset my variable paths many times..they are correct but yet nothing..

_Shawn, is the hla installer still available..I hate to think I have a simple install problem, so I will try hla install over again using your hla installer..

Randyll, do you think reading both AoA and the hla version at the same time will assist in my learning of assembly..

Wizzard


If the assembler is complaining about not finding kernel32.lib, then the
problem is either:

1) kernel32.lib isn't on your system, or
2) the environment variable "lib=...." doesn't contain the path where
this library module can be found. Note that, unlike the HLALIB environment
variable, "lib=" must contain the path to the directory where kernel32.lib
(and gdi32.lib and user32.lib) can be found, not the actual pathname of the
file. E.g., if you've put kernel32.lib, gdi32.lib, and user32.lib in the c:\hla\hlalib
directory, you'd set the LIB environment variable up as follows:

lib=c:\hla\hlalib; <<other paths for other compilers>>

The HLALIB environment variable would be set up as follows:

HLALIB=c:\hla\hlalib\hlalib.lib


Shawn -- I'm currently working on HLA v1.42 (main new feature, hopefully,
will be FASM code generation) to put on the CD for the published version
of The Art of Assembly... We should probably get together and do an
installer for that one.


As to the question about AoA and HLA, I presume you're talking about
reading both the 16-bit and 32-bit versions of Art of Assembly at the
same time. Frankly, the 32-bit edition contains everything found in the
16-bit edition except the 16-bit specific stuff, the DOS specific stuff,
the MASM-specific stuff, and the UCR Stdlib specific stuff. I strongly
discourage people from learning DOS & 16-bit coding at this point.
Unless you *really* need to write DOS code, there is no need to
waste the time and effort (and deal with the confusion) of 16-bit
assembly coding on the x86. Some people *do* need a DOS/assembly
reference, which is why I've left the 16-bit edition on line. But by and
large, the vast majority of people learning assembly at this point should
learn it for Windows or Linux. If you do need to learn 16-bit coding for
some reason, I'd suggest learning the 32-bit stuff first, then go back
and read the 16-bit stuff, as necessary, to fill in the details.
Randy Hyde
Posted on 2003-01-19 16:39:41 by rhyde
I am currently working on collecting some tools together
to create a "pseudo-IDE" for HLA. For example, I've written
some batch files to allow an HLA programmer to use
Hutch's QuickEdit program with HLA (much the same way
that it works with MASM). I'll also do some CodeWright and
UltraEdit32 work to allow the use of these editors as a
mini-IDE. If anyone out there has got a favorite little
*free* editor that supports setting up a mini-IDE, let me
know; as I get time I may try to provide the interface for it.

I'm also working on a *totally free* version of HLA (e.g.,
eliminating the reliance on Microsoft's MASM/LINK under
Windows). I'm in the middle of a FASM port (still a few
problems to resolve, but that's coming along nicely).
The big issue is a free linker. The only "somewhat free"
linker I've found for PE/COFF output is ALINK. ALINK
has a couple of problems - first, although you can download
a free copy, the license is too restrictive (it doesn't allow
distribution with commercial packages, which blows it for
me; even though HLA is not commercial, it is public domain
and *could* be distributed with a commercial package; I
don't wan't to include anything with HLA that prevents this).
The second problem with ALINK is that it failed to link the
simple "Hello World" console application. The license
expressedly forbids distributing modified copies (i.e., I could
probably fix the bug myself, but...) So I guess the next step
after getting the FASM port of HLA working is to write a public
domain linker.

I'm also looking at using OllyDbg as a debugging tool for
HLA programs. I've made an initial contact with Oleh Yuschuk
concerning a slight modification to OllyDbg's disassembler to
output HLA's "src,dest" syntax. Individuals with an interest
in seeing an HLA version might visit http://home.t-online.de/home/Ollydbg/
and check it out. (It wouldn't hurt to mention your desire for such
a version, though Oleh seems very receptive at this point.)

I'll Keep You Posted as Developments Occur,
Randy Hyde
Posted on 2003-01-25 11:58:51 by rhyde
TheFreeCountry website used to have a number of freeware linkers on it's assembly page, but the site was closed down this week.

Have you tried GoLink? http://www.jorgon.freeserve.co.uk/ (I'm new to all this and Golink may be Goasm specific.)

Looking forward to reading a hardcopy of the revised AoA.

I use the freeware Source Edit as my IDE and would be willing to assist you in creating a config file for it (though it would be a simple matter). http://www.sourceedit.com

Thank you for AoA ... I have it on my Palm. :alright:
Posted on 2003-01-25 13:58:30 by Masmer

TheFreeCountry website used to have a number of freeware linkers on it's assembly page, but the site was closed down this week.

Have you tried GoLink? http://www.jorgon.freeserve.co.uk/ (I'm new to all this and Golink may be Goasm specific.)



Yeah, I got to TheFreeCountry right after they shut down.
Talk about bad timing. Seaches via altavista turned up ALINK,
but I didn't follow through to the point I found any others.

GoLink looks interesting, except it's author has an aversion to
LIB files for some reason. He brags about how this is such a great feature,
being able to link in DLLs directly (e.g., kernel32.dll). That's fine for
the Win32 API, but if you've got your own library routines (e.g., the
HLA Standard Library) that you statically link, LIB files are the right
way to go.

In never ceases to amaze me how many assembler authors out there
fail to see the utility of linkable libraries. It's not like this is a new
invention; nor is it like any of them have come up with a better
solution. Oh well...
Randy Hyde
Posted on 2003-01-26 00:44:32 by rhyde
ask him. He visits the board.
Posted on 2003-01-26 07:14:33 by Hiroshimator
I have everything downloaded and burned onto a CDR from the Free Country's C/C++ and assembly pages. If you want, I can look for the linkers and see how good they are or upload them somewhere. From what I can remember, most of them were 16-bit only.
Posted on 2003-01-26 08:54:28 by Masmer

I am currently working on collecting some tools together
to create a "pseudo-IDE" for HLA. For example, I've written
some batch files to allow an HLA programmer to use
Hutch's QuickEdit program with HLA (much the same way
that it works with MASM). I'll also do some CodeWright and
UltraEdit32 work to allow the use of these editors as a
mini-IDE. If anyone out there has got a favorite little
*free* editor that supports setting up a mini-IDE, let me
know; as I get time I may try to provide the interface for it.

It's pretty amazing how things turn out sometimes :) I found and downloaded HLA just a few days ago and now Masmer recommends my editor Source Edit to be used as a "mini-IDE" with it. Thanks to my webstats (that tracks referrals) I now found this forum as well...

I'm currently working on creating a syntax highlighter for HLA to be used with Source Edit, adding the compiler using the Tools Configuration should be pretty straight forward.

While I'm in here I just might as well come with a request as well ;)
What I lack in HLA is a compiler option to specify the output directory, currently hla.exe outputs all the *.link, *.obj, *.inc, *.asm, and *.exe files to the current directory but I would prefer to not mix the source file with all these files but rather have them in a subfolder. I tried to use the -e option but that failed with the *.obj file which stopped the compiling process.

Best regards,
Posted on 2003-01-26 10:53:10 by Joacim Andersson


It's pretty amazing how things turn out sometimes :) I found and downloaded HLA just a few days ago and now Masmer recommends my editor Source Edit to be used as a "mini-IDE" with it. Thanks to my webstats (that tracks referrals) I now found this forum as well...

I'm currently working on creating a syntax highlighter for HLA to be used with Source Edit, adding the compiler using the Tools Configuration should be pretty straight forward.

While I'm in here I just might as well come with a request as well ;)
What I lack in HLA is a compiler option to specify the output directory, currently hla.exe outputs all the *.link, *.obj, *.inc, *.asm, and *.exe files to the current directory but I would prefer to not mix the source file with all these files but rather have them in a subfolder. I tried to use the -e option but that failed with the *.obj file which stopped the compiling process.

Best regards,


This is actually one of those things I should have fixed a year ago.
It's been a tremendous problem, but I keep forgetting to deal with it.
I'll put this on my list for v1.44 (v1.43 is the FASM output option and that's
a tremendous change as it is).
Randy Hyde
Posted on 2003-01-26 16:01:13 by rhyde