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

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

formatting link

Thanks.

Reply to
Robert Willy
Loading thread data ...

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

Reply to
Robert Willy

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 to
Robert Willy

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 to
Anders.Montonen

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 
 Click to see the full signature
Reply to
Tim Wescott

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
Reply to
Paul Bartlett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.