What is wrong when the small asm code loaded into ARMSIM?

Question

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]

formatting link

Thanks.

Robert Willy · Accepted Answer

" "  " @ new line The code snippet does have syntax errors. After a careful correction, now it can load to ARMSim#. Thanks.

Robert Willy · Answer

" "  " @ new line 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

Anders.Montonen · Answer

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

Tim Wescott · Answer

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.

Paul Bartlett · Answer

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."

What is wrong when the small asm code loaded into ARMSIM?

Join the Discussion

Didn't find your answer?