flat assembler
Message board for the users of flat assembler.

flat assembler > Non-x86 architectures > fasmarm relocations and ARM instructions queries

Author
Thread Post new topic Reply to topic
ProMiNick



Joined: 24 Mar 2012
Posts: 354
Location: Russian Federation, Sochi
Hello, revolution.

Can fasmarm produce executables in common case (with arm specific relocations)?
why mov replaced with movw (is movw clears higher part???, movt stays lower part untouched)
is any source where described all instructions with clear description of what they affect (like movw above, is it clears high part or not), CPU dependent restrictions. and so that all instructions would be in one place but not as manual to one specific CPU with only instruction supported by this CPU.

_________________
I don`t like to refer by "you" to one person.
My soul requires acronim "thou" instead.
Post 01 Apr 2019, 09:19
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16733
Location: In your JS exploiting you and your system
fasmarm doesn't produce any relocations in the currently supported formats.

movw is for immediate constants and allows the full 16-bit lower half to be defined and the upper half is cleared. movt only sets only the upper half, leaving the lower half unchanged. This behaviour is described in the ARM manuals. I recommend you download them.

I have not reproduced the ARM instruction documentation in any format. But there are other websites that have "more friendly" descriptions of the instruction operations.

I have links to the official ARM documents on the fasmarm webpage. Other sources may be incorrect, out of date, or wrong, so beware when obtaining information from other places.

IME the ARM documents are quite tricky parse to extract the CPU dependant information. But it is still important to take note of it as there are many variants out there. One can choose to use the default mode of simply allowing all instruction variants, but I don't recommend it unless you are really confident that you will never accidentally have a longer branch than is supported, or a similar type of encoding restriction. The assembler can monitor that for you if you let it. That is it's job, to show encoding errors that would otherwise be really tedious and tricky to control manually.
Post 01 Apr 2019, 10:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7318
Location: Kraków, Poland
revolution wrote:
fasmarm doesn't produce any relocations in the currently supported formats.
Interesting, this might be another good reason to work on "fasmgARM" macros...
Post 01 Apr 2019, 10:10
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: 16733
Location: In your JS exploiting you and your system
Tomasz Grysztar wrote:
revolution wrote:
fasmarm doesn't produce any relocations in the currently supported formats.
Interesting, this might be another good reason to work on "fasmgARM" macros...
Perhaps if you make it faster. My measurements for fasmg vs fasm are ~160 times slower on the sources I tested. fasmg was taking almost an hour to finish vs 20 seconds for fasm.
Post 01 Apr 2019, 10:14
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7318
Location: Kraków, Poland
revolution wrote:
Perhaps if you make it faster. My measurements for fasmg vs fasm are ~160 times slower on the sources I tested. fasmg was taking almost an hour to finish vs 20 seconds for fasm.
Was it on some x86 sources? These macros are overly complex.
Post 01 Apr 2019, 10:32
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: 16733
Location: In your JS exploiting you and your system
That was x86 code from our production sources. I would be very embarrassing to send something to the clients that takes an hour to build and requires many external support .inc files to get the desired output.
Post 01 Apr 2019, 10:34
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 354
Location: Russian Federation, Sochi
May be we try to encode some arm instructions in fasmg?
all instructions could be classified in arm specification except one - mov, because it is very overloaded:
in simplest case src could be reg or shifted reg.
then depending on arg sequence it can be interpreted as "add" or "sub" when src arg relative to reg,
in case of constant src value tryed to be encoded in instruction as i shl 12 + r shl 8, where
i=%-1
enc=src shl (2*(i and 15)) or src shr (32-(2*(i and 15)))
If value unencodable tryed variant with invertion of src, same testing formula.
Then if value still unencodable tested precedence & presence of specific instruction set via literal pool, if OK, src value compared with $FFFF and encoded if it fit.
if all previous fails to encode src operand it tested for precedence with "=" sign, if no sign - compiler should generate error, otherwise add constant to literal pool.
(that was only checking for arm mode)

instead of preceding to params branch that breacks pipeline we could encode params after call, (call breacks pipeline no matter that it return execution to next instruction), and call itself would be something as
mov lr,pc+xxx
ldmia lr,{lr,pc} - in literal pool we could place call & ret addr and params,
or making
ldmia lr,{r0-r3,lr,pc} to load everithing what call needed if it (4 params) within single instruction.
call address can have local jump elevator to import or direct call (or could be direct call itself).
import elevator is sequence (defined once within distance +/-$FFF where it could be used):
ldr ip,[pc]
ldr pc,[ip]
DTD iat_corresponding_firstchunk
that makes much more places for literal pools.

there are complex with encoding b & bl:
the way how value will be stored in instruction will be depending on mode 26bit or 32bit, ARM or THUMB.

arm could be bigendian and littleendian so for structures is no more enought to define only directive size, things that depend on endianess should be declared as DTD or DTW (dw or dh) but strings or endianess independent parts as db or du with appropriate sequence of ? after them.
Post 01 Apr 2019, 13:35
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16733
Location: In your JS exploiting you and your system
Endianness does not apply to the encoding. The instructions are always little endian regardless of the mode the CPU is using for data access.
Post 01 Apr 2019, 13:40
View user's profile Send private message Visit poster's website Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 354
Location: Russian Federation, Sochi
If we look at import elevator as 12 byte representation of abstract instruction, DTD part will depend on endianess.
Post 01 Apr 2019, 14:31
View user's profile Send private message Send e-mail Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 721
Yall know that I toiled with aarch64+fasmg enough to get a chess program working on my phone? Its not perfect but it is a good start, and the relocations were working to some extent.
https://github.com/tthsqe12/asm/tree/master/arm/include/hello
Post 01 Apr 2019, 21:47
View user's profile Send private message 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-2019, Tomasz Grysztar.

Powered by rwasa.