flat assembler
Message board for the users of flat assembler.

Index > Main > Organizing macros in modules

Author
Thread Post new topic Reply to topic
Chaeremon



Joined: 04 Dec 2013
Posts: 7
Chaeremon
I have so many macros, want to organize them in a modular way. What I found useful is the label:: thing in combination with virtual (somewhere in the man pages).
But the macro name appears to have its own rules (other than rules for labels). If the below can be made more fasm-like I'd love to see suggestions for modular organization.
Code:
;
section '.NaVM' code executable readable
 virtual at $$
  sym:: ; define a module's parent
 end virtual
;
 virtual sym ; tell which module
; here, without sym. before .test, fasm barks below
  macro sym.test arg { align arg } ; whatever you want in body
 end virtual
;
; now, without sym. in the above macro name, fasm barks error: illegal instruction
 sym.test 2
;
    
Post 22 Feb 2022, 06:26
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 601
Location: Russia
macomics
For macros, use "match"
Post 22 Feb 2022, 06:43
View user's profile Send private message Reply with quote
Chaeremon



Joined: 04 Dec 2013
Posts: 7
Chaeremon
The virtual sym thing can come from any file (bringing additions to modules) in any order.
Post 22 Feb 2022, 07:00
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 601
Location: Russia
macomics
virtual declares a separate addressing space. And, in my opinion, at the assembler level. What happens after the preprocessor at which macros are processed. Moreover, neither macros nor structures affect the current address space until they are used (not declared). Example of using virtual in combination with structures (read macros):
Code:
struc GDTR offset, length { local .temp
 . dp .temp and 0x00FFFFFF
 virtual at .
  .length dw length - 1
  .offset dd offset, 0
  load .temp qword from .
 end virtual }

newGDTR GDTR GDT, GDT_end - GDT
GDT: ... ; descriptors
GDT_end:

mov cx, [newGDTR.length]
mov esi, [newGDTT.offset]
lgdt [newGDTR]    
Post 22 Feb 2022, 07:06
View user's profile Send private message Reply with quote
Chaeremon



Joined: 04 Dec 2013
Posts: 7
Chaeremon
... what part is module declaration and what part is model member (element) use? And how's that pulled together from arbitrary .inc files ...

I'm not going to respond to address space, this is left to macro user.
Post 22 Feb 2022, 07:56
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 601
Location: Russia
macomics
But macros are not declared as binary data and are processed at the source code level. And virtual blocks work with the address space of the output file. They isolate part of this space and prevent its inclusion in the final output file. I.e., the name of the declared macro is not mapped to the address and is processed at the text level every time it is used in the source code location where it was used. If you want to exclude some unused macros from the source text, then you should use something like this:
Code:
 ; main.asm
define ALLMYMACRO used
define MYMACRO0 unused
define MYMACRO1 used
match =used ALLMYMACRO { include "allmymacro.inc" }    

Code:
; allmymacro.inc
match =used,MYMACRO0 { include "mymacro0.inc" } ; excluded
match =used,MYMACRO1 { include "mymacro1.inc" } ; included    

Code:
 ; mymacro0.inc
macro mymacro0 ...    

Code:
 ; mymacro1.inc
macro mymacro1 ...    

You can of course do it this way
Code:
 ; allmymacro.inc
match =used,MYMACRO0 { macro mymacro0 ... }
macth =used,MYMACRO1 { macro mymacro1 ... }    
But in this case, the source code of the program will not be truncated. Although unused macros will be excluded.


Last edited by macomics on 22 Feb 2022, 08:34; edited 1 time in total
Post 22 Feb 2022, 08:13
View user's profile Send private message Reply with quote
Chaeremon



Joined: 04 Dec 2013
Posts: 7
Chaeremon
Do you agree that match is useless because,
macomics wrote:
unused macros will be excluded.


What I wrote above: 1. declare a module in some wanted (arbitrary) environment; 2. append (arbitrary) things to the module if wanted/needed, maybe .inc files or your own addition. 3. use from the named module what you want.

_________________
An overabundance of Smalltalk platforms doesn't exist, just start writing the next core in flatassembler.
Post 22 Feb 2022, 08:24
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 601
Location: Russia
macomics
Chaeremon wrote:
What I wrote above: 1. declare a module in some wanted (arbitrary) environment; 2. append (arbitrary) things to the module if wanted/needed, maybe .inc files or your own addition. 3. use from the named module what you want.
That's what I'm trying to tell you. 1) the virtual action does not apply to the definition of macros and structures; 2) Labels of the type sym:: can be used only in 3 directives: virtual, load and store; 3) you define the macro sym.test in your example, but if you write the definition of the macro .test simultaneously with sym.test, then they will quietly coexist because these are two different macro names. The fasm preprocessor looks for the macro name exactly matching and does not concatenate it with the global label name.
Code:
format binary

Test1:

macro .Point X*, Y*, Z* { dq X, Y, Z }
macro Test1.Point X, Y { dd X, Y }

Test1.Point 0, 0
.Point 1, 2, 3
;flat assembler  version 1.73.29  (16384 kilobytes memory)
;1 passes, 0.3 seconds, 32 bytes.    
Post 22 Feb 2022, 08:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18757
Location: In your JS exploiting you and your system
revolution
Yeah, the two stage thing needs to be considered correctly.

