HLA suggestions

From: T.M. Sommers (tms2_at_mail.ptd.net)
Date: 10/29/03 

Date: Wed, 29 Oct 2003 03:46:51 GMT

I have a couple of suggestions about the directory structure of the
HLA source, plus a couple of questions.

1) Currently, to build HLA from scratch, one needs to get the compiler
source, the library source, and a binary distribution (for the library
include files). Each of these distributions puts its files in a
different place. It would make building from scratch easier if:

*) The library include files were included with the library source.
*) The library source (including the include files) and the compiler
source were both put in subdirectories of a common directory, such as:

hla
    hlasrc
    hlalibsrc
       include

*) An additional advantage of this setup (or something like it) would
be that the entire project could be built from a single makefile in
the top directory.

2) Porting the compiler seems to be fairly quick and easy, but the
compiler cannot build executables without the HLA library also being
ported, because it automatically puts some code in every program that
uses the library. And that means, among other things, that the
compiler cannot really be tested until the library is ported. How
about either:

*) Putting the library code used by the automatically-inserted code
into a separate library. Being much smaller, this library should be
easier, or at least quicker, to port, so that one could have a working
compiler while working on the rest of the library.

Or,

*) Adding a flag to HLA to omit the automatically-inserted code.

I prefer the second alternative, as it should be simpler, and as it
might be useful in other situations than porting. The first
alternative really only benefits porters, I think.

3) Now the questions: What do you think of having HLA add debugging
information? I'm not sure how hard that would be, espcially for
Windows, but it would have obvious advantages.

Also, I was thinking it might be useful to have an HLA analog to
mkdep, to create dependencies for use in makefiles. Adding an option
to the compiler, similar to cc -M, would be one way to do this. What
do you think? It should also be possible to do with an entirely
separate program, and that might actually be easier.

Relevant Pages

  • Re: HLA
    ... inline assembler for that compiler. ... different beast from a standalone assembler and IMHO, HLA is most ... It could be added to almost any C compiler without problems... ... then you're no longer programming in the standard form of the ...
    (alt.lang.asm)
  • Re: HLA suggestions
    ... >>HLA source, ... >>1) Currently, to build HLA from scratch, one needs to get the compiler ... > For symbolic information, you can do this under Windows ...
    (alt.lang.asm)
  • Re: Review of Art of Assembly Language
    ... PE files;) built into the IDE thingy and maybe it's not a HLA problem ... Borland's "freebie compiler" offer and could try it with that if it ... but it's all playing around with command lines and tools and makefiles ... thing certainly is worth paying for...but, also, sometimes, it's just ...
    (alt.lang.asm)
  • Re: HLA v2.x and / or LASM suggestion: Win32 Resources
    ... > With Microsoft's RC compiler, I've just noticed that it's less capable ... > binary resource converted into readable, ... selecting the particular assembler syntax you want to output for. ... > are using that RC compiler via HLA or whatever;)... ...
    (alt.lang.asm)
  • Re: Wiki, some vicious editing
    ... every reference to "compiler" there, too; given that HLA works the same ... How can you compare HLA with GCC ?? ...
    (alt.lang.asm)