FASM1 equivalent for __FILE__?

Index > Macroinstructions > FASM1 equivalent for __FILE__?

Author

Thread

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 12 Sep 2021, 13:35

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…

12 Sep 2021, 13:35

Tomasz Grysztar

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

Tomasz Grysztar 12 Sep 2021, 14:58

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

12 Sep 2021, 14:58

Tomasz Grysztar

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

Tomasz Grysztar 13 Sep 2021, 19:21

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

13 Sep 2021, 19:21

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 14 Sep 2021, 17:07

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.

14 Sep 2021, 17:07

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20422
Location: In your JS exploiting you and your system

revolution 14 Sep 2021, 18:04

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

14 Sep 2021, 18:04

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 14 Sep 2021, 18:29

But why would assembler stage line number be better than preprocessor stage one for this case?

14 Sep 2021, 18:29

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20422
Location: In your JS exploiting you and your system

revolution 15 Sep 2021, 00:47

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?

15 Sep 2021, 00:47

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 15 Sep 2021, 21:38

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

15 Sep 2021, 21:38

Tomasz Grysztar

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

Tomasz Grysztar 16 Sep 2021, 11:23

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

16 Sep 2021, 11:23

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 05 Apr 2022, 13:48

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.

05 Apr 2022, 13:48

Overclick

Joined: 11 Jul 2020
Posts: 669
Location: Ukraine

Overclick 05 Apr 2022, 14:12

What if preload it to virtual then recombine as you want?..

05 Apr 2022, 14:12

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 05 Apr 2022, 15:04

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.

05 Apr 2022, 15:04

macomics

Joined: 26 Jan 2021
Posts: 1014
Location: Russia

macomics 05 Apr 2022, 15:51

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.

05 Apr 2022, 15:51

Tomasz Grysztar

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

Tomasz Grysztar 05 Apr 2022, 15:59

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

05 Apr 2022, 15:59

macomics

Joined: 26 Jan 2021
Posts: 1014
Location: Russia

macomics 05 Apr 2022, 16:08

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

05 Apr 2022, 16:08

Tomasz Grysztar

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

Tomasz Grysztar 05 Apr 2022, 16:25

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.

05 Apr 2022, 16:25

macomics

Joined: 26 Jan 2021
Posts: 1014
Location: Russia

macomics 05 Apr 2022, 16:57

Then I'd rather use "env INCLUDE".

05 Apr 2022, 16:57

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 05 Apr 2022, 17:43

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.

05 Apr 2022, 17:43

macomics

Joined: 26 Jan 2021
Posts: 1014
Location: Russia

macomics 05 Apr 2022, 17:53

Tomasz Grysztar wrote:

Linux does not allow to abuse ".." in such way. Windows does.

Approximately the same thing is described here.

05 Apr 2022, 17:53

< 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