flat assembler - FASMARM v1.43 - Cross assembler for ARM CPUs

Index > Non-x86 architectures > FASMARM v1.43 - Cross assembler for ARM CPUs

Goto page Previous 1, 2, 3 ... 29, 30, 31

Author

Thread

bzt

Joined: 09 Nov 2018
Posts: 43

bzt

revolution wrote:

Are there any programming IDEs for Android?

Yeah sure, it's called vi Smile

revolution wrote:

It wouldn't be a very good platform for code development.

Some of the tablets with a BT keyboard could be useable at some degree. Wouldn't be my first choice though, I give you that.

On @hyphz's question, qemu supports both
"-M raspi2 -kernel kernel7.img" (for AArch32)
"-M raspi3 -kernel kernel8.img" (for AArch64)
these days. The "-cpu" and other arguments no longer needed, and framebuffer works too (at least VC is emulated at mailbox level, not sure about GL; video and image decoding definitely missing, as well as many BCM peripherals).

Cheers,
bzt

22 Dec 2018, 19:12

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17010
Location: In your JS exploiting you and your system

revolution

There are currently no plans to rewrite fasmarm in native ARM code.

So to run fasmarm, or fasm for that matter, on a tablet or phone you will need an 80386 emulator/VM. To run the IDE you will also need a windows VM or have WINE running also.

23 Dec 2018, 17:13

guignol

Joined: 06 Dec 2008
Posts: 666

guignol

and no muscle, i get it

_________________
qiq;

29 Dec 2018, 13:46

TmEE

Joined: 19 Jun 2019
Posts: 3
Location: Estonia

TmEE

Allo !

I have been using FASMARM for STM32 development for a little while and I have found a bug regarding immediate offset handling.

FASMARM allows the more conventional syntax of [Rx+123] instead of [Rx,123] that is standard in ARM and I have been using it instead but I have found out that if you use the offset in hexadecimal (using $) the instruction will not always assemble with correct offset.
LDR R0, [R8+$12] produced offset equivalent of $18 in some tests I was performing.
LDR R0, [R8,$12] gives correct result.

I have converted all my code to use the conventional ARM syntax but it would be nice if this could be looked at and perhaps fixed or maybe opposite and disallowed entirely. I cannot say I'm a big fan of the ARM syntax, especially with 68K background where similar operations use more intuitive representation.

19 Jun 2019, 22:33

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17010
Location: In your JS exploiting you and your system

revolution

Yes, you are right. And it appears to only affect thumb mode long form instructions using high registers.

Code:

ldr     r0,[r8+$12]
thumb
ldr     r0,[r8+$12]
ldr     r0,[r0+$12]
ldr     r0,[r0+$10]

Output:

Code:

00000000: E5980012 V1     ldr   r0,[r8,0x12]
thumb
00000008: F8D8001A 7M     ldr   r0,[r8,0x1A] ;Oops
0000000C: F8D00012 7M     ldr   r0,[r0,0x12]
00000010:     6900 V4T    ldr   r0,[r0,0x10]

It is still another week before I will be back to my dev system. I'll update fasmarm with a fix then.

19 Jun 2019, 22:54

guignol

Joined: 06 Dec 2008
Posts: 666

guignol

revolution wrote:

And it appears to only affect thumb mode long form instructions using high registers.

can you actually pronounce that quick

20 Jun 2019, 03:12

TmEE

Joined: 19 Jun 2019
Posts: 3
Location: Estonia

TmEE

Thänk you for the quick look at the matter, I look forward to any developments ~

EDIT: I am wondering if there's a better way to define interrupt vectors (or other addresses) than to do DW Label+1 ? Lowest bit needs to be set as I found out or the CPU will hard fault. Perhaps there could be dedicated data definition like say DV (define vector) which automatically sets the lowest bit ?

20 Jun 2019, 12:49

TmEE

Joined: 19 Jun 2019
Posts: 3
Location: Estonia

TmEE

