A suggestion for the 64 bit version.

[hutch--]

This may sound like heresy for an assembler but there is no reason to be restricted by assumptions from the past when it comes to the design of a new tool like the Habran Assembler. It is common for C compilers (not necessarily C++ compilers) to have some minimum run time library to support a number of mechanisms and in this case the "switch - endswitch" capacity in the available notation. It is relatively easy to store an fully optimised algorithm and simply add it to the end of the executable where the linker would normally place and selected modules.

As far as doing a high performance table based version for known limited ranges of numeric inputs, again doing it directly in binary would have to be a lot cleaner than trying to fit it into a macro capacity. I have a basic compiler I use that has this option and its close to as fast as a manually coded table version in MASM so it certainly can be done.

[mineiro]

I think this is the place to put suggestions to developer.
I never have see this type of "macro" in any assembler, so this is my point of view.

The point is: Modular macro
This way we (users) don't need ask for a new feature, like invoke macro not supported on others O.S., calling convention, output format, ABI, etcetera.
We only need access the macro on source code being assembled using assembly language as a macro, the best language to a macro.

So, you can create an environment to user modular macro land, you can dispose internal hjwasm functions to speedup macro code (strlen, assemble, ...).

When assembler trigger invoke modular macro, it create an environment to user (will pass the text) and assemble macro and execute macro on runtime.
So, user have a supposed pointer to start of modular macro (user will only deal with text (source code), nothing more), in this scenario the pointer to letter "i" of invoke, but their modular macro is assembled on runtime or by using a module (you can create your own filetype and environment).

this way, he can create more flexible and portable code, and can too agregate instructions of others microcontrolers,processors while maintaining compatibility with hjwasm syntax.

An pseudo example of invoke macro.
invoke function,1,2,3

So, the macro can be, just a noob perspective from now:

Code Select Expand


invoke modular macro
assume si|esi|rsi: ptr macro name           ;your environment here
;below is the assembly macro module that will be called by hjwasm
mov ax|eax|rax,si|esi|rsi          ;let's calculate the size of something
.while byte ptr [si|esi|rsi] != " " ||  byte ptr [si|esi|rsi] != 09h   ;searching for space or tabs
inc si|esi|rsi
.endw

;we reached function name easily, using assembly language.

I think anyone on this board understood this macro and know how much powerfull it can be. So, we need a way to insert "assembly instruction strings" into source code being assembled.

Of course, I know this can reach big problems, like memory faults, ilegal instructions strings,  many initial errors, but this is user fault, not developer fault.
This way many persons here can create macros by their own way and add that to your assembler as a preloaded module when it gets mature.
So, we don't need be a International Master with hjwasm macros to develop International module macros. Well, I think I will only use these types of macro if you develop them.

[habran]

Hi hutch,
At the moment we are busy implementing VECTORCALL in HJWasm. When we get it done John will provide detailed manual how to use it and some examples. With this feature our goal will be completed (for now) and than we will focus on libraries, examples and headers.
It is a personal meter what tool someone will use for programming.
Before Japheth started JWasm I came to conclusion that only option I was left with was FASM because it is open source and free, so you can use it for commercial use. I did not like some features of it (macros, [], includes) and I was happy when JWasm became available. I was pushing Japheth to implement more advanced features. Now, I wouldn't change it for any other tool. John and myself are developing HJWasm for our use but we are generous and make it available for everyone who is interested, and even if no one want to use it any more we will continue to develop it.

From my life experience I have learned that we "human" will always choose the worst option available.
In my former country (former Yugoslavia) we had to use our representative for us employs and we would always chose the most stupid person to do that and than we would wander why are we in such a bad situation.
Similar thing will soon happen in US as happened here in OZ when they chosen H**ard.
However, that is a human nature, we love to suffer  

[hutch--]

Hi Habran,

Its good to see that you are in the later stage of development with the assembler as the next stage of libraries, examples and headers will be the great leap forward that will make the project viable for a far wider range of people. FASM is a very good tool that is well written and reliable but I only have one life and I confess I don't like the TASM style addressing mode that it uses as I have been using Intel based MASM notation for too long to change to another system.

Something I would like to see is the removal of the last of the WATCOM code so you and John can licence it yourselves and get it out of the Open Source Licence system. A high quality freeware assembler would be of great benefit. Another suggestion here, when you have it finished, find a new name for it as the current one tends to be a mouth full.

[habran]

It will be hard to get rid of Watcom code while it is in C language but when we get all done as we want it, we will rewrite it  all in 64 bite assembly language and than we will change the name to HASM because John's family name and mine family name start with H. I am looking forward to that because I am not C programmer but ASM programmer.
I am waiting for EVEX processor so that I can take advantage of large set of registers.
For the processors without EVEX registers I will use macros to represent EVEX registers.

I have no intention to abandon such a great tool, I can only make it better, only madame Death can stop me, however, in that case John can continue to maintain it, he is now in his best.