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
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.
Joined: 16 Jun 2003
Location: Kraków, Poland
Re: Questions to Tomasz: to make includes bitness independent?
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.
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 ?".
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.
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.
Joined: 16 Jun 2003
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.
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