Do you think that fasm would somehow be able to prevent its other instance in the future from accessing some of the files it created?

The "virtual files" are not actual files in my understanding, just like guinea pig is not really a pig.

I think it would be more useful to have an option to specify the folder where the auxiliary outputs would get stored (the default setting would be to use the same folder as the main output file)

I got an impression that you don't approve them

fasm already allows to utilize the environment variables more than I ever wanted

Also, please note that the folder of the main output is not necessarily the same as current directory

My impression is that you are concealing something, that justifies all of the design decisions you make. Until now I could not even make you reveal any use cases on your mind except for some questionable debugging (by analyzing the content of the addressing spaces) implied by this post.

What appeals to me in this feature is not the ability to mess with file system, but the ability to store some additional information beside the main output format. The DISPLAY is there for this purpose, but ability to create supplementary files could sometimes make one's life easier.

I don't think, that using another environment variable for storing the output path means any more utilization, than there already is.

Quote:

Also, please note that the folder of the main output is not necessarily the same as current directory

How do you come to the "necessity"? I always talked about defaults. "Default" does not imply necessity. As for me it's not crucial whether the defaults for the secondary output would be the main output folder or the current one.

Then I'm just curious if this is the next feature to appear. Or are you planning to finalize any of the outstanding before? Such as relocation information in loop variables or whatever else?

My main plan is to have AVX512 support for the 1.72 milestone...

And it's almost surely not what m3ntal expected.

FASM can load external source+binary files (include+file), but there is no way to save files as .EXT at assembly time. You must assemble the entire project as .EXT (format binary as '.EXT'). Example:

Code:

savefile p, 'NAME.EXT'    

This is merely a suggestion. And I only care what Tomasz thinks on this issue.

format binary as 'asm'
file 'version.asm'
load PROGRAM_VERSION qword from $-8

rept 1
{
    common local d
    repeat 8
        d = PROGRAM_VERSION shr (64-%*8) and $FF
        if d = '9'
            PROGRAM_VERSION = PROGRAM_VERSION and not ($FF shl (64-%*8)) or 'A' shl (64-%*8)
            break
        else if d = 'F'
            PROGRAM_VERSION = PROGRAM_VERSION and not ($FF shl (64-%*8)) or '0' shl (64-%*8)
        else
            d = d + 1
            PROGRAM_VERSION = PROGRAM_VERSION and not ($FF shl (64-%*8)) or d shl (64-%*8)
            break
        end if
    end repeat
}
store qword PROGRAM_VERSION at $-8

define PROGRAM_VERSION $00000000    

Y:\>fasm version.asm && echo. && more +23 version.asm
flat assembler  version 1.71.33  (1048576 kilobytes memory)
1 passes, 683 bytes.

define PROGRAM_VERSION $00000001

Y:\>fasm version.asm && echo. && more +23 version.asm
flat assembler  version 1.71.33  (1048576 kilobytes memory)
1 passes, 683 bytes.

define PROGRAM_VERSION $00000002

Y:\>fasm version.asm && echo. && more +23 version.asm
flat assembler  version 1.71.33  (1048576 kilobytes memory)
1 passes, 683 bytes.

define PROGRAM_VERSION $00000003    

if 0
    include 'version.asm'
end if    

This feature has been finally implemented in fasmg but it might also be applied in a similar way to fasm 1 if it continues to be requested.

Tomasz Grysztar wrote:

This feature has been finally implemented in fasmg but it might also be applied in a similar way to fasm 1 if it continues to be requested.

Yes, please! It opens some interesting ways of managing auxiliary debugging data and project management.