flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Non-x86 architectures > FASMARM v1.41 - Cross assembler for ARM CPUs

Goto page Previous  1, 2, 3 ... , 27, 28, 29  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14784
Location: Not in LAX

Andrew Martin wrote:
Yes. Now (with 0x10) almost all OK Smile

Can you please expand upon "almost". Looking through previous posts I can't find anything pending so perhaps I overlooked something.
Post 06 Dec 2015, 00:48
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk
Line number program:


Code:
 Special opcode 26advance Address by 4 to 0x130 and Line by 2 to 168
  Advance PC by 536870608 to 0x20000000
  Special opcode 2advance Address by 0 to 0x20000000 and Line by 2 to 170
  Advance PC by 4 to 0x20000004
  Extended opcode 1End of Sequence



Address 0x20000000 is in section ".data", which have only WRITE|ALLOCATE access, but no EXECUTE access.
Maybe it does not matter.
Post 06 Dec 2015, 12:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14784
Location: Not in LAX
I haven't made it look at the section attributes when defining the line numbers. I didn't see anywhere in the DWARF spec that talks about only numbering executable code, perhaps it is simply assumed or implied.

BTW: I also number the "section ..." lines since they also produce output data. But I don't number the "format ..." line.
Post 06 Dec 2015, 15:02
View user's profile Send private message Visit poster's website Reply with quote
Andrew Martin



Joined: 30 Sep 2015
Posts: 29
Location: 404, Lugansk
There is no sense in the line numbering in data sections. It is necessary to link PC with line numbers in source code for step-by-step debug. In non-executable sections, address value in LNP is not the same as that PC.
Besides, in that executable, size of section ".data" = 0.
Post 06 Dec 2015, 16:02
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14784
Location: Not in LAX
v1.38
Version 1.38 now available:

Quote:
v1.38 2016-Apr-11
  • Fixed more bugs with elf dwarf format file corruption
  • Fixed a bug with "section ... at 0" not updating PC to 0
  • Fixed an encoding bug with VMULL.P8
  • Add 32-bit v8 instructions

Note that this version assembles against fasm v1.71.51
Post 11 Apr 2016, 01:05
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: 14784
Location: Not in LAX
v1.39
Version 1.39 now available:

Quote:
v1.39 2016-May-01
  • Add 64-bit v8 instructions
  • Add simple expression evaluation inside address fields, e.g. "ldr x1,[x2-4]" and/or "ldr x1,[x2,-4]"
  • Add processing for lists of instruction classes to PROCESSOR and COPROCESSOR directives
  • Add 64-bit SemiHosting example program

Note that this version assembles against fasm v1.71.51

