flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Compiler Internals > Suggestion: Save Virtual Block as File

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
While the design of "decide in compilation summary window" that I sketched for fasmw looks like a convenient way to handle it, I'm having second thoughts about the semantics of command line option. 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). This would be more consistent with existing options to specify the path+name for main output and .fas output, and the default behavior would be predictable enough to be an acceptable choice, IMO (as the auxiliary output definitions would be limited to specify a simple name, without any path elements).
Post 20 Jun 2014, 11:10
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
Tomasz Grysztar

Quote:
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?


First of all, fasm can prevent storing of those files. E.g. by requiring a command line switch discussed before.

But I think, it's not about prevention. It's about making it easier or more difficult. The former can be achieved by providing some special means for the include and file directives (such as a well-known pseudo-environment variable), so that a developer can be more or less sure, that subsequent compilation would access the same file stored before. The latter can be achieved by randomly generating a file name, where addressing space data is stored (and that's what I mean by the invalidation).

If the use cases I talked about are something similar to the use cases you have in mind, then you should be willing to simplify such accesses in subsequent compilations. And then I can't understand what you found unclear about my questions from my pre-previous post, and why your "considerations apply to a single compilation only".


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


I didn't consider "virtual files" and files to be the same. You could call the "virtual files" mgaguchas . But you already defined the mgaguchas as an abstraction for something that eventually may or may not be a persistent file depending on some settings. So once again, what's the problem to spread this mgaguschas abstraction beyond the scope of the newly introduced feature, so that it becomes useful for an older feature, the file directive?

I'd like to clarify my position in the discussion. Whether you define the "virtual file" as something accessible by the file directive or not is not something I really care about. However I see these two alternatives and I see, that the one has an advantage, even if it's absolutely tiny, and the other one does not. I see no other significant differences, neither from the pragmatical, nor from the conceptual point of view. And now you decide for the alternative without the advantage. How come?

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Jun 2014, 11:23
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
Tomasz Grysztar

Quote:
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 don't wanna appear to be very confident, but it seems that you are coming closer and closer to the suggestions, I was giving from the very beginning. I.e. the option would be an environment variable with the path, which is accessible even if it's not explicitly defined, in which case it has a default value (current directory).

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Jun 2014, 11:32
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
I don't plan to to get any closer to introducing new environment variables. 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.

As for the other characteristics of my design, I'm not sure how close they are to the one you had in mind, because during our discussion I got an impression that you don't approve them.
Post 20 Jun 2014, 12:40
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
Tomasz Grysztar

Quote:
I got an impression that you don't approve them


I can't approve or disapprove them without knowing the background argumentation. 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. If this is the only use case you want to support, then the utility of the new store directive is too low IMHO. And it's almost surely not what m3ntal expected.


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


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.

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Jun 2014, 13:10
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland

l_inc wrote:
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.

In that very post I wrote what is my justification:

Tomasz Grysztar wrote:
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.

That's why I started to call it an "auxiliary output". The DISPLAY buffer already is a kind of auxiliary output (and can be redirected anywhere you want), but an option to have such output sorted into a separate files can be handy when testing some code that uses data buffers in multiple virtual blocks, like my LZW compressor.

The other scenario that I keep in mind from some older requests is to be able to make multi-file output for the cases when some separate files (like external signature, or function tables, etc.) are needed beside the main executable.


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

It would be "more", because at the moment you cannot use the environment variable to specify the output path. By my choice the output path is specified through the command line.


l_inc wrote:

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.

I was merely pointing out that these are two different possibilities for the default setting, and the difference between them may be crucial in some cases.
Post 20 Jun 2014, 13:31
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
Tomasz Grysztar
OK. Finally we got to the point, when you explicitly say, that you are just not going to support any of the use cases I talked about. I.e. none of those based on passing data between compilations. And then yes, I can now say, that I'm not excited about it.

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?

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Jun 2014, 14:16
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland

l_inc wrote:
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 I may actually leave the new experimental features for the 1.73.x line.
Post 20 Jun 2014, 15:09
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
Tomasz Grysztar
Nice to know. Thanks for the information. And for the discussion. Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 20 Jun 2014, 15:21
View user's profile Send private message Reply with quote
m3ntal



Joined: 08 Dec 2013
Posts: 296
Tomasz:

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

I understand. You're concentrated on the assembler aspect and the language (preproccessor+directives) can be a distraction.

l_inc:

Quote:
And it's almost surely not what m3ntal expected.

No expectations. Just a suggestion.

Thanks!

_________________
New FASM Site, Examples, Graphics, Updated Libraries
Post 20 Jun 2014, 17:58
View user's profile Send private message Reply with quote
TheRaven



Joined: 22 Apr 2008
Posts: 77
Location: U.S.A.
Re: Suggestion: Save Virtual Block as File

m3ntal wrote:
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.



I'm feeling it regardless of whether m3ntal cares about my opinion! Crying or Very sad
Object or text output right???
I smell incremental build with specialized object code -- I like it.

There also appears opportunity here considering text output in addition to FAS files greatly extending debugger support - it's foggy, but none the less...

_________________
Nothing is so sought after and often avoided as the truth.
Post 15 Jan 2015, 12:37
View user's profile Send private message Reply with quote
Grom PE



Joined: 13 Mar 2008
Posts: 113
Location: i@grompe.org.ru
I have one question:

What can be done with the proposed feature that cannot be done with multiple .asm sources?

I think having a bunch of small .asm files that include main source and define a mode of operation fulfill this functionality in an obvious and expected way.
Post 23 Jan 2015, 14:41
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
Grom PE
The author's idea is to allow to store information related to the current source, not the actual output. If you have a virtual section with some content that depends on the the output data, then you currently can't specify any "mode of operation" by creating a separate top-level source file, so that all the original output data wouldn't get into the output, but the virtual section would.

Your suggestion is however applicable to the use cases I was talking about. E.g., automatic version incrementing could be done with a separate version.asm file:

Code:
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-%*8and $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



This is a self-modifying source code. Each time you compile it as a standalone source, the PROGRAM_VERSION is incremented:

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

define PROGRAM_VERSION $00000001

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

define PROGRAM_VERSION $00000002

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

define PROGRAM_VERSION $00000003



But if you include it into your main project file like this (could be wrapped into another file like VER.INC for convenience):

Code:
if 0
    include 'version.asm'
end if


then you'd just get the PROGRAM_VERSION constant. It could be used by your main project for whatever purpose. A PRNG could be implemented in a similar way.

_________________
Faith is a superposition of knowledge and fallacy
Post 23 Jan 2015, 21:33
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
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.
Post 08 Oct 2017, 17:21
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria

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. Smile

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 19 Oct 2017, 20:50
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 88
Location: Belarus

JohnFound wrote:

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. Smile


+1 for backporting the feature.
Post 20 Oct 2017, 09:41
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
OK, I think it is finally a right time to close the 1.71.x development line, release the stable 1.72 and start 1.73.x for the new features.
Post 20 Oct 2017, 10:49
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3459
Location: Bulgaria
Hooray! Cool
Post 20 Oct 2017, 10:58
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
Well, this took a while but version 1.73.00 has it.
Post 24 Nov 2017, 23:09
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.