Recently I've been working on a set of basic compatibility macros for fasmg that would allow to assemble sources written for fasm with its standard Windows headers, with as few changes as possible. I have now completed a version that assembles most of the Win32/Win64 examples from fasm package and I'm attaching it here.

Note that I do think that any such headers for fasmg (or fasm 2, if such ever arrives) could make better use of the macro capabilities of the new engine, therefore I think that developing some entirely new macros with new and improved syntax could be a good direction. But converting the standard fasm's includes is an important first step.

Not every behavior of fasm's macros is preserved - for example, as I explained in the other thread, "proc" macro I prepared for fasmg creates a separate namespace for every procedure - because this is how it should have always been working, and it was only because of the limitations of fasm's macro engine that its "proc" did not really work like that (though it at least kept the local data labels limited in scope). This means that local labels inside "proc" no longer need to start with dot.

The "struct" and "union" macros I used are the plain ones I created for fasmg, and they do not reproduce the complete behavior of fasm's "struct". This should change later - I still plan to write a variant more compatible with fasm's one for the inclusion in this package, though in general I prefer the new one, for its simplicity and flexibility. Using the new version required some changes of syntax in fasm's examples, because this variant of "union" needs to end with "endu" and the values to initialize fields in structure need to be labeled instead of providing them in original order.

When converting the resource macros I was really amazed how old and fossilized they are, with weird syntax choices that date back to the time when fasm had only very basic macro abilities, and implementations that have not been touched in ages. I converted them all, preserving the compatibility, but I think that their syntax really could use some renewal. The same can be said about import macros.

And another update, this time with extended "struct" macro which allows to initialize fields' values sequentially, like fasm's "struct" did. Both ways of providing values for fields are now allowed.
In fact, the "struct" macro in this package should now support all the documented features of its fasm's counterpart, while still allowing the new (named) style of field initialization.

At least I've seen that other compilers do an additional alignment here and this is why the wLength and the wValueLength are different fields here. The same with the macros for the FASM1, it also doesn't have this align directive here.

It might also be worth noting for anyone not currently aware, and wondering why there is the extra complication, that using EAX instead of RAX produces a smaller code footprint because there is no REX prefix needed.

One could also write a MOV macro that would do this additional optimization automatically, similarly to the TEST optimization that was once discussed. Since in case of fasmg instructions are just macros anyway, we could add a package of such optimizations as an optional variant that would not have much overhead compared to the basic ones.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum