This is the first part of a series where I plan to talk about some unusual and complex trickery that can be done with fasmg. I'm going to deal with problems that I consider too eccentric or difficult to mention in my introduction to fasmg, therefore these texts are going to require an "advanced" level of knowledge about fasmg - please keep the manual at hand.

The other installments: part 2, part 3, part 4.
_______

We're going to start with a problem that appears simple on the surface, but it is not. In fasmg the ORG and SECTION directives both begin a new section of output file (they differ only in how they treat the uninitialized data that came before) and to accentuate their function they are not allowed inside a VIRTUAL blocks. Of course, as almost everything in fasmg, this can be adjusted with macros, so let's try it.

If what is needed is simply to change the origin address for a portion of virtual block, this classic behavior is easy to emulate with a set of macros that look like this: This alters every virtual block so inside it ORG is a macro that switches to a new virtual addressing space. The local "addr" variable is used to compute the value of address before closing the virtual block, just in case the specified address is an expression that uses values like $ or $$.

But there is also a different scenario, where the specific function of ORG is more apparent and this simple emulation does not help. Let's say that we need to take an entire source of program, like the basic Win32 example from fasmg package, and put it inside a VIRTUAL block, so that we can read the values of symbols defined there without generating actual output (perhaps because we want to output some other data instead).

Now this poses a complex problem, because the PE formatting macros not only use ORG and SECTION, but also the values of $% and $%% - the offsets within generated output file. Of course PE format macros could themselves be modified to use only relative offsets (like $-$$), but for the exercise let's say that we want to assemble a foreign source without changing it. We need to provide the correctly computed values of $% and $%% then. The following sample prepares what is necessary to assemble the PE macros inside a VIRTUAL block: A variable named $$% is used to hold the offset within the virtualized output file. Note that definitions inside ORG and SECTION macros use an identifier with attached dot to change this value - this ensures that the global symbol is modified even if the macros are used inside a descendant namespace. The END VIRTUAL is postponed, because PE formatting macros themselves use postponed block to finish the executable. We can go one step further and intercept the postponed blocks in the foreign source, to launch them in a controlled fashion: However even though those macros work correctly with the PE example, their method of computing $%% is not correct in general. The difference between such defined $% and $%% is always the same as between $ and $@, and this is the size of uninitialized data at the end of current addressing space. But if there are multiple consecutive areas containing only uninitialized data, computation of $%% should take them all into consideration. The following modification deals with this problem, though it does it in a tricky way: The additional @% variable holds the size of uninitialized data in previous spaces (I used the cryptic names for these variables to keep the expressions short, but longer names would work just as well). The trick is that we need to subtract this value from $%% only when there is no initialized data in current space, and this is true when $@ is equal to $$. The expression 1/($@-$$+1) is a contraption that generates 1 only when $@-$$ is zero, and 0 otherwise.

The last variant does handle everything that is needed to "hide" it from the foreign source text that it is assembled inside a virtual block and it even cleans up after itself with PURGE and RESTORE, so any source text that follows can use the ORG and file offsets in their original meaning. The only problem we could still have are the symbol name clashes, and this will be covered in the next part.

The only way to read the whole output within the program is to do it in multiple chunks, one per each virtual block, correct?
Since the "load" instruction cannot read across an "org", "section" or "virtual" boundary yet the offsets can be changed only by those.
It seems faking $ and $$ won't be enough since the address of labels won't be adjusted this way.

Yes, this is the only way. For example pe.inc has to deal with this problem when computing the checksum - it collects the labels of all the separate areas into CheckSumBlocks variable and later iterates through all of them.
Well, you could try to catch label definitions with "struc ?" and emulate them appropriately. I'm not sure if that would be practical, though.