Hi, I am trying to use ARMSim# on ARM assembly code. I have downloaded the follow code snippet from the web: ..................... .equ SWI_Open,0x66 @ open a file .equ SWI_Close,0x68 @ close a file .equ SWI_PrStr,0x69 @ Write a null-ending string .equ SWI_RdStr,0x6a @ read a string from file .equ SWI_PrInt,0x6b @ Write an Integer .equ Stdout, 1 @ Set output target to be Stdout .equ SWI_Exit,0x11 @ Stop execution .global _start _start: @ ========= Open file for reading ============================= ldr r0,=myFile mov r1,#0 swi SWI_Open @ open file bcs InFileError @ if cannot open file branch to InFileError ldr r1,=InputFileHandle str r0,[r1] @ ========== Read String ======================================= ldr r0,=InputFileHandle ldr r0,[r0] ldr r1,=array mov r2,#1024 swi SWI_RdStr bcs emptyFile @ branch if file is empty mov r3,#0 mov r5,r0 @ number of characters mov r6,r1 @ address of string mov r7,#0x30 mov r8,#0x39 mov r9,#0x41 mov r10,#0x5A mov r11,#0x61 mov r12,#0x7A @ =============================== Loop: ldrb r4,[r6] cmp r4,r7 BLT sim cmp r4,r8 BLE Num cmp r4,r9 BLT sim cmp r4,r10 BLE Letter InFileError: mov R0, #Stdout ldr R1, =FileOpenInpErrMsg swi SWI_PrStr bal Exit emptyFile: mov R0, #Stdout ldr R1, =FileEmpty swi SWI_PrStr bal Exit Letter: mov r4,#'* strb r4, add r4,r4,#1 bal Loop Num: sim: add r5,r5,#1 InputFileHandle: .word 0 array: .skip 1024 FileEmpty: .asciz "File is Empty" myFile: .asciz "input.txt" FileOpenInpErrMsg: .asciz "Error opening file \n" EndOfFileMsg: .asciz "End of file reached\n" NL: .asciz "\n " @ new line .end ............... When I load it to ARMSim#, it has an error. I have to upload the window message picture to show you, because it is not easy to describe or copy (it prevents copy at ARMSim# widow). I am still new to ARM syntax. Could you show me what is wrong? [IMG]http://i62.tinypic.com/14si53n.png[/IMG] http://tinypic.com/r/14si53n/8 Thanks.
What is wrong when the small asm code loaded into ARMSIM?
Started by ●July 30, 2015
Reply by ●July 30, 20152015-07-30
On Thursday, July 30, 2015 at 5:29:52 PM UTC-7, Robert Willy wrote:> Hi, > > I am trying to use ARMSim# on ARM assembly code. I have downloaded the follow > code snippet from the web: > > ..................... > .equ SWI_Open,0x66 @ open a file > .equ SWI_Close,0x68 @ close a file > .equ SWI_PrStr,0x69 @ Write a null-ending string > .equ SWI_RdStr,0x6a @ read a string from file > .equ SWI_PrInt,0x6b @ Write an Integer > .equ Stdout, 1 @ Set output target to be Stdout > .equ SWI_Exit,0x11 @ Stop execution > .global _start > _start: > @ ========= Open file for reading ============================= > ldr r0,=myFile > mov r1,#0 > swi SWI_Open @ open file > bcs InFileError @ if cannot open file branch to InFileError > ldr r1,=InputFileHandle > str r0,[r1] > @ ========== Read String ======================================= > ldr r0,=InputFileHandle > ldr r0,[r0] > ldr r1,=array > mov r2,#1024 > swi SWI_RdStr > bcs emptyFile @ branch if file is empty > mov r3,#0 > mov r5,r0 @ number of characters > mov r6,r1 @ address of string > mov r7,#0x30 > mov r8,#0x39 > mov r9,#0x41 > mov r10,#0x5A > mov r11,#0x61 > mov r12,#0x7A > @ =============================== > Loop: > ldrb r4,[r6] > cmp r4,r7 > BLT sim > cmp r4,r8 > BLE Num > cmp r4,r9 > BLT sim > cmp r4,r10 > BLE Letter > InFileError: > mov R0, #Stdout > ldr R1, =FileOpenInpErrMsg > swi SWI_PrStr > bal Exit > > emptyFile: > mov R0, #Stdout > ldr R1, =FileEmpty > swi SWI_PrStr > bal Exit > > Letter: > mov r4,#'* > strb r4, > add r4,r4,#1 > bal Loop > > Num: > > > sim: > add r5,r5,#1 > > InputFileHandle: .word 0 > array: .skip 1024 > FileEmpty: .asciz "File is Empty" > myFile: .asciz "input.txt" > FileOpenInpErrMsg: .asciz "Error opening file \n" > EndOfFileMsg: .asciz "End of file reached\n" > NL: .asciz "\n " @ new line > .end > ............... > > When I load it to ARMSim#, it has an error. I have to upload the window > message picture to show you, because it is not easy to describe or copy > (it prevents copy at ARMSim# widow). I am still new to ARM syntax. > Could you show me what is wrong? > > > [IMG]http://i62.tinypic.com/14si53n.png[/IMG] > > > http://tinypic.com/r/14si53n/8 > > > Thanks.The code snippet does have syntax errors. After a careful correction, now it can load to ARMSim#. Thanks.
Reply by ●July 30, 20152015-07-30
On Thursday, July 30, 2015 at 5:29:52 PM UTC-7, Robert Willy wrote:> Hi, > > I am trying to use ARMSim# on ARM assembly code. I have downloaded the follow > code snippet from the web: > > ..................... > .equ SWI_Open,0x66 @ open a file > .equ SWI_Close,0x68 @ close a file > .equ SWI_PrStr,0x69 @ Write a null-ending string > .equ SWI_RdStr,0x6a @ read a string from file > .equ SWI_PrInt,0x6b @ Write an Integer > .equ Stdout, 1 @ Set output target to be Stdout > .equ SWI_Exit,0x11 @ Stop execution > .global _start > _start: > @ ========= Open file for reading ============================= > ldr r0,=myFile > mov r1,#0 > swi SWI_Open @ open file > bcs InFileError @ if cannot open file branch to InFileError > ldr r1,=InputFileHandle > str r0,[r1] > @ ========== Read String ======================================= > ldr r0,=InputFileHandle > ldr r0,[r0] > ldr r1,=array > mov r2,#1024 > swi SWI_RdStr > bcs emptyFile @ branch if file is empty > mov r3,#0 > mov r5,r0 @ number of characters > mov r6,r1 @ address of string > mov r7,#0x30 > mov r8,#0x39 > mov r9,#0x41 > mov r10,#0x5A > mov r11,#0x61 > mov r12,#0x7A > @ =============================== > Loop: > ldrb r4,[r6] > cmp r4,r7 > BLT sim > cmp r4,r8 > BLE Num > cmp r4,r9 > BLT sim > cmp r4,r10 > BLE Letter > InFileError: > mov R0, #Stdout > ldr R1, =FileOpenInpErrMsg > swi SWI_PrStr > bal Exit > > emptyFile: > mov R0, #Stdout > ldr R1, =FileEmpty > swi SWI_PrStr > bal Exit > > Letter: > mov r4,#'* > strb r4, > add r4,r4,#1 > bal Loop > > Num: > > > sim: > add r5,r5,#1 > > InputFileHandle: .word 0 > array: .skip 1024 > FileEmpty: .asciz "File is Empty" > myFile: .asciz "input.txt" > FileOpenInpErrMsg: .asciz "Error opening file \n" > EndOfFileMsg: .asciz "End of file reached\n" > NL: .asciz "\n " @ new line > .end > ............... > > When I load it to ARMSim#, it has an error. I have to upload the window > message picture to show you, because it is not easy to describe or copy > (it prevents copy at ARMSim# widow). I am still new to ARM syntax. > Could you show me what is wrong? > > > [IMG]http://i62.tinypic.com/14si53n.png[/IMG] > > > http://tinypic.com/r/14si53n/8 > > > Thanks.Excuse me. I have a new question in the same thread as the original post. For the below code, ARMSim# does not recognize '.arch armv7-r'. It says: "unknown opcode or directive: .arch" It does not recognize 'addw' either, says: "unknown opcode or directive: addw" I have check ARMTRM. 'addw' is a legal assembly code. '.arch' is also used in some assembler. How do you think ARMSim# want? Thanks. //////////////////// .arch armv7-r .syntax unified .text .thumb .global foo foo: @ Section A6.1.3 "Use of 0b1101 as a register specifier". @ R13 as the source or destination register of a mov instruction. @ only register to register transfers without shifts are supported, @ with no flag setting mov sp,r0 mov r0,sp @ Using the following instructions to adjust r13 up or down by a @ multiple of 4: add sp,sp,#0 addw sp,sp,#0
Reply by ●July 31, 20152015-07-31
Robert Willy <rxjwg98@gmail.com> wrote:> For the below code, ARMSim# does not recognize '.arch armv7-r'. It says: > "unknown opcode or directive: .arch"According to its website, ARMSim# is a simulator for the ARTM7TDMI, which uses the ARMv4T architecture. Also, it might not understand the newer "unified" assembly syntax. -a
Reply by ●July 31, 20152015-07-31
On Thu, 30 Jul 2015 17:29:46 -0700, Robert Willy wrote:> Hi, > > I am trying to use ARMSim# on ARM assembly code. I have downloaded the > follow code snippet from the web:Just as an aside to any 'real' answers: in this day and age there's little point in using assembly language programming for production code. If you're at the point of doing file I/O, then there's a really good chance that a decent optimizing compiler working on well-written C or C++ code will do a more efficient job of implementing your desired algorithm than hand-written assembly. About the only exception to this in my experience is doing DSP or other algorithms where the processor's features aren't a good fit for C -- then you may need to write the inner loops in assembly if you can't figure out how to express things in a way the optimizer can turn into efficient code. Of course, if your point is to learn assembly programming -- go for it. Even in the absence of a need to write esoteric algorithms, every team needs at least one person who can look at what a compiler barfs out and understand what's going on. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●August 1, 20152015-08-01
On Fri, 31 Jul 2015, Tim Wescott wrote:> On Thu, 30 Jul 2015 17:29:46 -0700, Robert Willy wrote: > >> [...] >> >> I am trying to use ARMSim# on ARM assembly code. I have downloaded the >> follow code snippet from the web: > > Just as an aside to any 'real' answers: in this day and age there's > little point in using assembly language programming for production code. > If you're at the point of doing file I/O, then there's a really good > chance that a decent optimizing compiler working on well-written C or C++ > code will do a more efficient job of implementing your desired algorithm > than hand-written assembly. > > [...] > > Of course, if your point is to learn assembly programming -- go for it. > Even in the absence of a need to write esoteric algorithms, every team > needs at least one person who can look at what a compiler barfs out and > understand what's going on.Eventually, of course, everything resolves down to machine code running on the real hardware. Even with respect to software, sooner or later *somebody* has to know the machine language that even the best, most hotshot, greatest compiler spits out, and in practive that means that *somebody* has to be able to program in assembly language. For many real world problems, of course, a so-called high-level compiler or interpreter may suffice, but eventually somebody besides hardware engineers have to know what is going on "down on the iron / silicon." -- Paul Bartlett
