Some Comments about HLA v2.0 Syntax

[Randall Hyde]

As work progresses on HLA v2.0, there are a couple of things that I'm going to change based on my experiences with HLA v1.x.  As much as possible, I'm trying to preserve the syntax of the language, but there have been some parts of the language design that I'm unhappy with and, therefore, I'm going to change in HLA v2.0.

One syntactical item that has always bugged me is that there is no differentiation between (constant) array indexes and memory indexes, despite the fact that these are semantically different items. Consider the following:

type
  array :dword[8];
const
  a:array := [0,1,2,3,4,5,6,7];
static
  b:array := [8,9,10,11,12,13,14,15];
     .
     .
     .
// Access an element of the "a" constant array:

    mov( a[4], eax ); // Loads the constant four into eax

// Access an element of the 'b' memory array

   mov( b[4], eax );  // Loads the value nine into eax from memory location b+4

Though they are syntactically identical, these two "array" references have completely different meanings. The programmer probably intended the following for the second (memory) array access:

   mov( b[4*4], eax );  // Loads the value 12 into eax from location b+16.

Remember, indexes on memory objects are *byte* indexes, not element indexes. For constant arrays, however, the indexes are actual element indexes. This inconsistency has always been an annoyance to me.

This will change in HLA v2.0.

I'm going to use parenthesis to denote array indexes and square brackets to denote memory references. In HLA v2.0, the correct way to do the above would be:

// Access an element of the "a" constant array:

    mov( a(4), eax ); // Loads the constant four into eax

// Access an element of the 'b' memory array

   mov( b[4*4], eax );  // Loads the value 12 into eax from memory location b+4

Note that you still have to explicitly multiple a memory index by the size of the operand, but the syntax doesn't suggest that both operations are identical.

This particular change will have some far-ranging impacts on existing HLA (v1.x) source code. Array declarations (which will also use parenthesis) appear throughout many existing HLA applications. To prevent chaos occuring when HLA v2.0 first appears (because it won't compile very many HLA v1.x programs), I'm going to phase in this new syntactical feature in three steps:

1. Initially, HLA v2.0 will allow the use of "(" and ")" as well as "[" and "]" for array indexes and declarations. This should allow the compilation of most HLA v1.x code (at least, on the basis of this change alone).

2. At some point in the future, HLA v2.x (x>0, x<y), I will begin printing a warning message if source code continues to use the "[" and "]" for array declarations and indexes. The program will still compile and run, but you'll get annoying warnings during assembly (which should be a clue to clean up your source files).

3. At some later point in the future, HLA v2.y (y>x), I will eliminate the use of "[" and "]" in array declarations and as the array index operator.  HLA v2.y will report a syntax error if it encounters these symbols.

With HLA v1.74 (and earlier), there is nothing you can do today to prepare for this. HLA v1.x only accepts the "[" and "]" symbols for array declarations and indexes. In theory, I could inject the optional syntax into HLA v1.x so people could start preparing for this change today, but I don't really think this is that important to do just yet.

In any case, this is just a "heads-up" notice to let people know what is about to happen.
Cheers,
Randy Hyde

[Sevag.K]

// Access an element of the "a" constant array:

    mov( a(4), eax ); // Loads the constant four into eax

// Access an element of the 'b' memory array

   mov( b[4*4], eax );  // Loads the value 12 into eax from memory location b+4

How about keeping the memory syntax and applying that for constants as well?

  mov( a[4*4], eax);  // load dword constant at &a+12 bytes into eax

I don't think I've made use of array constants yet and I wasn't even aware of that
inconsistency in syntax.



A side note, since we are on the subject of syntax.
I know a macro can be used for this, but it would be nice to have
it built-in:

mov ( "blah", eax );  // compiler converts 'blah' to a dword constant

[Randall Hyde]

How about keeping the memory syntax and applying that for constants as well?

Not possible.
Internally, HLA does not store constants in simple memory locations as they would be in a run-time assembly application. Because the compile-time language uses dynamic typing, indexing into a constant array changes during program compilation.

I feel for you, this would be the best "assembly" way to do it. Alas, the compile-time language and the run-time language are radically different and in this area they cannot be reconciled.

I don't think I've made use of array constants yet and I wasn't even aware of that
inconsistency in syntax.

Yes, array constants aren't used that often except in advanced assembly programs. They are invaluable for creating HL-like constructs (e.g., the "switch" macro in the HLA standard library), but they don't find a whole lot of use in typical assembly apps.  Record constants even less so.  Nevertheless, they are *incredibly* useful on occasion and their presence is one of the things that differentiates HLA from other assemblers (including powerful ones like MASM and TASM).

A side note, since we are on the subject of syntax.
I know a macro can be used for this, but it would be nice to have
it built-in:

mov ( "blah", eax );  // compiler converts 'blah' to a dword constant

Yeah, I've thought about this now and then.  It's a question of balancing convenience with the type checking that HLA does.  I'm thinking, perhaps, about using syntax like this:

mov( #"blah", eax );

This is 'somewhat' consistent with the use of '#' to prefix character constant codes.
Cheers,
Randy Hyde

[Sevag.K]

How about keeping the memory syntax and applying that for constants as well?

Not possible.
Internally, HLA does not store constants in simple memory locations as they would be in a run-time assembly application. Because the compile-time language uses dynamic typing, indexing into a constant array changes during program compilation.

I feel for you, this would be the best "assembly" way to do it. Alas, the compile-time language and the run-time language are radically different and in this area they cannot be reconciled.

I see your point.  I'm sure you already noticed that, using array(n) syntax looks too much like a macro/function call.
But I guess you are limited on grammar here.  The only other feasible option would be curlies {} but that would begin to look alien.

Yes, array constants aren't used that often except in advanced assembly programs. They are invaluable for creating HL-like constructs (e.g., the "switch" macro in the HLA standard library), but they don't find a whole lot of use in typical assembly apps.  Record constants even less so.  Nevertheless, they are *incredibly* useful on occasion and their presence is one of the things that differentiates HLA from other assemblers (including powerful ones like MASM and TASM).

I can think of some macros where I might be able to use them, but not in the forseable future.  This implementation won't break much of my code so I'm not too worried (it'll probably be a consideration where I use the switch/case macros).  It does mean more work for you though as it would mean more work to make the library code 2.0-ready.

Even though I used to be a low-level advocate, I've recently migrated over to more of the 'HL' of HLA as it makes the code easier to read and maintain (as well as faster to write).  After over a year of HLA, last week was the first time I used the switch/case macro and I must say, I'm happy with the results.  Much faster than coding the tables by hand and easier to add more elements.  I'll be using it more often methinks.

Yeah, I've thought about this now and then.  It's a question of balancing convenience with the type checking that HLA does.  I'm thinking, perhaps, about using syntax like this:

mov( #"blah", eax );

This is 'somewhat' consistent with the use of '#' to prefix character constant codes.
Cheers,
Randy Hyde

The '#' works for me.  Much better than

mov ( convToConst("halb"), eax );

[tommy]

What about using single-quotes for dwords and double-quotes for strings?

[Randall Hyde]

What about using single-quotes for dwords and double-quotes for strings?

Apostrophies are used for character constants, versus quotes for strings already.
The only problem with allowing more characters inside the quotes is that I can't do the type checking HLA does so well if you do this kind of stuff.

As for other syntax, I *could* have used the grave accent (back quote), but I'm thinking of using that for a different purpose in HLA v2.0.
Cheers,
Randy Hyde