After testing and losing time with nearly all languages in the Pascal family (Delphi, OBERON, Eiffel and many others), i finally consider HLA as my programming language.
The extensive docs and tutorials are impressive.

I plan to use HLA as a replacement for OBERON.
My top criteria when evaluating a language are:
1. readibility
2. control
3. support

HLLs such as OBERON usually give more readibility and more support.
But HLA gives much more control.
Lack of control is a plague when you know how to do advanced control but are stopped because the compiler enforces type safety, garbage collection, dynamic loading, execution environment and other services.

I have read most of the docs, no other language is as well documented as HLA. The HLA documentation is the only one that also covers the CPU and the OS environments, both are usually considered as off-topic. The educationnal effort is remarkable and really facilitates the transition.

Here are my first impressions, or at least the ones that i can formulate in an articulated manner:

Fasm

If hlatemp is used then Fasm fails with "error: file not found".
So i have switched back to ML.EXE


Memory functions

* is malloc-ed memory 0-ed or not (seems it is not)?
* so is there a stdlib function to fill memory?
* does malloc-ed mem-blocks have to be freed before program termination?
* is there a stdlib function to copy (possibly overlapping) memory?


Type coercion

With a "::" type coercion operator i could write:

if( ::node.Prev <> NULL ) then
add( 2, ::dword);
else
push (1::dword); // simulates pushd(1)
endif;

instead of:

if( (type node ).Prev <> NULL ) then
add( 2, (type dword ));
else
push( dword(1) ); // simulates pushd(1)
endif;

which is more cumbersome (more parenthesis) and less consistent (constant coercion and memory coercion should be the same) in my opinion.


Classes and methods

I plan to use classes extensively so i need good support.
Basically what i need is an option so that "this" is preserved, ESI could be saved in stack frame at entrance, and then restored after any CALL. I know it seems like another code overhead but actually it's "this" registeration, so it's real speed improvement when "this" is accessed many times.


Iterators

It's the best thing since sliced bread, HLA is really high level.


Regards,

Damien
http://perso.wanadoo.fr/alphablock/
http://membres.lycos.fr/brickcaster/
Posted on 2003-10-18 16:24:22 by SpiceGuid
Originally posted by SpiceGuid
After testing and losing time with nearly all languages in the Pascal family (Delphi, OBERON, Eiffel and many others), i finally consider HLA as my programming language.
The extensive docs and tutorials are impressive.

Thank you. Welcome aboard.


Here are my first impressions, or at least the ones that i can formulate in an articulated manner:

Fasm

If hlatemp is used then Fasm fails with "error: file not found".
So i have switched back to ML.EXE

I will look into this someday. FASM support has been weak recently (because
of many other recent changes in HLA), but I am interested in a totally free version
of HLA (and this requires something like FASM).



Memory functions

* is malloc-ed memory 0-ed or not (seems it is not)?


You cannot assume this to be the case, in general.
Under Windows, I call Win32 API functions, so whatever they do...
Under Linux, I allocate the memory myself and I do not zero it out (why waste
the time doing this if most of the time it doesn't matter?).


* so is there a stdlib function to fill memory?


No. But you can use the STOSD instruction to do this just as easily.


* does malloc-ed mem-blocks have to be freed before program termination?


No. The OS reclaims the storage (at least, in all current implementations
of the HLA Standard Library).



* is there a stdlib function to copy (possibly overlapping) memory?


MOVSB/W/D does this job, depending on how you've set the direction
flag. The HLA StdLib doesn't provide the equivalent of "bcopy", but that's
a trivial function to write using the MOVSB instruction.



Type coercion

With a "::" type coercion operator i could write:

if( ::node.Prev <> NULL ) then
add( 2, ::dword);
else
push (1::dword); // simulates pushd(1)
endif;

instead of:

if( (type node ).Prev <> NULL ) then
add( 2, (type dword ));
else
push( dword(1) ); // simulates pushd(1)
endif;

which is more cumbersome (more parenthesis) and less consistent (constant coercion and memory coercion should be the same) in my opinion.


Constant coercion and memory coercion should be the same, but I ran into problems with HLA's LALR grammar when attempting to do that. Your idea is interesting (though "::" is already used as scope operator in HLA). Definitely trying to make the two forms consistent is a goal in HLA v2.0.



Classes and methods

I plan to use classes extensively so i need good support.
Basically what i need is an option so that "this" is preserved, ESI could be saved in stack frame at entrance, and then restored after any CALL. I know it seems like another code overhead but actually it's "this" registeration, so it's real speed improvement when "this" is accessed many times.


You should be able to do this with a little work using HLA macros.
I'd have to think through the details, but I don't think it would be that much work.

What I really want to do in HLA v2.0 is to let the programmer decide which registers to use for THIS
and the VMT pointer. It's too much of a mess to fix in HLA v1.x (tried, didn't work out), but this is
a goal for HLA v2.0.


Iterators

It's the best thing since sliced bread, HLA is really high level.


I think iterators are pretty cool too :-)
Cheers,
Randy Hyde
Posted on 2003-10-19 15:01:26 by rhyde
Thanks for the infos and support.

- Damien
Posted on 2003-10-20 16:07:45 by SpiceGuid

Type coercion

With a "::" type coercion operator i could write:

if( ::node.Prev <> NULL ) then
add( 2, ::dword);
else
push (1::dword); // simulates pushd(1)
endif;

instead of:

if( (type node ).Prev <> NULL ) then
add( 2, (type dword ));
else
push( dword(1) ); // simulates pushd(1)
endif;

which is more cumbersome (more parenthesis) and less consistent (constant coercion and memory coercion should be the same) in my opinion.




Well, I'm not able to help you with the "less cumbersome" issue yet, but the inconsistency of type coercion for constants and memory locations has been bugging me for some time and your post finally motivated me to do something about this. As of HLA v1.59 (when it appears), you will be able to use the same syntax for constant and memory type coercion, i.e.,

(type <typename> <memory or const>)

e.g.,

However, you still can't get away with "push( (type dword 1));", nor can you
do something like "mov( (type dword 1), );" because you must specify
the memory size, not the constant's size (e.g., use pushd or use (type dword )).
pushd/pushw is necessary because "push( (type word 1) );" is still ambiguous
(it's perfectly reasonable to push a word constant, appropriately extended, as
a double word value; ditto for the mov instruction).

The main use for this common syntax is going to be in macros. This allows you
to do something like the following:

#macro xxx( yyy );

mov( (type byte yyy), al );

#endmacro

and not have the compiler choke because you fed it a constant rather than
a memory location.

As for the condensed syntax, well, I'll worry about a more consistent syntax
for HLA v2.0.
Cheers,
Randy Hyde
Posted on 2003-10-21 19:42:08 by rhyde