flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > FASM1 equivalent for __FILE__?

Author
Thread Post new topic Reply to topic
DimonSoft



Joined: 03 Mar 2010
Posts: 958
Location: Belarus
DimonSoft
As far as I can tell, we don’t have that. There were at least several suggestions but I can find no feedback about them. Is there any particular reason for not having it implemented? Like from design point of view or something…
Post 12 Sep 2021, 13:35
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7938
Location: Kraków, Poland
Tomasz Grysztar
No, there's nothing really preventing back-porting this to fasm 1, I just never attempted it. Because fasm's assembly-time variables have limited capacity, __FILE__ would have to be implemented as a preprocessor variable (like EQU definition), while __LINE__ could be an assembler's variable (like %T is already).
Post 12 Sep 2021, 14:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7938
Location: Kraków, Poland
Tomasz Grysztar
After giving it more thought: a better choice might be to make them both preprocessor built-in variables, and make it a syntactic distinction that symbols starting with "%" are assembly-time variables, while "__" ones would be preprocessor-time. Also __TIME__ could be a preprocessor-time equivalent to %T (while in fasmg they are just plain synonyms).
Post 13 Sep 2021, 19:21
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 958
Location: Belarus
DimonSoft
I was afraid the real reason is that the next suggestion is going to be something like parsing file names like they do in BAT files, like extracting plain filenames/paths/extensions at the preprocessor stage Smile

P.S. In fact, __LINE__ and %LINE should maybe mean different things. Or maybe shouldn’t. If we discuss the use case of producing debug output, it’s probably better for a programmer to have the line number within the original source code, not the preprocessed one. OTOH, in C/C++ both __FILE__ and __LINE__ are preprocessor stage variables and nobody seems to complain, so maybe it’s not even worth messing up the assembler stage. There might be valid use cases for assembler time line numbers but I can’t see any right now.
Post 14 Sep 2021, 17:07
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18220
Location: In your JS exploiting you and your system
revolution
DimonSoft wrote:
There might be valid use cases for assembler time line numbers
There's always a reason for something Razz
Code:
;...
asserton_error_42 = %l+1
cmp eax, 0x1234
mov ecx, asserton_error_42
ja .error_error_error
;...
.error_error_error:
stdcall printf, <"Assertion error at line %u",13,10>, ecx
;...    
Post 14 Sep 2021, 18:04
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 958
Location: Belarus
DimonSoft
But why would assembler stage line number be better than preprocessor stage one for this case?
Post 14 Sep 2021, 18:29
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18220
Location: In your JS exploiting you and your system
revolution
DimonSoft wrote:
But why would assembler stage line number be better than preprocessor stage one for this case?
Because less typing and more cryptic, so more "assembly style" and less "HLL OOP style". Razz

Why not both?
Post 15 Sep 2021, 00:47
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 958
Location: Belarus
DimonSoft
Well, I guess, IF Tomasz decides to implement these the final choice is not ours anyway.

I’m just not sure if line numbers relative to preprocessed code would have any meaning to anyone. If not, the changes could be limited to the preprocessor only which seems more probable to be added to the list of “features to implement in good-old FASM1”.
Post 15 Sep 2021, 21:38
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7938
Location: Kraków, Poland
Tomasz Grysztar
My attempt is ready with 1.73.28 release. I extended the EQU processing with ability to recognize special variables with __*__ names, and implemented __FILE__ and __LINE__ this way.

Because this is done during preprocessing, the number can be converted with ` operator if needed:
Code:
macro warning_assert condition*&
{
        if ~(condition)
                display 'Warning: assertion failed in ',__FILE__
                match line,__LINE__ \{ display '[',\`line,']' \}
                display 13,10
        end if
}    
And it also works with REPT:
Code:
rept 1 n:__LINE__ { display `n }    
And it is evaluated in EQU definitions like any other symbolic variable:
Code:
c equ __LINE__


c equ __LINE__ - c

rept c { display '.' }    
There may be some loose ends in the implementation, after all it is a brand new thing in the old preprocessor. You can still try to define symbols with such names using EQU, but it has no effect (this differs from fasmg, but fasm 1 has different considerations).
Post 16 Sep 2021, 11:23
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:  


< 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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.