Is this the complete source that causes the problem? If not, please provide the complete minimum source text that I can use to reproduce this (the above one works fine for me). What is your environment? And the exact fasmg version?

Suggestion: I think you can still edit the first post,in that thread ?
It can be easier to find/follow, if the lastest version, with a version number, is included in the first post - ie the first post has the revisions, and readers do not need to trawl/merge to find latest.

but there are bugs in there, as the pairing somehow effects listing, and it bumps from 4162 lines to 7910 lines. Bonus lines look to all be 18 spaces per line.

I would need to see the exact versions of these macros that you use, the best would be the complete set of files to reproduce the problem. I've been putting many different versions of these macros on the board, sometimes with bugs - and, frankly, I thought that I'm just giving some simple examples to demonstrate some general methods that others might refine into something suitable for their needs. None of them were the "perfect" version, I even noted in several threads already that creation of a good macro framework for given architecture requires careful design of the interactions between various parts, and any macros should be adapted accordingly.

jmg wrote:

Those speed impacts look to make a good case for having HEX & LST as a native options in fasmg, as they are pretty fundamental assembler leg-work.

The main principle of fasmg is that it is a pure macro engine. It could become a base for fasm 2 or other similar assemblers, and such fasm 2 would implement some output formats internally (just like fasm 1), but fasmg intentionally does not. In fasmg macros need to have control over everything - but as soon as the assembler starts to implement some things (like output formats with relocations) internally, it becomes harder and harder to let the macros control all aspects of the assembly (for example, up to this day I did not manage to create a satisfactory mechanism of allowing macros to generate custom relocation formats in fasm). Therefore I decided to go in this direction - considering that nowadays computers are so fast that even the insanely complex macros like x64 output with relocations can still assemble some programs in reasonable time on my Windows tablet (the self-assembly of fasmg as either PE or a relocatable ELF object takes 7-8 seconds here, this is in fact similar time to how long the self-assembly of fasmw originally lasted on my good old Pentium 60 MHz). It is an experiment that turned out very interesting, and I found out that there are some people that find it useful enough (obviously it works best for the ones that are already familiar with fasm, since fasmg takes many features of fasm's macros and improves them), so I decided to work on it a bit more. But still, fasm 2 and perhaps other natively-implemented assemblers based on this engine may be created in the future. I planned to create some kind of assembler construction kit based on fasmg's engine - but for now experiments with macros eat all my free time. Having x86/x64 macros I can experiment with how things could work in fasm 2, without having the actual fasm 2 - this is a very fruitful environment for me.

Those speed impacts look to make a good case for having HEX & LST as a native options in fasmg, as they are pretty fundamental assembler leg-work.

The main principle of fasmg is that it is a pure macro engine. It could become a base for fasm 2 or other similar assemblers, and such fasm 2 would implement some output formats internally (just like fasm 1), but fasmg intentionally does not. In fasmg macros need to have control over everything - but as soon as the assembler starts to implement some things (like output formats with relocations) internally, it becomes harder and harder to let the macros control all aspects of the assembly (for example, up to this day I did not manage to create a satisfactory mechanism of allowing macros to generate custom relocation formats in fasm). Therefore I decided to go in this direction - considering that nowadays computers are so fast that even the insanely complex macros like x64 output with relocations can still assemble some programs in reasonable time on my Windows tablet (the self-assembly of fasmg as either PE or a relocatable ELF object takes 7-8 seconds here, this is in fact similar time to how long the self-assembly of fasmw originally lasted on my good old Pentium 60 MHz). It is an experiment that turned out very interesting, and I found out that there are some people that find it useful enough (obviously it works best for the ones that are already familiar with fasm, since fasmg takes many features of fasm's macros and improves them), so I decided to work on it a bit more. But still, fasm 2 and perhaps other natively-implemented assemblers based on this engine may be created in the future. I planned to create some kind of assembler construction kit based on fasmg's engine - but for now experiments with macros eat all my free time. Having x86/x64 macros I can experiment with how things could work in fasm 2, without having the actual fasm 2 - this is a very fruitful environment for me.

I can understand that, but native support does not have to exclude macros & their flexible use.
Macro's have pluses, but for these most basic of tasks, 'flexible' matters less than speed, and those speed impacts are significant. 0.2s to 27s is a massive hit !

Intel hex especially, is very well defined, and is simply an output format-variant.
Even a LST file is not widely variable, they all follow the same rules.
Address: Hex Info : Source line fragment.

Given the interaction of macros here, maybe it is better to just include a BIN2HEX separate pgm with fasmg, that can work on the BIN output.

A good (but old) example is here, has most of the options users need...

...the self-assembly of fasmg as either PE or a relocatable ELF object takes 7-8 seconds here, this is in fact similar time to how long the self-assembly of fasmw originally lasted on my good old Pentium 60 MHz)...

Now that's cool & would make a good demonstration.
Suggestion:
Can you include a directory in the install, that can do that self-assembly of fasmg ?

I can understand that, but native support does not have to exclude macros & their flexible use.

Yes, and an assembler like fasm 2 would still have the complete macro engine of fasmg beside the natively implemented formatters and instruction encoders. But then the macros would no longer be able to control everything like they can when everything is macro-based, like in fasmg. I know that the idea behind fasmg is a bit insane, but it is just a culmination of what I've been doing for years with fasm and I find it very inspiring.

Thus what you are looking for is perhaps a specialized assembler based on this engine, like the nonexistent fasm 2. I'm going to work on my fasmg-based "assembler construction kit" for this purpose, but it would still require some able and interested people that could use such kit to make actual assemblers, and this would probably be a bit harder for a third person compared to writing macro packages for fasmg (though when one is accustomed to x86 assembly, then not that much harder, the internal interfaces of fasmg engine are relatively simple to use).

jmg wrote:

Can you include a directory in the install, that can do that self-assembly of fasmg ?

addit: this seems to work ? Is it really this simple ?

..\fasmg windows/fasmg.asm fasmg.exe

Yes, it works just like that. The docs/fasmg.txt mentions it too. The sources are prepared in such way that either fasm or fasmg can be used to assemble them.

I have found out what causes the excess passes - the MATCH directive used by this variant to detect LIST/NOLIST switches forward-referenced the symbolic constants present in your macros. The easiest correction is to replace MATCH with RMATCH:

This may the first time I used RMATCH to solve some problem. I implemented this directive because I predicted that it could sometimes be necessary, but until now I did not encounter a problem for which the use of RMATCH would be the correct solution - I need to remember this case, and perhaps make such example in documentation.

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