started playing around with the HLA assembler tonight, and I must say I am mighty impressed, the code structure is very neat and the hla standard lib is amazing!! anyway, I am slowly grasping the extended syntax and am happily converting some of my masm programs to hla. However, I ran in to a little problem just now, basically I was wondering if there is a equivalent in hla to masm's ASSUME directive. the assume directive in masm basially allows you to set a register as a pointer to a predefined struct, so you can do

assume eax : ptr dummystruct
mov .dummyparameter, NULL

where dummyparameter is of course a structure field of dummystruct.

when looking through the (massive!!) HLAref the only thing I found was the pointer to base_type, which
is nice and all, but doesn't allow you to type a register, right? instead if I created a pointer to base type it
would be either stack based or placed in the data section.

type p_dummystruct: pointer to dummystruct

which I can then create in the static data seg as for example:
pDS: p_dummystruct;

and use in program:
mov(&of_a_dummystruct, pDS);
mov(1, pDS.dummyparameter);

assuming this works, is there any way I can temporarily cast a register as a pointer type?


I'm probably not making any sense here, too tired to think straight...

oh, and before I go to sleep, another thing. I was doing some winsock stuff, and since there wasn't any winsock hhf I threw together a ws2_32.hhf myself in a hurry, just the functions I needed. anyway all worked fine except for the 'socket' function which generated errors, seemingly colliding with the SOCKET type definition, so I had to rename the socket function to something like createsocket in order to get it to work, not a big hassle, but I was wondering if there was some way around this, since hla seems to regard SOCKET and socket as the same definition?

once more I must say from what I've seen hla is a masterpiece, the overhead generated isn't much from what I've seen studying the generated masm code and even that can be avoided if one wants to do it all by hand so to speak, also the hla standard lib seems just incredible, and I haven't even started glancing at the classes and objects yet, this will be a ride!

but first I must sleep....
Posted on 2003-05-23 18:31:00 by BinarySoup
Quick answer on the first question is:



mov(NULL, (type dummystruct [eax]).dummyparameter);


