Hi there. I'd like to ask, if it's possible to make a following improvement in fasm. If one needs to do any sophisticated code encryption (not a very simple like the one described in the documentation), he possibly will confront a problem to get a code outside of a fasm virtual addressing space.
AFAIK the only one way to achieve this is to declare many symbolic constants loaded with parts (bytes, words, dwords...) of a code located in a virtual-block by means of a rept-block. Well... Except for one little problem this solution would be acceptable for me.
The "little problem" is that it's impossible to know the size of the code in a virtual-block in a preprocessing stage (rept directive processing stage). And I think, there is no effective solution to overcome this problem.
So my suggestion is to allow an optional name of addressing spaces.
Example of a code, using the suggested improvement (no encryption, just a very simple example of how it would look like):

This code sends some dwords back and forth. Hereby addressing space names are acting like special labels. As much as I can estimate this improvement would be fully backward compatible. So I see no disadvantages. Is there any reason for making no such improvement?

I like this part

I think this is a good suggestion. I'm sure it could be useful in some places.

Currently fasm does not keep information about previous sections. It would require some not-so-simple changes to implement it. So I guess it comes down to would the time required to add this be outweighed by the benefit gained with this new feature?

l_inc: If you can produce a sample version of fasm with this feature working it might help you towards getting this implemented. No guarantee though. Just a suggestion for you so as to improve the likelihood of having it in official versions.

If you watch the fasm 2 presentation video carefully, you are going to notice, that it has a similar feature with double colon syntax (it's on the fourth "slide"). You may also notice that there is something mentioned about difficulties of implementing it with fasm 1 architecture.

bitshifter
If you think, it does nothing in the real fasm, you're wrong.
revolution

I understand it. But I think this is an enough useful feature to take a challenge.

I've never really looked into the fasm's source files. Just a couple of times without any purpose. And as long as the source is as flat as the assembler (I mean there're no text indents there), I considered it unreadable for that time. No offense, but I think the author has much better understanding of fasm than I will ever have. Also I heard, that patches were never accepted.
Tomasz Grysztar
I think the presentation link is dead. At least it doesn't work for me. But thanks. I've never heard about the second version. If you say, there will be such feature in fasm 2, I believe you without watching the presentation video. Is there any hypothetical approximate terms for its first release?
And... As I understood, you have no intention to implement it in the first version, have you?

in theory display as a reserved word could be a load/store operand and an intermediate buffer between address spaces maybe

double fail i think, there is the only memory and Tomasz is still making the borders, i do not understand, possibly time lack of that man

load RAW ...
store RAW ...
could solve the dilemma

Could anyone show meaningful use of named addressing spaces outside of load context?

Tomasz, end virtual doesn't restore context exactly, was that intended?

VIRTUAL only creates an addressing space, it has nothing to do with code generation modes.

See version 1.71 for the new address space naming feature.

http://board.flatassembler.net/topic.php?t=14608

revolution
Thanks. I know. Downloaded it as soon as it was available. It's getting better and better. I will be missing those tricky and creative solutions with in-place data modification and reordering.

Heh, I don't think I'll be missing them.

I second this Debugging hundreds of made-on-the fly variables is not fun. I've already written AES in a fraction of the time and hopefully the larger SHA/WHIRLPOOL will be just as easy now too