What's wrong with HLA?

[dogman]

I know Frank is a major proponent of HLA  Aside from the philosophical and personal style issues, is HLA deficient? Does it have any technical shortcomings?

I'm asking because I have another 750 pages of reading to go and I don't want to get to the end and have to groan Oh no Frank was right!

The first thing that jumps out at me is the price of that power comes with a runtime which is an inhibitor for a certain sector of projects. OTOH I really like the portability it affords and the mitigation of the wretched POSIX interface requirements on assembly programs in UNIX-land. Again, these are strictly technical issues I am concerned about.

Any input guys? Would appreciate your comments.

Joe

[Frank Kotler]

I am neither a proponent nor an opponent of HLA. It is what it is. It does not suit my personal taste. I see no reason why that should be a problem to you!

Best,
Frank

[dogman]

I posted this question here because I know you and Keith and Rob and Bryant (not to neglect anyone- hello!) use x86 assembler heavily and I value your knowledge and helpfulness in the past. Again my question is specifically: is HLA technically deficient in any way? Is there anything standard x86 assemblers can do that HLA can't? Will a person using HLA hit the wall and not be able to write code at some point that he could write in gas/nasm etc? Does HLA make it harder to do things than mainstream assemblers?

If it's truly a matter of taste then that is the answer I'm hoping for. If not, then I would appreciate knowing about any technical shortcomings you or anybody else is aware of before I go much further in the book.

Thanks,

Joe

[TmX]

I think there are some people that dislike HLA: "it's not a real assembler", "it's just a compiler in disguise", etc etc.
Personally, I like it because somehow it resembles Pascal.

OTOH, I'm not really sure how efficient/deficient HLA is.
Where is Randy, BTW? Hopefully he's still working on HLA.

[Frank Kotler]

Pascal, eh? Whatever floats your boat...

Randy (Hyde) has made a couple of posts recently to the HLA mailing list:
aoaprogramming@yahoogroups.com
Mostly, he seems to be busy with his "Plantation Productions" (light and sound for Christian Rock groups, etc.). Doesn't sound too "politically correct" to me, but that's what he calls himself. I don't know if he's still working for General Atomics. Those who dislike HLA are appalled to find that it's being used to write control-room code for a nuclear reactor! (GA's reactor is said to be "safe", in that it shuts down if it gets hot. It is a research reactor, not suitable for generating electricity.)

The reason people can claim it's "not a real assembler" is that it requires a "real assembler"  to produce a linkable object file (or did, until fairly recently). Nasm can be used for that "real assembler" in the Windows version of HLA, but not the Linux version (last I knew - I haven't really kept up with it). At one point, HLA would produce a linkable object for Linux (some code borrowed from Fasm), but it didn't work properly and was removed. It may do so for Windows. In HLA's favor, the output HLA emits to this "real assembler" is a list of "db"s unless you explicitly ask for "-source", so it's doing what you'd normally consider the "assembly" part of the process and depends on the "real assembler" only for the "output driver" part of the process.

It has been observed that HLA emits some "startup code". This is true by default, but if you tell HLA "unit mything" instead of "program mything", and "@nodisplay" and "@noframe", it can be convinced to emit just the code you wrote (pretty near, anyway). Randy has produced some documentation under "Writing Units" unless I'm mistaken...

In terms of actual "deficiencies", HLA won't produce 16-bit code, it won't produce 64-bit code, it won't produce flat binaries (although ld - and perhaps other linkers - would do this if you need it). Unless you need these things, it isn't much of a "deficiency".

I should note that Randy is a real nice guy! He has always taken time to help me if I've had any questions, no matter how much I disagree with him. The folks who question Randy's "motivations" for writing HLA are way off-base, IMHO!

By coincidence, both the HLA mailing list and news:comp.lang.asm.x86 are currently discussing sorting algorithms, if anyone's interested in that subject...

Best,
Frank

[dogman]

The reason people can claim it's "not a real assembler" is that it requires a "real assembler"  to produce a linkable object file (or did, until fairly recently).