You can also look at Iczelion tutorials converted to HLA (tutorials #02 - 15 included in example folder of HLA package, tutorials # 16-32 are in this msgboard "Iczelion tutorials converted" thread)
Posted on 2003-05-24 11:23:13 by Green Joe
thanks!, the ability to type-cast registers on a instruction by instruction basis is great, hla really is a small dream come true! oh and great work on the iczelion tuts, I just checked them, great information there for masm32->hla. by the way, are there anywhere one can find hhf includes for other win32 libraries other than those included in the hla package? I have converted parts of ws2_32 myself for my own needs, but I was hoping there had been others converted?
Posted on 2003-05-24 13:47:40 by BinarySoup
The only hhf I aware of is share32.hhf.
I did it manually and included with Tutorial #23. While it wasn't much work with this hhf, becouse it is relatively small, it is not a good idea to make hhfs manually. Much better solution would be to write a tool that convert MASM incs to HLA hhfs. I believe it is not a great challenge to create such small command line utility.
Posted on 2003-05-24 14:24:49 by Green Joe
yeah you're right, shouldn't be impossible to write a program that creates a hhf based on the output of a dumpbin symbol table.
Posted on 2003-05-24 17:29:28 by BinarySoup
Tutorial #21 even explain how to do it... thru Pipe ... To redirect output from dumpbin to your program,
compute how many parameters each function excepts and write apropreate prototype to hhf file.

Converting structs is more difficult task.... at least it seems so.
Posted on 2003-05-24 17:50:03 by Green Joe

started playing around with the HLA assembler tonight, and I must say I am mighty impressed, the code structure is very neat and the hla standard lib is amazing!! anyway, I am slowly grasping the extended syntax and am happily converting some of my masm programs to hla. However, I ran in to a little problem just now, basically I was wondering if there is a equivalent in hla to masm's ASSUME directive. the assume directive in masm basially allows you to set a register as a pointer to a predefined struct, so you can do

assume eax : ptr dummystruct
mov .dummyparameter, NULL

where dummyparameter is of course a structure field of dummystruct.



In HLA, the way you would do this is via type coercion and TEXT constants,
e.g.,

const
eaxdp :text := "(type dummystruct )";
.
.
.
mov( NULL, eaxdp.dummyparameter ); // eaxdp expands to the string above...





when looking through the (massive!!) HLAref the only thing I found was the pointer to base_type, which
is nice and all, but doesn't allow you to type a register, right? instead if I created a pointer to base type it
would be either stack based or placed in the data section.

type p_dummystruct: pointer to dummystruct

which I can then create in the static data seg as for example:
pDS: p_dummystruct;

and use in program:
mov(&of_a_dummystruct, pDS);
mov(1, pDS.dummyparameter);

assuming this works, is there any way I can temporarily cast a register as a pointer type?



Yes, the type coercion operator: (type <typename> <objectToCast>)

Often, this involves quite a bit of extra typing, so if you do it often, using
the TEXT assignment becomes quite useful.



I'm probably not making any sense here, too tired to think straight...

oh, and before I go to sleep, another thing. I was doing some winsock stuff, and since there wasn't any winsock hhf I threw together a ws2_32.hhf myself in a hurry, just the functions I needed. anyway all worked fine except for the 'socket' function which generated errors, seemingly colliding with the SOCKET type definition, so I had to rename the socket function to something like createsocket in order to get it to work, not a big hassle, but I was wondering if there was some way around this, since hla seems to regard SOCKET and socket as the same definition?


Nope, no easy way around it. HLA uses a "case neutrality" convention
unlike C's (horrible) case sensitive convention. There are two solutions to this
problem -

1. put your definition in a (different) namespace (or put the original definition in a
namespace).

2. Use some sort of suffix or prefix character sequence to differentiate them.

For example, within the w.hhf header file I attempt to use a "_c" suffix for constants
that conflict with other identifiers or "_t" for type names that conflict with other identifiers.
(and leave the more commonly used ID of the two alone).

Some might claim that changing HLA's case neutrality feature to case sensitive would
solve the problem. This is not at all true. There are still problems that have to be dealt
with such as C identifiers that conflict with HLA reserved words. Fortunately, namespaces
solve most of the problems and the suffix tricks handles the few cases where namespaces
just aren't sufficient.



once more I must say from what I've seen hla is a masterpiece, the overhead generated isn't much from what I've seen studying the generated masm code and even that can be avoided if one wants to do it all by hand so to speak, also the hla standard lib seems just incredible, and I haven't even started glancing at the classes and objects yet, this will be a ride!

but first I must sleep....


Yeah, me too!
Thanks for the kind words.
Randy Hyde
Posted on 2003-05-25 13:33:45 by rhyde
Randall Hyde wrote:
In HLA, the way you would do this is via type coercion and TEXT constants,

ahh text constants, I knew there was something better in this world than copy/paste, sweet stuff :D


Randall Hyde wrote:
1. put your definition in a (different) namespace (or put the original definition in a
namespace).
2. Use some sort of suffix or prefix character sequence to differentiate them.


hmmm.. well, neither of these are perhaps a good solution in this case, SOCKET definition collides with socket function, both in the 'w' namespace. moving socket or SOCKET out into another namespace seems wrong. and really, any naming convention that allows both a data definiton and a function to carry the same name albeit with different case:ing is really stupid in my book, so I'll probably stick to using 'createsocket' instead of 'socket', looks better next to 'closesocket' anyways ;)


Randall Hyde wrote:
Thanks for the kind words.


you are very welcome, and thank YOU for HLA, I'm currently trying to read up on the powerful macro system, and from what little my small brain can grasp, it is truly great!
Posted on 2003-05-27 18:39:28 by BinarySoup

yeah you're right, shouldn't be impossible to write a program that creates a hhf based on the output of a dumpbin symbol table.


Actually, the original HLA header files for Windows were created by writing a short program that did exactly this. Worked great for all the API functions (still had to do the parameter names and types manually, but this saved quite a bit of effort). The windows.hhf header file was originally created by writing a program that manipulated the windows.inc header file that comes with the MASM32 package. Still require a bit of manual manipulation, but at 17,000 lines of code, any automation at all is a tremendous help!
Cheers,
Randy Hyde
Posted on 2003-05-27 23:56:47 by rhyde