flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > Questions to Tomasz: to make includes bitness independent?

Author
Thread Post new topic Reply to topic
ProMiNick



Joined: 24 Mar 2012
Posts: 802
Location: Russian Federation, Sochi
ProMiNick 07 May 2018, 08:41
Hello,
Will it be good to make includes bitness independent(or CPU independent)?

so import macros for win could look like (on fasmg syntax example):
Code:
macro library? definitions&
        PE.Imports:
        iterate <name,string>, definitions
              if ~ name.redundant
                      dd RVA name.lookup,0,0,RVA name.str,RVA name.address
              end if
              name.referred = 1
        end iterate
        dd 0,0,0,0,0
        iterate <name,string>, definitions
              if ~ name.redundant
                      name.str db string,0
                               align 2
              end if
        end iterate
end macro

macro import? name,definitions&
        align ?
        if defined name.referred
                name.lookup:
                iterate <label,string>, definitions
                        if used label
                                if string eqtype ''
                                        integer RVA name.label
                                else
                                        integer 1 shl (x86.mode-1) + string ; or "define genreg.signbit 1 shl (x86.mode-1)" somewhere, and use "integer genreg.signbit + string"
                                end if
                        end if
                end iterate
                if $ > name.lookup
                        name.redundant = 0
                        integer 0
                else
                        name.redundant = 1
                end if
                name.address:
                iterate <label,string>, definitions
                        if used label
                                if string eqtype ''
                                        label integer RVA name.label
                                else
                                        label integer 1 shl (x86.mode-1) + string
                                end if
                        end if
                end iterate
                if ~ name.redundant
                        integer 0
                end if
                iterate <label,string>, definitions
                        if used label & string eqtype ''
                                name.label dw 0
                                           db string,0
                                           align 2
                        end if
                end iterate
        end if
end macro    

I used integer here it should be something like dbx (x86.mode shr 3). in fasm1 same things can be done throw integer fix dd|dq. Word "integer" is not best name for data defenitions, something smaller starting with "d" would be better.

for procs macros something like (on fasm1 syntax example):
x86.Settings.StackTopRegister equ esp|rsp
x86.Settings.StackFrameRegister equ ebp|rbp
x86.Settings.StackAlignment equ x86.Settings.GenRegSz|x86.Settings.mmxRegSz
Code:
macro proc [args]
 { common
    match name params, args>
    \{ define@proc name,<params \} }

prologue@proc equ prologuedef

macro prologuedef procname,flag,parmbytes,localbytes,reglist
 { local loc,fill,counter
   loc = (localbytes+x86.Settings.StackAlignment) and (not x86.Settings.StackAlignment)
   parmbase@proc equ x86.Settings.StackFrameRegister+16
   localbase@proc equ x86.Settings.StackFrameRegister-loc
   push x86.Settings.StackFrameRegister
   mov x86.Settings.StackFrameRegister,x86.Settings.StackTopRegister 
   if loc+fill
    sub x86.Settings.StackTopRegister ,loc+fill
   end if
   counter = 0
   irps reg, reglist \{ push reg
                        counter = counter+1 \}
   fill = (x86.Settings.StackAlignment-x86.Settings.GenRegSz)*(counter and 1) }

epilogue@proc equ epiloguedef

macro epiloguedef procname,flag,parmbytes,localbytes,reglist
 { irps reg, reglist \{ reverse pop reg \}
   leave
   retn }
...    


Or such space economy is to grredy for compilation time?

Question 2: Are Thou planning to backport "macro ?"? Fasm1 is more faster than fasmg and less memory greedy, so for x86 assembly (exept macos) it is more preferable. But in short size projects fasmg preferable because it is more featured and compilation time penalty is unvaluedly small. I like to play(to code) in fasm1 as in fasmg, they both are perfect instruments. So I willing they both evalutioned, not only fasmg.

Question 3: (fasmg relative) Will it be good if in core will be injected "macro CPU" like "macro format" done? with most common settings of all CPUs: endianness, bytesize (in bits), wordsize (in bits),stacktopregister,stackframeregister,instructionpointerregister,devicesmappedtomemoryorviaports,generalregistercount,generalregistersize,availablememoryrange,specialmemoryregions(start,end,characteristic), CPUstates, isinstructionorderstrait (can some fast instruction be finished before finishing of previous slower one). So macros for opcodesets and for specific to CPU OSes can be altered throw these CPU dependant values and its became more standartized. And than macros may becоme more crossCPU.

_________________
I don`t like to refer by "you" to one person.
My soul requires acronim "thou" instead.
Post 07 May 2018, 08:41
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 07 May 2018, 13:11
ProMiNick wrote:
Will it be good to make includes bitness independent(or CPU independent)?
The formatter macro package are in general CPU independent (though for architectures other than x86 there are no relocation generators currently defined), this includes PE.INC. If I included some macros for generating "import" sections in PE.INC they way I did it for resources, it would then be bitness-independent too. This might be a good idea, in fact - there could be some low-level import section generators like there are for resources, and then customized syntax on top of it (like fasm1-compatible one) could be added with additional includes that would call these basic macros.

As for the proc macros, it is doable but is it really worth it? Perhaps if you were making some source that could be assembled to different architectures, but then you'd need to prepare lots of custom macros for your project anyway.

ProMiNick wrote:
Question 2: Are Thou planning to backport "macro ?"?
I was thinking about it. The one problem I see is that "?" in fasm 1 is a valid symbol name, so allowing "macro ?" like fasmg would break some backward compatibility if you happened to use macro with such name in older projects. On the other hand, parser (not preprocessor) already treats such name specially, since it is used in syntax like "db ?".

ProMiNick wrote:
Fasm1 is more faster than fasmg and less memory greedy, so for x86 assembly (exept macos) it is more preferable.
The preprocessor of fasm 1 is actually much more memory greedy than fasmg. If you tried to define x86 instructions in form of macros for fasm 1 and then compare memory usage with the ones for fasmg, you should see a much larger usage in case of fasm 1 - because the preprocessor of fasm 1 creates the actual complete source text with expanded macro and keeps this text in memory.
However you probably do mean comparing the built-in instruction encoder of fasm 1 with the macro implementation of fasmg, then obviously the latter is going to use more resources. Perhaps something like an actual fasm 2 is really what you're looking for. After all, when comparing the engine itself fasmg can be in fact less resource-hungry.


ProMiNick wrote:
Question 3: (fasmg relative) Will it be good if in core will be injected "macro CPU" like "macro format" done?
You can define such macro yourself, this is perhaps even a motto in case of fasmg. The FORMAT was added internally only because I wanted to have fasm1-compatible "FORMAT BINARY AS ext" so I had to make this a pre-defined symbol. For any symbol that is not pre-defined you can create analogous functionality purely with macros.
Post 07 May 2018, 13:11
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 07 May 2018, 18:36
I have just realized that there is an additional problem with "macro ?". In fasm 1 PURGE works a bit differently - a macro is not able to use it to remove its own definition, as in fasmg. In fasm 1 PURGE removes the previous definition of a macro when used from inside of it.

This behavior would need to be changed either for "macro ?" only (an unsatisfactory break of symmetry) or for all macros, which would be breaking backward-compatibility again.
Post 07 May 2018, 18:36
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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.