Stage 1. All macros (rept, irp, struc, ...) and label names (but not their values) are defined. No instructions or virtual blocks are processed, they are completely ignored.

Stage 2: Assemble instructions and virtual blocks. All macros blocks are completely ignored, the macros have already done their part.

[edit] Changed "pass" to "stage"


Last edited by revolution on 22 Feb 2022, 15:29; edited 3 times in total
Post 22 Feb 2022, 09:16
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: 18757
Location: In your JS exploiting you and your system
revolution
For example this file will assemble without error:
Code:
virtual at 0
 db 1
 macro foo {
  db 2
  end virtual
}
end virtual

virtual at 0
foo    
macro foo is defined in stage 1 and has no effect on the first virtual block in stage 2.

[edit] Changed "pass" to "stage"


Last edited by revolution on 22 Feb 2022, 15:30; edited 1 time in total
Post 22 Feb 2022, 09:19
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 601
Location: Russia
macomics
revolution wrote:
macro foo is defined in pass 1 and has no effect on the first virtual block in pass 2.
And he also wants the names of macros to be connected with special labels defining different address spaces ( sym:: ).
Post 22 Feb 2022, 09:31
View user's profile Send private message Reply with quote
Chaeremon



Joined: 04 Dec 2013
Posts: 7
Chaeremon
Try (in my example) without the sym. in the virtual sym thing. So the talk can be about that thing.

P.S. I thought about your match thing, macros invoke each other, can even pass macros as argument. No match thing can know that.
Post 22 Feb 2022, 09:48
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8022
Location: Kraków, Poland
Tomasz Grysztar
Chaeremon wrote:
But the macro name appears to have its own rules (other than rules for labels).
That's because fasm 1 has a separate preprocessing stage, with its own language and rules. The macros (and also symbolic definitions like EQU) are defined and unrolled by preprocessor, and finished preprocessed text then becomes an input to the actual assembler. And it is only the assembler that recognizes things like labels, virtual blocks, etc.

Chaeremon wrote:
If the below can be made more fasm-like I'd love to see suggestions for modular organization.
Code:
;
section '.NaVM' code executable readable
 virtual at $$
  sym:: ; define a module's parent
 end virtual
;
 virtual sym ; tell which module
; here, without sym. before .test, fasm barks below
  macro sym.test arg { align arg } ; whatever you want in body
 end virtual
;
; now, without sym. in the above macro name, fasm barks error: illegal instruction
 sym.test 2
;
    
This is what namespaces are supposed to solve, and it is one of the landmark features that distinguishes fasmg from fasm 1, combined with the fact that fasmg has a unified language (the preprocessor is not a separate stage as in case of fasm).

I altered your sample to show how you'd do it with fasmg:
Code:
section '.NaVM' code executable readable

 sym: ; define a module's parent

 namespace sym ; tell which module to enter
   macro test arg
     align arg
   end macro
 end namespace

 sym.test 2    


That being said, you could perhaps make a simplified framework for handling modules with fasm 1, doing something like this:
Code:
macro module name { define __MODULE__ name }
macro mmacro decl& { local d
                     define d decl
                     match module, __MODULE__ \{ match name rest, d \\{
                                                 macro name args& \\\{ module\#.\\#name args \\\}
                                                 macro module\#.\\#name rest \\} \} }


module sym

   mmacro test arg { align arg }

sym.test 2    


Last edited by Tomasz Grysztar on 22 Feb 2022, 10:19; edited 1 time in total
Post 22 Feb 2022, 09:55
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: 18757
Location: In your JS exploiting you and your system
revolution
macomics wrote:
revolution wrote:
macro foo is defined in pass 1 and has no effect on the first virtual block in pass 2.
And he also wants the names of macros to be connected with special labels defining different address spaces ( sym:: ).
Chaeremon wrote:
Try (in my example) without the sym. in the virtual sym thing. So the talk can be about that thing
This is related to the two stages.

Virtual blocks are entirely ignored during the first stage. So you can't have macro names be part of the virtual block in any way. The code simply doesn't exist in the assembler. Macro names are in a separate part of the assembler memory from program labels memory. They never mix together.

[edit] Changed "pass" to "stage"


Last edited by revolution on 22 Feb 2022, 15:31; edited 1 time in total
Post 22 Feb 2022, 09:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8022
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
This is related to the two passes.
I prefer to call them "stages", to avoid having them confused with the assembly passes.
Post 22 Feb 2022, 10:03
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 601
Location: Russia
macomics
To make it clearer what you want - let's give examples that do not consist of separate pieces.
Post 22 Feb 2022, 10:27
View user's profile Send private message Reply with quote
Chaeremon



Joined: 04 Dec 2013
Posts: 7
Chaeremon
Quote:

namespaces are supposed to solve

Wasn't aware they can reference macros like you show, so I'm going to make modules with their own namespace.

Thank you Tomasz.
Post 22 Feb 2022, 10:41
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 601
Location: Russia
macomics
He just needs to add a prefix to the macro name. Maybe I didn't understand something. I'll ask you directly. Where are the modules here?
Post 22 Feb 2022, 14:59
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.