hi revolution, pardon my poor knowledge on ARM. the question
may seem silly. have you ever thought to do it using macros
to opcode the ARM ISA ?
why reworking fasm source code entirely ?
Cheers,

IMO macros would be a vastly inferior solution. I'm not even sure that everything could be done with macros. Coding the DWARF format with source level line numbering and file names would be extremely tricky (and probably impossible) using just macros.

well, ok. i was just wondering about a post-processing stage from an external tool that matches labels/instructions in the source against generated code, in one or several passes. afterall, the tool will find the code already there, eventually relocated/forwarded etc.
it may be executed/activated at run-time or at debug-time. and source should be always included.

What about macros in the ARM source file? It would be a non-trivial task to post process all of the sources again and match to the binary. It would seem to me to be much more sensible to just do it right at the source. Besides, separate tools easily become cumbersome and just as much work (sometimes more work) to write and maintain as the solution I chose.

Why are you asking? Are you considering writing your own assembler for another CPU? It would be good to see another CPU supported.

i am entering the ARM world in these days. it is fascinating. especially the simplest micros, without MMU. i start from some general assumptions now in order to calculate
a learning curve on not well-determined things, for example finding docs/specs on internet.
but i am sure from now i will integrate something of it in my IDE.

now, given the State of Art, i.e. fasm,
i am asking because, relating to another CPU, i dont know yet, i may take advantage of my 64bit "data-packer", because it is a baby in which the only few features are natively 64bit/unicode/datatype/labels, and a stark RPN engine. also, no intellectual "preprocessing" for now.

i was thinking at a middle pluggable layer, that may turn useful on outputting debug-formatted-stuff and for architecture switching.
but i need time to reflect on main matters. anyways, whether impossible or not, i dont know yet, now is the right time to think at its doability.

thank for you help,

btw: i would not be wrong, but there should be some IDEs capable to post process all of the sources again and match to the binary using built in decoders. or something like that.

hopcode are the functions that generate the ELF or other object file formats not suitable? What's the purpose of post processing sources and matching them with the binary?

well,i mixed a couple of things.

the goal with an external tool would be to free the assembler of the complex task
of generating a DWARF. the tool matches source lines against already
generated code, running in a post-processing stage.
this may be not so complex as it seems. the assembler, would result more simple
to be developed, i.e closer to my simple datapacker, that i already have
in development stage.

that task results to be more tricky/complex to be implemented
with macros, as revolution hinted. about macros as an inferior solution
for DWARF, i agree generally with him.
in other case, i.e. opcode generation, macros might be suitable. in both case,
to be sure i should read specs/ISA carefully, and look at some code
assemblable with fasmarm.

the mix comes now.

why developing an external tool to output a DWARF if i can embed a pluggable
layer in the assember capable of that format DWARF and that particular
object format ? because assembling rules and contents changes
acording the ISA. the debug format follows abstractely in some way.

ELF functions that generate formats are ok. what i mean is an
itermediate abstract language, but there's nothing new in this. i think it
pluggable, without entering details. but i wouldnt know actually
how/where exactly implement it.

i was drawing something this early morning, but i couldnt post it.
well, i set it there out if anyone has an idea about it:

something like a command-scripted protocol, where instructions
are in abstract classes. move,load classes etc, according the ISA.

pragma to understand source
emit acordingly

in analogy we use now on intel use32 or use64 given to a monlithical
assembler. in this case instros belong pactically to the same ISA family.
but even this fact doesent make the implementation simpler, imo.

there's no reason to let the datapacker evolve, without having a design
on layers that i require being pluggable.

I would be interested to see your macro solution to generating ARM code. Try starting with just the MOV opcode and see how you feel about it afterwards.

given a roundtrip of this type

1st name) the Cortex-M3 is a low-power processor that implements
2nd name) the ARM architecture v7-M, it is to say
3rd name) A Thumb®-2 Instruction Set Architecture (ISA) subset, consisting of all base
4th name) Thumb-2 instructions, 16-bit and 32-bit, and excluding blocks for media etc.

and the fact that they needed a UAL,
we pick the doc
DDI0403D_arm_architecture_v7m_reference_manual.pdf
also,4 names for one file only !

from there, it maybe doable this way

select Cortex-M3
select T1,T2,T3 encodings for the MOV
select type for the MOV immediate/register/shifted/top
match backward feeded paras on the macro

i need some basics and approx. a couple of coupled months
to encode those stuff

but it's cool !

have you a nutshell/general overview/infolinks for those versions/thumbs etc ?

Even though ARM is RISC at the binary level it does get complicated at the opcode level. I recommend the DDI0100 manual for versions 5 and older. And then the later manuals for v6, v6M, v7M, v7A & R etc. Supporting all those with just macros will be challenging. Good luck.

I think it's a bit against FASM's concept: one input file - one output file. FASM does a very good job generating object files. I think that instead building some complex, external tools you could use GCC tools to get whatever you want

Or at least write an external FASM linker that would link the object file, not the executable binary with no debug information combined with source. But I think that FASM does a good job generating different output files.

Revolution was going to make some project decisions about how control directives between the source code will work. I hope it stays the current way eventually new features will be added.

it's against the natural linear cheaper concept.
one more reason fasm is not a toy.
but the song remains the same. appearingly no solution,
because the object files are formatted to feed the linker, not for
the previous stages (assembler and parser). for this reason we dont
give that format an attribute of "middle layered format".
and fasmarm, if i am not wrong, cannot be actually merged inside fasm,
right ?

thinking,thinking,thinking...
Cheers,