flat assembler
Message board for the users of flat assembler.

Index > Non-x86 architectures > About ARM macros and fasm as assembler

Author
Thread Post new topic Reply to topic
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
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,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 10 Oct 2012, 11:54
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: 16935
Location: In your JS exploiting you and your system
revolution
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.
Post 10 Oct 2012, 13:14
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
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.

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 10 Oct 2012, 13:58
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: 16935
Location: In your JS exploiting you and your system
revolution
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.
Post 10 Oct 2012, 14:02
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
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.

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 10 Oct 2012, 15:00
View user's profile Send private message Visit poster's website Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
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?
Post 10 Oct 2012, 19:49
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
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.

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 11 Oct 2012, 13:02
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: 16935
Location: In your JS exploiting you and your system
revolution
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.
Post 11 Oct 2012, 13:52
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
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 Smile

but it's cool !

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

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 11 Oct 2012, 15:29
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: 16935
Location: In your JS exploiting you and your system
revolution
hopcode wrote:
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 Smile

but it's cool !
Even though ARM is RISC at the binary level it does get complicated at the opcode level.
hopcode wrote:
have you a nutshell/general overview/infolinks for those versions/thumbs etc ?
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.
Post 12 Oct 2012, 09:32
View user's profile Send private message Visit poster's website Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
hopcode wrote:

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.


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 Smile

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.

_________________
There's nothing special about it,
It's either there when you're born or not.
Post 12 Oct 2012, 09:40
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
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 ? Wink

thinking,thinking,thinking...
Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 12 Oct 2012, 16:41
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-2020, Tomasz Grysztar.

Powered by rwasa.