For those interested in the 64-bit v8 instructions, ARM have a freely available document [ARM Cortex-A Series Programmer's Guide for ARMv8-A] with some useful information. [PDF is here]
Post 01 May 2016, 03:28
View user's profile Send private message Visit poster's website Reply with quote
krom



Joined: 05 Jun 2012
Posts: 13
Hi revolution,

I just got the newest FASMARM with aarch64 support, but when I tried using the new instructions I get an error:
"Error: Requires CPU64 capability V8, use direct"

I am using both CODE64 & PROCESSOR CPU64_V8, I tried swapping the order of them, outputing to binary format.
Also I tried compiling your EXAMPLES\ARM64\SemiHosting.asm file, but it gives the same error as above.

I am using the windows FASMWARM.EXE binary from FASMARM_full.ZIP on Windows 10.

Hope this helps, also thanks for the free ARM v8 pdf doc you linked.
Post 12 May 2016, 15:50
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: 14784
Location: Not in LAX
Cannot reproduce:

Code:
flat assembler for ARM  version 1.39 (built on fasm 1.71.51)  (3145344 kilobytes memory)
2 passes215 bytes.

But I am using Windows 7 and XP, however I don't see how Windows 10 could get this wrong.

Your error message is truncated also, the full message should be "Requires CPU64 capability V8, use directive "processor" to select".
Post 13 May 2016, 00:01
View user's profile Send private message Visit poster's website Reply with quote
krom



Joined: 05 Jun 2012
Posts: 13
Hi revolution, thanks for the quick response.

revolution wrote:
Cannot reproduce

I just tried a fresh install, in a new directory...
I used the IDE FASMWARM.EXE once again to navigate to the EXAMPLES\ARM64\SemiHosting.asm file, & pressed the Run/Compile button & I got the same truncated error message.

I then tried copying the SemiHosting.asm file into the root directory, where the command line FASMARM.EXE is, & used that to correctly compile the file, so it seems to be a problem with the IDE FASMWARM on Windows 10.


revolution wrote:
Your error message is truncated also, the full message should be "Requires CPU64 capability V8, use directive "processor" to select".

Yes I had a feeling this message was truncated, but this is how messages show inside the IDE FASMWARM.EXE, fixed width message window, it's been like this since I started using IDE FASMWARM on Windows XP for me...

As I can use the command line FASMARM to compile aarch64 now I am very happy, but would love for the IDE to work as it really speeds up my workflow.
Anyway I hope this helps, sorry about the weirdness of this IDE bug in windows 10...

P.S I also made sure to check I do not have any other FASMARM.EXE files on my hard-disk, so it is not picking up another executable from anywhere else...


Last edited by krom on 13 May 2016, 10:27; edited 1 time in total
Post 13 May 2016, 09:41
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: 14784
Location: Not in LAX
krom: Thank you for the report. I will look into the IDE problem.
Post 13 May 2016, 10:18
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: 14784
Location: Not in LAX
v1.40
Version 1.40 now available:

Quote:
v1.40 2016-May-14
  • Fix a bug with unexpected size checks in 64-bit code for immediate values not used for addressing
  • Fix a bug with MOVK not respecting the shift amount when the immediate is zero
  • Change the IDE error summary dialog to show the full error message

Note that this version assembles against fasm v1.71.52
Post 14 May 2016, 09:19
View user's profile Send private message Visit poster's website Reply with quote
krom



Joined: 05 Jun 2012
Posts: 13
Thanks revolution this new FASMARM v1.40 fixes all the IDE compilation problems I was having.
I'll have a lot of fun with this, great work =D
Post 14 May 2016, 11:08
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: 14784
Location: Not in LAX
Relocations with ELF and ELF64
Relocations with ELF and ELF64

Looking for suggestions on how to specify relocation information for ELF and ELF64 output formats.

Compared to x86 output there are a number of differences related to relocations. For simple things like a memory location using DW or DD there is no problem, but some instruction sequences require very specific information to be forwarded to the linker to correctly resolve the final address.

The GNU assembler, AS, simply uses a variant of the link info internal name to specify the required relocation information. For example for 64-bit code we have this for a 48-bit address:

Code:
        movz    x1,:abs_g2:foo
        movk    x1,:abs_g1_nc:foo
        movk    x1,:abs_g0_nc:foo

Or for a PC relative address:

Code:
        adrp    x1,:pg_hi21:foo
        add     x1,x1,:lo12:foo

Or:

Code:
        adrp    x1,:pg_hi21:foo
        ldr     x1,[x1,:lo12:foo]

And for 32-bit code we would do this:

Code:
        movw    r0,:lower16:foo
        movt    r0,:upper16:foo

And there appears to be no support in AS for any of the thumb or ARM 8-bit partial address building relocations.

For fasmarm I didn't want to start using such specific linker internal names because they are unintuitive and hard to remember, and I especially wanted to avoid the usage of the colons (:) and underscores (_) because they are tedious to type.

My current thinking could be something like this:

64-bit absolute:

Code:
        movz    x1,quarter3 foo ;no overflow check needed for 64-bit
        movk    x1,quarter2 foo ;no overflow check
        movk    x1,quarter1 foo ;no overflow check
        movk    x1,quarter0 foo ;no overflow check

48-bit absolute:

Code:
        movz    x1,quarter2 foo ;overflow check
        movk    x1,quarter1 foo ;no overflow check
        movk    x1,quarter0 foo ;no overflow check

32-bit absolute:

Code:
        movz    x1,quarter1 foo ;overflow check
        movk    x1,quarter0 foo ;no overflow check

16-bit absolute:

Code:
        movz    x1,quarter0 foo ;overflow check

64-bit relative:

Code:
        adrp    x1,foo                  ;overflow check
        add     x1,x1,lower12 foo       ;no overflow check

In ARM mode 32-bit absolute:

Code:
        movw    r1,half1 foo
        movt    r1,half0 foo

ARM 32-bit mode PC relative relocations: because of the ability to use either one, two, or three instructions to build an address we thus have three possible situations:

Using a single instruction to get a PC relative address:

Code:
        adr     r1,foo          ;automatic overflow check

Using two instructions to get a PC relative address:

Code:
        adr     r1,half1 foo    ;no overflow check
        add     r1,half0 foo    ;overflow check

Using three instructions to get a PC relative address:

Code:
        adr     r1,third2 foo   ;no overflow check
        add     r1,third1 foo   ;no overflow check
        add     r1,third0 foo   ;overflow check

We have to perform the overflow check on the last ADD instruction (the opposite for the MOVZ above) and to build the address from top to bottom to comply with the linker's address building logic. The final ADD can be replaced with LDC, or any of the LDR variants. There is no availability of quarter* here, the linker tries to build all addresses with no more than three instructions. It is worth noting here that even though half* and third* might imply differently the actual size of the bitfield is always 8-bits.

The usage of quarter* can be used in thumb-16 code to produce the thumb specific absolute addresses:

Code:
        add/mov r1,quarter3 foo ;overflow check
        add/mov r1,quarter2 foo ;no overflow check
        add/mov r1,quarter1 foo ;no overflow check
        add/mov r1,quarter0 foo ;no overflow check

However this usage cannot be used without intervening code to shift in the bits to the correct position, e.g. using LSL, because the selected 8-bit value is always added/moved into the lowest 8 bits of the register because there is no thumb-16 instruction available to mov/add an immediate value into anywhere but the lowest 8 bits of a register.
Post 24 May 2016, 10:48
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 875
revolution
Did you have a look at the actual specifications? Base spec., ARM supplement, ARMv8 supplement . These define the r_info field and possible values for the ELF32_R_TYPE and ELF64_R_TYPE subfields, which seem to cover all the possible relocation requirements.

_________________
Faith is a superposition of knowledge and fallacy
Post 24 May 2016, 13:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14784
Location: Not in LAX
Yes of course, but how to represent them in assembly code? Do you think I should use the same as AS? Or something else?
Post 24 May 2016, 13:24
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 875
revolution
Oh, then it seems, I misunderstood the question. It's not about forwarding the information to the linker. It's about telling the translator what kind of relocation one needs. I think this information should not be explicitly specified, but rather derived from the expressions applied to the corresponding relocatable label. E.g., when you do movw r0,foo and $FFFF then the result of the expression foo and $FFFF still keeps the relocatability property. I guess you need significant improvements to the expression calculator though, but that's the correct way to do that.

_________________
Faith is a superposition of knowledge and fallacy
Post 24 May 2016, 13:34
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14784
Location: Not in LAX
The problem is that the programmer needs to tell the assembler how many instructions to generate. Do you know that all of your addresses are less than <some number> of bits? If so then you might be able to always use only two instructions to get your address. And then you have to tell the assembler (and subsequently the linker) to compute addresses with a particular limit and error if something goes outside that range.

Basically there is no way for the assembler to know the full intent unless you tell it. Does "ADD r1,r1,my_address" mean you want the second, or the third, set of significant bits encoded?
Post 24 May 2016, 13:41
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: 14784
Location: Not in LAX
BTW: It is not possible to say "foo and 0xffff" for a relocatable label. That value is unknown as assembly time. And for things like "ADR r1,foo", which bits would you mask? 0xff0000? 0xff00? 0x3fc000? There are a number of possibilities and the values change depending upon the actual address at link time.
Post 24 May 2016, 13:44
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 875
revolution

Quote:
And then you have to tell the assembler (and subsequently the linker)


If I understand you correctly, the linker has nothing to do with the decision. It just evaluates the r_info field: the decision how to construct the field (or a multiple of them) has already been made by the translator and/or programmer.

Quote:
Does "ADD r1,r1,my_address" mean you want the second, or the third, set of significant bits encoded?


add r1,r1,my_address means all of the bits of my_address must be preserved, which is not encodeable in general for a relocatable label. What you can do is to remove the relocatability property from some bits by applying an appropriate expression to the address.

Quote:
BTW: It is not possible to say "foo and 0xffff" for a relocatable label. That value is unknown as assembly time.


Sure it's not known. That's why we have fixups. But the relocatable labels can still be calculated with. Current fasm's expression calculator can do a limited subset of calculations, and you need to extend it to be able to calculate with partially relocatable values. That means allowing for bitwise operators as well.

Quote:
And for things like "ADR r1,foo", which bits would you mask? 0xff0000? 0xff00? 0x3fc000?


I guess it depends on how many instructions you use to encode the address. It's up to the programmer and the constraints the programmer expects for the address to satisfy.

Quote:
the values change depending upon the actual address at link time


In many cases upon the actual address at load or even runtime actually. But it doesn't prevent you from calculating with the relocatable values, which is what fasm already does by allowing for addition and subtraction, and with registers even multiplication:

Code:
dd foo+0x100+ebx*3-(bar-foo+ebx-0x10)*2-ebx


This will perfectly compile even though you don't know the value of ebx and the relocatable labels foo and bar at runtime, right?

_________________
Faith is a superposition of knowledge and fallacy
Post 24 May 2016, 14:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14784
Location: Not in LAX
Hmm, the linker has a limited set of things it can do. For example we cannot instruct it to use a fixed set of bits of our choosing for ARM32 ADR/ADD. It uses "smart" algorithms to create the address with value dependant bitmasks. So the assembler has to work within those constraints. So, no, we can't actually pre-compute anything. We only have the option to tell the linker that a particular instruction needs a set of bits that come from a sequence the linker decides based upon the value only it knows. The best the assembler can do is tell the linker a particular instruction is the first, or subsequent, instruction, in a sequence. And the sequence doesn't even have to be in order, the linker just accepts it as given one instruction at a time without any notion of connecting it to another instruction either before or after. That allows us some flexibility so we could use the final stage values multiple times from a pre-loaded register and the linker doesn't care. Also note that the linker can change ADD to SUB and the assembler has no control over that.

Since using fixed bitmasks cannot work, I think there needs to be another solution. So, what is your opinion? Is the AS way the way to go (with its colons and underscores)? Or perhaps what I suggested above?
Post 24 May 2016, 14:34
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:  
Goto page Previous  1, 2, 3 ... , 27, 28, 29  Next

< 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.