Looks like this has fallen into cracks lol (I'm not in actual hurry, I only now remembered to check up on this)

24 Sep 2019, 16:33

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17010
Location: In your JS exploiting you and your system

revolution

Yeah, I thought some time back that it would be a week till I got back to my dev system. But the 737MAX thing has turned into a really big problem. I should refrain from predicting an end time. As it looks now it might be never. Sigh.

For your suggestion of DV (which I only saw now). You can use a macro to do the CPU specific requirements. It isn't part of the instruction set so I think making special assembler directives isn't the proper place to have it.

Code:

macro DV pointer {
  dw pointer + 1
}

24 Sep 2019, 23:24

murder

Joined: 03 Nov 2011
Posts: 10

murder

Is it planned to add support for the ELF64? It`s need for Android programming.

02 Nov 2019, 16:14

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17010
Location: In your JS exploiting you and your system

revolution

murder wrote:

Is it planned to add support for the ELF64?

I hope so. I am anxious to get back to my dev system soon.

02 Nov 2019, 16:20

guignol

Joined: 06 Dec 2008
Posts: 666

guignol

woo-ooh !

02 Nov 2019, 19:33

guignol

Joined: 06 Dec 2008
Posts: 666

guignol

You know, I think Boeing should release all of its software opensource

02 Nov 2019, 20:52

ProMiNick

Joined: 24 Mar 2012
Posts: 443
Location: Russian Federation, Sochi

ProMiNick

revolution, if thou going back to dev system please cut off optimization mov ->unpaired movw (unpaired with movt) - reason relocations respect only movw movt pair.

02 Nov 2019, 23:19

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17010
Location: In your JS exploiting you and your system

revolution

ProMiNick wrote:

revolution, if thou going back to dev system please cut off optimization mov ->unpaired movw (unpaired with movt) - reason relocations respect only movw movt pair.

Currently fasmarm doesn't generate relocations. If it did then it would still be up to the programmer to create the movw/movt pair manually. A single mov doesn't generate any relocation, so changing it to movw shouldn't have any affect to relocations. Unless I misunderstand what you are suggesting?

03 Nov 2019, 03:28

MazeGen

Joined: 06 Oct 2003
Posts: 959
Location: Czechoslovakia

MazeGen

revolution wrote:

murder wrote:
Is it planned to add support for the ELF64?
I hope so. I am anxious to get back to my dev system soon.

Wait guys... so this is not supposed to work on Android?

Code:

format ELF64 executable
processor cpu64_v8

entry start

segment readable executable

start:
 mov x0, 1
 adr x1, msg
 mov x2, msg_len
 mov x8, 4
 svc 0

 mov x0, 0
 mov x8, 1
 svc 0

msg DB "hello from arm64", 10
msg_len=$-msg

EDIT: wow, this generates ELF x64 without any errors Smile

23 Nov 2019, 22:13

guignol

Joined: 06 Dec 2008
Posts: 666

guignol

Czechoslovakia, anyone?

24 Nov 2019, 06:08

murder

Joined: 03 Nov 2011
Posts: 10

murder

MazeGen
It will generate x64 ELF. For ARM64 need to be replace e_machine with EM_AARCH64 and e_flags must be equal to 5000000h. Also if you want to use dynamik linking e_type field must be ET_DYN.

01 Dec 2019, 05:59

murder

Joined: 03 Nov 2011
Posts: 10

murder

revolution
If try to compile this code in FASMARM 1.43 - it will be crashed

Code:

if 0<>0
  [a->b] ;if remove brackets FASMARM not crash
end if

FASM 1.73.09 work`s fine

01 Dec 2019, 06:04

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17010
Location: In your JS exploiting you and your system

revolution

murder wrote:

revolution
If try to compile this code in FASMARM 1.43 - it will be crashed
Code:
if 0<>0
  [a->b] ;if remove brackets FASMARM not crash
end if  
    
FASM 1.73.09 work`s fine

Thanks for the report.

I will fix all these problems as soon as I am able.

01 Dec 2019, 09:05

Goto page Previous 1, 2, 3 ... 29, 30, 31

< 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