This macro intercepts all the "regular" instructions and lists the bytes generated by each. It is best to include it after the instruction sets and other such headers are defined.

This works well with x86 examples, but not with the examples that use HEX output - there the formatting macros intercept the bytes generated by instructions and convert them into hex text. In that case some other variant of listing macros would be needed - perhaps displaying the actual addresses instead of file offsets, and the bytes generated by instruction regardless of whether they go into the final output or not.

Here's that slightly modified variant that displays assumed addresses instead of file offsets and shows bytes generated by instructions even when they are in a virtual block and do not go into output file:

shows bytes generated by instructions even when they are in a virtual block and do not go into output file

Which is in most cases not desirable actually. For that reason I explicitly omitted everything placed in nested virtual blocks, while allowing to display their internal content when additionally placing the ilen_/_ilen block inside. But in your case you also handle the virtual blocks incorrectly, because changing the addressing space does not necessarily mean setting current offset to the new base:

This approach has also another disadvantage: the instructions are not shown if they are generated by a higher-level macro such as invoke. This results in longer byte sequences without providing a good reference to what these refer to.

shows bytes generated by instructions even when they are in a virtual block and do not go into output file

Which is in most cases not desirable actually. For that reason I explicitly omitted everything placed in nested virtual blocks, while allowing to display their internal content when additionally placing the ilen_/_ilen block inside.

The purpose of this second variant was noted in the first post - it is something that works with the examples that use the HEX output. The detection of changing addressing areas is very crude and flawed for the reasons you mentioned, but still this simple modification manages quite well to show the instruction codes.

Sorry, I missed that part. But the idea I tried to express is still same: it's better to use block-wise application of whatever effects. Nested blocks allow to differentiate what effect should be applied first. If done right, works quite well.

For example, the implementation of HEX.seg/HEX.endseg is problematic: to allow for nesting I always used in-place modification (needs improvement for compression cases) instead of enclosing into virtual-blocks. The org-directive however is a pain in the ass, and in early implementations I used the same close-reopen-block trick in an org-redefinition, but many encodings (e.g., into base64) are very hard to do that way, and supporting nesting requires to do all paired macros of such "encoding"-kind in a uniform way. So I switched to a different approach: all the data across all addressing spaces separated by the org directive are gathered into a single virtual-block, then converted using whatever encoding, then stored back overwriting the original bytes.

Here's that slightly modified variant that displays assumed addresses instead of file offsets and shows bytes generated by instructions even when they are in a virtual block and do not go into output file:

This is cool, but there were no actual usage examples ?

I played around by drop of the above into listing.inc & then

Code:

include'listing.inc'

and that seems to generate a listing in the console, needing this for a file

Code:

..\..\fasmginvert.asminvert.bin > invert.lst

I notice that seems to go a little strange if

Code:

include'hex.inc'

is also active - ie it seems designed for BIN output only?
or is there a include order or placement that works better with HEX ?

addit: Testing this, I see it appends this at end of list, on a pass

2 passes, 95 bytes.

and appends nothing on an asm fail, which is a little vague.

Can Fasmg instead list the Errors, so the LST file says either of

2 passes, 95 bytes. 0 Errors.
or
3 Errors.

It seems to not report the errors in the list file ? - I'm not sure how easy that is to add ?

That 2nd one, was the one I used for the tests.
It seems to do the listing part ok, but then appends some extra garbage, when HEX is enabled ?

It shows the bytes generated by the HEX macro itself (the macro converts the instruction bytes from virtual blocks into HEX format and writes this into output with DB). You could turn off the listing macro before HEX finisher jumps in by adding these few lines into listing.inc:

Code:

postpone
purge?
endpostpone

But you need to make sure that listing.inc is included after hex.inc, because postponed block are executed from the last to first (and this way you also ensure that the not-postponed lines from hex.inc are not included in listing, either).

Because the macro does not differentiate what lines does it show, if you want all the lines from hex.inc to be ignored you may also modify the HEX macros themselves and make them generate listing of the code-related lines (this could be a "HEX with listing" macro package). Or even this simple trick could do the job:

Apparently this variant of listing.inc does not work well with such "proc" anyway, because "proc" is not an unconditional macro (so it becomes a line processed by listing macro) but it opens "if" block without closing it - and this variant of listing macro tries to execute original line inside the "else" block, thus creating an overlapping of the control blocks, which leads to errors.

Here is a corrected variant that still executes the line outside of the control blocks. Some additional dummy macros are needed.

Apparently this variant of listing.inc does not work well with such "proc" anyway, because "proc" is not an unconditional macro (so it becomes a line processed by listing macro) but it opens "if" block without closing it - ...

? Isn't that normally considered an error ?
Most pgms I use, get rather upset if they hit unbalanced blocks, as usually that is a user-typo.

Apparently this variant of listing.inc does not work well with such "proc" anyway, because "proc" is not an unconditional macro (so it becomes a line processed by listing macro) but it opens "if" block without closing it - ...

? Isn't that normally considered an error ?
Most pgms I use, get rather upset if they hit unbalanced blocks, as usually that is a user-typo.

Yes, this is exactly what caused the problem here, the control blocks must be nested properly, so after "if" fasm was awaiting "end if" before the "match" block got closed.

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