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: 1042
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: 8017
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: 8017
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: 1042
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: 18743
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: 1042
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: 18743
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: 1042
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: 8017
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
DimonSoft



Joined: 03 Mar 2010
Posts: 1042
Location: Belarus
DimonSoft
There seems to be one more thing: __DIR__. One might imagine this being useful when implementing a library that defines a macro to include its files by using a shorter name than a complete relative path. include seems to use the path of the file where the macro was used as a search origin, so for such macros being able to access something not only “relative to whoever invoked me” but “relative to my own file” seems to be a valid use case.
Post 05 Apr 2022, 13:48
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 522
Location: Ukraine
Overclick
What if preload it to virtual then recombine as you want?..
Post 05 Apr 2022, 14:12
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 1042
Location: Belarus
DimonSoft
Overclick wrote:
What if preload it to virtual then recombine as you want?..

Won’t work: include works at the preprocessor stage while virtual works at the assembler stage, long after the preprocessor is gone.
Post 05 Apr 2022, 15:04
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 598
Location: Russia
macomics
DimonSoft wrote:
Overclick wrote:
What if preload it to virtual then recombine as you want?..

Won’t work: include works at the preprocessor stage while virtual works at the assembler stage, long after the preprocessor is gone.
Even more than that. include works at the stage of loading text and splitting it into lines even before the preprocessor. As fix.
Post 05 Apr 2022, 15:51
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8017
Location: Kraków, Poland
Tomasz Grysztar
macomics wrote:
Even more than that. include works at the stage of loading text and splitting it into lines even before the preprocessor. As fix.
That's a bit misleading, INCLUDE statements can be generated at the time of preprocessing:
Code:
macro include2 filename* { match dir,__DIR__ \{ include dir\#`filename \} }
__DIR__ equ 'c:\asm\fasm\include\'

include2 win32a.inc    

In fact, with a little trickery we can actually include relative to a specific file:
Code:
macro include_anchor filename* { match dir,__DIR__ \{ include dir\#`filename \} }
macro anchor_here { match current,__FILE__ \{ __DIR__ equ current\#'/../' \} }

anchor_here
macro test
{ include_anchor test.inc }    


Last edited by Tomasz Grysztar on 05 Apr 2022, 16:12; edited 1 time in total
Post 05 Apr 2022, 15:59
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 598
Location: Russia
macomics
But the result of even these instructions will be about the same. They will be replaced with a block of text from the file immediately after calculation.

http://flatassembler.net/docs.php?article=manual#2.3.1 wrote:
The whole included file is preprocessed before preprocessing the lines next to the line containing the include directive.
It's better to perceive it that way.

Code:
macro include_anchor filename* { match dir,__DIR__ \{ include dir\#`filename \} }
macro anchor_here { match current,__FILE__ \{ __DIR__ equ current\#'/../' \} }

anchor_here
macro test
{ include_anchor test.inc }        
nice, but didn't work
main.asm wrote:
Code:
macro include_anchor filename* { match dir,__DIR__ \{ include dir\#`filename \} }
macro anchor_here { match current,__FILE__ \{ __DIR__ equ current\#'/../' \} }

include "./src/test.asm"
macro testinc { include_anchor test.inc }    


./src/test.asm wrote:
Code:
anchor_here    


./src/test.inc wrote:
Code:
display "Hello"
string db "Hello!"    


output wrote:
Code:
$ make
env INCLUDE="$HOME/WORK/INCLUDE/FASM/;$INCLUDE" \
fasm -m 102400 ./main.asm
flat assembler  version 1.73.30  (102400 kilobytes memory)
./main.asm [14]:
testinc
./main.asm [7] testinc [0]:
macro testinc { include_anchor test.inc }
./main.asm [3] include_anchor [0]:
macro include_anchor filename* { match dir,__DIR__ \{ include dir\#`filename \} }
./main.asm [3] match [0]:
macro include_anchor filename* { match dir,__DIR__ \{ include dir\#`filename \} }
error: file not found.
make: *** [Makefile:2: default] Error 2    


Last edited by macomics on 05 Apr 2022, 16:33; edited 1 time in total
Post 05 Apr 2022, 16:08
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8017
Location: Kraków, Poland
Tomasz Grysztar
macomics wrote:
But the result of even these instructions will be about the same. They will be replaced with a block of text from the file immediately after calculation.
That applies to the lines that are introduced by INCLUDE. But the INCLUDE itself is processed during standard preprocessing, it's not like FIX. You cannot generate a FIX statement with a macro, but you can generate an INCLUDE.
macomics wrote:
nice, but didn't work
Linux does not allow to abuse ".." in such way. Windows does.
Post 05 Apr 2022, 16:25
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 598
Location: Russia
macomics
Then I'd rather use "env INCLUDE".
Post 05 Apr 2022, 16:57
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 1042
Location: Belarus
DimonSoft
Tomasz Grysztar wrote:
macomics wrote:
nice, but didn't work
Linux does not allow to abuse ".." in such way. Windows does.

I’m not quite sure it’s a good idea to abuse ... It might be a valid thing for folders but I really doubt the filename-related implementation detail survives in future versions of Windows in spite of Microsoft’s effort to ensure backwards compatibility. The Linux case has already been mentioned.
Post 05 Apr 2022, 17:43
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 598
Location: Russia
macomics
Tomasz Grysztar wrote:
Linux does not allow to abuse ".." in such way. Windows does.
Approximately the same thing is described here.
Post 05 Apr 2022, 17:53
View user's profile Send private message 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.