AFAICT V1 was a cross-compiler and V2 is a compiler. I'm trying to use the right terms- it's not correct to call a translator that produces assembly output a compiler. A compiler produces object files directly (even if that's not the way 99% of *NIX compilers work- most use gas as a back end). HLA does produce native object files. It compiles. It assembles. It leaps tall buildings in a single bound  It's not exactly clear to most people what kind of animal it is but what it does is not new. Wirth did the same thing in the 1960s (PL/360) but I'm not sure he was the first to do it and there have been similar compiler/assemblers in use for many years. HLA is innovative, but it builds on basic, well-established ideas and ways of doing things that have been around for 50 years.

Nasm can be used for that "real assembler" in the Windows version of HLA, but not the Linux version (last I knew - I haven't really kept up with it). At one point, HLA would produce a linkable object for Linux (some code borrowed from Fasm), but it didn't work properly and was removed. It may do so for Windows. In HLA's favor, the output HLA emits to this "real assembler" is a list of "db"s unless you explicitly ask for "-source", so it's doing what you'd normally consider the "assembly" part of the process and depends on the "real assembler" only for the "output driver" part of the process.

Yes, this is weird. HLA does offer various format output for the backend. It produces native object files in Windows and Linux in V2. Like you said it also offers NASM format ouput (and more) but only for Windows? I don't understand why or why not... But looking at the various forms of output it can create is fascinating. The kitchen sink is jealous. I don't know why he went to all the trouble of doing that but he is nothing if not prolific.

Code: [Select]

hla@intelx86:~$ hla -?
Usage: hla options filename(s)

HLA (High Level Assembler - HLABE back end, LD linker)
Version 2.16 build 4409 (prototype)

Generic Options:
  -license  Display license information.
  -@        Do not generate linker response file.
  -@@       Force generation of a new linker response file.
  -dxx      Define VAL symbol xx to have type BOOLEAN and value TRUE.
  -dxx=str  Defile VAL symbol xx to have type STRING and value str.
  -sym      Dump symbol table after compile.
  -test     Send diagnostic info to stdout rather than stderr.
  -thread   Set @thread to true (for thread-safe code generation).
  -v        Verbose compile (also sends output to stdout).
  -?        Display this help message.

Language Control:

  -level=h  High-level assembly language.
  -level=m  Medium-level assembly language.
  -level=l  Low-level assembly language.
  -level=v  Machine-level assembly language (very low level).


Source Output Control and Compiler/Back-end output control:

  -source   Compile to source instructions (rather than hex opcodes).
  -s        Compile to .ASM files only.
  -c        Compile and assemble to object file only.

  -fasm     Use FASM as back-end assembler.
  -masm     Use MASM as back-end assembler.
  -gas      Use GAS (Linux/BSD syntax) as back-end assembler.
  -gasx     Use GAS (Mac OS X syntax) as back-end assembler.
  -nasm     Use NASM as back-end assembler.
  -tasm     Use TASM as back-end assembler.
  -hla      Emit Pseudo-HLA syntax
  -hlabe    Emit human-readable HLABE source code (implies -source).

Executable Output Control:

  -win32    Generate COFF file for Win32 OS.
  -linux    Generate ELF file for Linux OS.
  -freebsd  Generate ELF file for FreeBSD OS.
  -macos    Generate Mach-o file for Mac OSX.
Assembler and Linker Control:

  -axxxxx     Pass xxxxx as command line parameter to assembler.
  -lxxxxx     Pass xxxxx as command line parameter to linker.
  -e:name     Executable output filename (appends ".exe" under Windows).
  -x:name     Executable output filename (does not append ".exe").
  -b:name     Binary object file output filename.
  -main:xxxx  Use 'xxxx' as the name of the HLA main program.


Temporary file control and assembly control:

  -p:path   Use <path> as the working directory for temporary files.
            (overrides hlatmp environment variable.)

  -r:name   <name> is a text file containing cmd line options.

  -obj:path Use <path> as the directory to hold the object files.

  -inc:path Application-specific include path.

  -i:path   Include path (used to override HLAINC environment variable).

  -lib:path Library path (used to overide HLALIB environment variable).

HLA Environment Variables:


  hlaauxinc=<path>     Sets path to HLA app-specific include
                         subdirectory.

  hlaopt=<options>     Uses the specified command-line options
                         as default.

  hlaasmopt=<options>  Passes the specified command-line options
                         on to the underlying assembler.

  hlalinkopt=<options> Passes the specified command-line options
                         on to theunderlying linker.
hla@intelx86:~$


In terms of actual "deficiencies", HLA won't produce 16-bit code, it won't produce 64-bit code, it won't produce flat binaries (although ld - and perhaps other linkers - would do this if you need it). Unless you need these things, it isn't much of a "deficiency".

Dr. Hyde has real clear opinions on the stuff he works with. I guess that is important and good for a teacher. He's pragmatic. He has "gotten away" from DOS and real mode. He acknowledges the shortcomings of Intel in his books but as a practical matter that's what everybody is likely to have and use so that's what he targets. V3 of HLA will support 64 bit. It's in development. I have no idea how far along it is.

I should note that Randy is a real nice guy! He has always taken time to help me if I've had any questions, no matter how much I disagree with him. The folks who question Randy's "motivations" for writing HLA are way off-base, IMHO!

This bears repeating. I don't know him and have never corresponded with him. But when I read his books I see a focused, committed, extremely knowledgeable and very practical person who expresses himself effectively and well with boundless energy and enthusiasm. Those are all good qualities for somebody in software. Heck they're all good qualities in most situations. I could have used a few more teachers like him when I was in college.

Joe