flat assembler
Message board for the users of flat assembler.
Index
> Non-x86 architectures > FASMARM v1.44 - Cross assembler for ARM CPUs Goto page Previous 1, 2, 3 ... 13, 14, 15 ... 31, 32, 33 Next |
Author |
|
g-gabber 09 Jan 2009, 10:24
Hi, thanks for your great work!
Is there possibility to set BIGENDIAN memory ordering??? Thanks in Advance. |
|||
09 Jan 2009, 10:24 |
|
revolution 12 Jan 2009, 07:53
g-gabber wrote: Hi, thanks for your great work! |
|||
12 Jan 2009, 07:53 |
|
orefkov 12 Jan 2009, 11:37
Hi.
I was trying use "format MS COFF" directive, for create small asm routines for MS VC++ project for PocketPC. First, error "High register (R8-R15) not allowed." is appear. After I was add "CODE32" directive and it work. But result file was x86 arch in header, not arm, and MS linker cant link that file with my project. I replace first byte of result file from 4C to C0, and linker can work, and program was builted. But I cant use in asm file import methods (like MessageBoxW). I was try that example: Code: format MS COFF public somFunc CODE32 CODEFP CODEVFP2 CODEV6 section '.text' data code readable writeable executable someFunc: mov r0,0 ;window owner (NULL) add r1,pc,Text-$-8 ;the text add r2,pc,Caption-$-8 ;the caption mov r3,0 ;style (MB_OK) ldr pc,[pc,MessageBoxW-$-8] ;display message and exit Text du 'Hello WinCE world',0 Caption du 'ARM small PE',0 align 4 data import dw RVA core_imports,0,0,RVA core_name,RVA core_imports rw 5 core_imports: MessageBoxW dw 0x8000035A dw 0 core_name db 'COREDLL.DLL',0 align 4 end data But was error: Code:
data import
error: illegal instruction.
|
|||
12 Jan 2009, 11:37 |
|
revolution 12 Jan 2009, 12:07
orefkov: I have not used the COFF format myself so I have left it unchanged in the original fasm code, that is why is still uses the x86 values.
However if you are willing to do some testing and reporting then I am happy to modify it accordingly to suit the ARM format for the object linker. But please note that for a linker I think it would be best not to try to create your own imports (i.e you cant use data imports). This is usually a job for the linker since more than one module will likely want to have some entries in the import table. You should consider using extrn and public for object files. |
|||
12 Jan 2009, 12:07 |
|
orefkov 12 Jan 2009, 12:29
2revolution
I ready to do some testing and reporting. While I was found, when 'format MS COFF' using: 1. switch to thumb mode (I was using code32 directive to workaround). 2. first byte of result .obj file need replace by 0xC0 I understand about create own imports, but can you show small example of using extrn and public? I was try: Code:
...
extrn MessageBoxW
.....
mov pc, MessageBoxW
It compied, linked, but in disasm I was see Code: mov pc, #0 |
|||
12 Jan 2009, 12:29 |
|
revolution 12 Jan 2009, 13:02
orefkov: When I get back to my desk next week I will make some time to see what I can do to do some testing of my own. Until then you might find you need to use ldr and not mov. In ARM opcodes mov cannot generate the proper constants. Plus the format of the MS COFF file needs to be considered so that the proper opcode can be used.
In the example you posted above you can see the format of the imports table that would need to be build by the linker. The use of ldr is the proper way to obtain the address of the import. Perhaps in the meantime you can try just deleting the whole data import section completely and just leave the rest of the file intact but add the extrns and assemble. |
|||
12 Jan 2009, 13:02 |
|
revolution 09 May 2009, 09:56
ARM has no direct instruction to set or clear the carry flag. Generally the usual method of doing this is stated as using the MRS/MSR combination to set the flags as required. But this method, while effective, creates a bad stall in some instantiations, the CPSR register access appears not to be pipelined. So instead I have developed the following two macros to do the equivalent STC/CLC functions.
Code: macro clc {tst r0,0x40000000} macro stc {tst r0,0x80000000} |
|||
09 May 2009, 09:56 |
|
TodWulff 11 Jul 2009, 23:14
Good day!
I have looked through the GUI's options, and I am unable to locate an option to change the endian-ness of the compiler's output. I am using FASMWARM for generating embedded machine code in a higher-level language for an NXP LPC 2xxx. The target is indeed little endian, but the syntax for an asm construct in the host language is big-endian-ish... i.e. The host's construct for ARM asm code of STR R5, [R7] is ASM($E5875000). When I compile the .asm to a .bin, I then edit the .bin with a hex editor and get the machine code that way. It is always output in little endian. It is quite the kludge to have to then hand-code what I am seeing into useable snippets for my host language. I guess I could do up an executable utility to do the translation, but I have zero x86 experience and almost nil win32 api experience. If someone could please review and reply to advise, I'd greatly appreciate it. Thank you. -t p.s. I did RTFM (actually, Searched) and only found a single snippet about endian-ness and it was related to a specific asm operator, not WRT the compiler's output... |
|||
11 Jul 2009, 23:14 |
|
revolution 12 Jul 2009, 00:01
TodWulff: In ARM all CPUs expect code in little endian format. I don't understand why you would need big endian code? The later CPUs have the "setend" instruction for data accesses to memory that is organised as big endian but this would not affect the binary code (the code will still need to be little endian).
Can you please explain more as to why you need the code in big endian format? I don't know of any system that would use BE for code on a CPU that needs LE for code. |
|||
12 Jul 2009, 00:01 |
|
TodWulff 12 Jul 2009, 01:15
revolution wrote: ...Can you please explain more as to why you need the code in big endian format? I don't know of any system that would use BE for code on a CPU that needs LE for code. Fully understood on your confusion... I am using your tool NOT to generate code that will run natively from Flash, or SRAM, but rather to yield the translation from .asm to machine language, so that I can then copy the machine language code and embed it in the Host Language ASM() constructs. ... The host language is a BASIC derivative. The language is a compiled language, not interpreted. The BASIC compiler I am using resides on-chip and as such has to be small. The smallest compilers are of the recursive-decent type. The parser already does the translations from BE to LE format - i.e. *40001d6c = $12345678 will set the memory as follows: 40001d6c 78 40001d6d 56 40001d6e 34 40001d6f 12 i.e. little endian and a read of the same memory address via X = *40001d6c will set x to $12345678 as one would expect in a LE environment. Now the ASM() construct was recently added to allow me to embed machine-code into my BASIC applications, for optimizing certain functions (such as a context switch, or a state save when servicing an interrupt). ... In order to get usable machine code embedded from BASIC into memory at the correct location, the ASM() construct was added. This new construct needed to be added at a very small penalty from a parser/compiler foot-print perspective, since they resides on-chip in Flash. Accordingly, existing parser code was leveraged and the new construct borne with negligible bloat. This new operator requires machine code to be passed as a parameter in a BE format, so that when it is pushed into the memory locations, using existing libs, it is pushed home in a proper LE format that the core will properly respond to. ... I don't know that I explained it to well, but hopefully you understand. Admittedly, it is an esoteric need, and if FASMWARM doesn't natively support changing the endian-ness of the compiler's binary output, I suspect that you'll tell me to go and take a long walk... -t |
|||
12 Jul 2009, 01:15 |
|
revolution 12 Jul 2009, 03:57
Okay, there is no option in the assembler to generate BE code, so ideally what you need is an external tool to convert the binary to the form that you want. But ...
... you could change the source to make a special version of fasmarm just for your need. find the file "ARMv6.INC". At line around 2828 you see this: Code: ... .store_instruction: mov [edi],ebp add edi,4 jmp instruction_assembled ... Code: ... .store_instruction: bswap ebp ;<--- add this line mov [edi],ebp add edi,4 jmp instruction_assembled ... If you are using THUMB mode then you also need to make changes for the thumb storage around lines 4604 add three lines: Code: ... THUMB_store_instruction: mov eax,edi sub eax,dword[org_origin] test eax,1 mov ecx,THUMB_instruction_not_aligned jnz THUMB_store_instruction_with_error .store: ror bp,8 ;<--- add this line mov [edi],bp add edi,2 jmp instruction_assembled THUMB_store_2_instructions: mov eax,edi sub eax,dword[org_origin] test eax,1 jnz THUMB_instruction_not_aligned bswap ebp ;<--- add this line ror ebp,16 ;<--- add this line mov [edi],ebp add edi,4 jmp instruction_assembled ... |
|||
12 Jul 2009, 03:57 |
|
TodWulff 12 Jul 2009, 05:41
revolution wrote: Okay...so ideally what you need is an external tool to convert the binary to the form that you want. But ... Very true. I do like your idea, however, of building a version of your tool that does what I am wanting. Good suggestion. Thank you. Now, the next question is "How?"... I downloaded the source (FASMARM_small.ZIP) and read the readme - no build instructions that I could see (me = blind?). I searched the directory structure and found a .bat file in the IDE folder. I tried to run that, to no avail. I do have Flat Assembler Proper installed. I tried to load the FASMWARM.asm file and told it to compile, to no avail - it cant find the includes, and neither can I after looking in what I would consider candidate folders. Is there a tutorial somewhere that explains the file/directory structure needed, and also the process, to successfully build the tool from it's sources? I did look at all 14 pages of this thread and came up empty handed. I am not afraid to read, I just do not know where I need to look to learn how to re-build it. Please advise, when convenient. Thanks so much, for all of your help thus far. Have a good evening! -t [edit]... The more I think about it, the more it makes sense to use a simple scripting language (i.e. autoit or ahk) to do up a tool that does the conversion to BE and also converts it to an ascii file that has the ASM($blah) constructs already created for a simple copy/paste into my source. Is it a safe assumption that all (non-thumb) instruction fall on 4 byte boundaries, or would the converter need to have more intelligence?[/edit] Last edited by TodWulff on 12 Jul 2009, 14:29; edited 1 time in total |
|||
12 Jul 2009, 05:41 |
|
revolution 12 Jul 2009, 09:03
You need to have fasm installed and fasmarm installed when you compile the sources. Use the batch file "MAKE_ARM.BAT" to make the fasmwarm version. You need to have your environment includes set also.
All ARM instructions must start on 4 byte boundaries else the CPU will go into fault mode. This is guaranteed by the design. Similarly, all THUMB instructions must start on 2 byte boundaries. |
|||
12 Jul 2009, 09:03 |
|
TodWulff 12 Jul 2009, 14:33
Understood. Thank you. Have a great summer!
-t |
|||
12 Jul 2009, 14:33 |
|
TodWulff 16 Jul 2009, 21:03
Hey Revolution.
I have searched and found a couple of texts that seem to be quite informative for those looking to learn a bit about programming in assembly for the ARM. I offer them in the interests of, if they meet your scrutiny favorably, your possibly putting them on your site for download, in addition to the ARM DDI 0100x document: ARM Assembly Language Programming - Knaggs & Welsh ARM Assembly Language Programming - Pete Cockerell Have a good one! Thanks, kind sir. -t |
|||
16 Jul 2009, 21:03 |
|
revolution 08 Aug 2009, 20:40
TodWulff: Thanks for your input. Unfortunately I cannot include copyrighted documents in the download. It is by the good grace of Tomasz Grysztar that the arm site exists here and I won't do anything that might create future problems for him.
|
|||
08 Aug 2009, 20:40 |
|
stosb_rpc 10 Aug 2009, 09:22
revolution: I tried making a special version of fasmarm that will generate BE code just as you instructed, and it seems to work.
but now i'm facing a new problem, I need an ARM emulator to debug the code. untill now I used NoICE, but it doesn't seem to support BE code. Does any one know a good ARM emulator that will work with BE code? I'm willing to pay, in case that it's not a freeware. Thanks a lot... |
|||
10 Aug 2009, 09:22 |
|
revolution 10 Aug 2009, 15:47
I doubt you will ever find an emulator to support BE code since there are a grand total of zero ARM chips out there will execute BE code natively. Perhaps you can try the same trick again, find an open source emulator and modify it for your needs.
|
|||
10 Aug 2009, 15:47 |
|
rxantos 20 Aug 2009, 01:37
A question.
The iPhone processor is an ARM1176JZF Can this assemble instructions for this processor? And if so, can it output the object format for the iPhone? |
|||
20 Aug 2009, 01:37 |
|
Goto page Previous 1, 2, 3 ... 13, 14, 15 ... 31, 32, 33 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.