flat assembler
Message board for the users of flat assembler.

flat assembler > Heap > Questions to Tomasz: to make includes bitness independent?

Author
Thread Post new topic Reply to topic
ProMiNick



Joined: 24 Mar 2012
Posts: 159
Location: Russian Federation, Sochi
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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6867
Location: Kraków, Poland
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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6867
Location: Kraków, Poland
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 can attach files in this forum
You can download files in this forum


Copyright © 2004-2018, Tomasz Grysztar.

Powered by rwasa.