简体   繁体   中英

Assembly Address: Label vs Absolute Address

I am writing simple SMIPS assembly tests to be run on HDL-defined processors.

For instance I have the following code that should generate an overflow exception:

main:

        #Test Overflow Exception

        addi $2, $0, 0xffffffff
        addi $3, $2, 0x1  

I know that if the processor is doing the right thing, it should redirect to the handler which is placed at address 0xdeadbeef . I know only to add labels for jumps as in adding the following code to the above:

overflowHandler: 
        addiu $5 $0, 1
        bne   $0, $5, pass

Is there a way to make the overflowHandler code start at the correct 0xdeadbeef address? Does main start at address 0 ?

EDIT : (I have control over jump address from processor described in HDL)

Since I have control over processor jump address from the description of processor design in Bluespec , I can change that to be divisible by 4 and jump to a closer more convenient location. So my question is: does the address start counting from address 0x0 at the beginning of main?? What is the best solution? : change the address jump, or the label to correspond to it?

Thanks in advance,

Since your processor is modeled in Bluespec, it seems that the code to be executed would get loaded in to the processor's memory using Verilog's $readmemh() function, which reads a text file containing the memory contents. It would be up to the Bluespec model creator to decide what address the code will be loaded into, using the arguments to the $readmemh() function and address specifiers within the text file.

The simplest way to create the text file with memory contents is to run your assembly source code through the MIPS assembler and extract the hexadecimal opcodes from the assembler's source code listing.

Question: "does the address start counting from address 0x0?"

A MIPS processor starts executing code at 0x1cf00000 when it is reset. (A Simple MIPS processor starts at 0x00001000 when it is reset.) You would normally put a jump to the start of your test program at the reset address. If you load the test program to be executed at address 0x0 , JR $zero should work.

Branches within the test program should all be to relative addresses, so you don't need to do anything special to specify the address of labels within the test code. If you need to branch to a known location for PASS and FAIL, do something like this (assuming PASS is at address 0x4000 ):

LI $t0, 0x4000
JR $t0

This question is not answered very clear. As a rule, the address of some labels are assigned automatically by the assembler (and or linker) and depends on many factors.

The assembler always has some directives that allows the programmer to control to some extend where the code and labels are placed in the address space. "org" directive is often used for setting the current address of the assembling process.

In most assemblers, the following code will set the label overflowHandler equal to 0xdeadbeef.

                   org 0xdeadbeef ; or any other number
overflowHandler:   
                  ; some code here

But again, it depends on the particular assembler syntax (and they are, as a rule, different among different implementation). Another issue is that even properly compiled, the code must be loaded in the memory on the proper address. This task is not assembler task, but a task of the linker, OS and depends on the binary file format used as well.

Note, that in most operating systems, the programmer can't choose freely the addresses where some binary file will be loaded.

The proper approach here is to learn carefully the tools used for the project - assembler syntax (I mean assembler directives, not the processor instructions), the linker features, the binary format used and the operating system functions that will load this code for execution.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM