I´m new to assembly programming so I´m using THRSim11 to program some assembly examples.
I´m trying to store a value in memory address $0142 but it seems the value in this memory address doesn´t change.
LDAA #$00
STAA $0142
I first load Acc A with 00 value and then try to store this value to memory address $0142 but it will not change value from $FF.
If I do this with address $40 it works...
What am I doing wrong?
Thanks in advance for your answers.
THRSim11 simulates only memory in the ranges $0000-$00ff and $ff00-$ffff, unless you have the licensed version. Therefore you cannot use the address $0142 in the unlicensed version.
Related
As the title suggests, I want to see from where came the value of a specific address. I am debugging an ios game with lldb. This game has a muliplier value of 0.4 (how fast combos decrease). I can change this value with cheat engine, but I want to know which instruction in assembly set this value to that address so I can change this instruction with hex editor. I used to use watchpoints breakpoints etc.. for variable values, but in this case, the value is constant and it is set when the app starts immediately.
The equivalent instructions in lldb for Jester's gdb steps are:
(lldb) image lookup -va <ADDRESS>
That will tell you everything lldb knows about that address.
I have been experimented around accessing memory used by other programs and I've encountered a little bit strange (to me) results.
First I have created a variable in my first program and gave it the value of 10. Then I looked at the address of it and asigned it manualy to a pointer in my second program. After that i tried to derefrence the pointer and (to my surprise) the program didn't crash. Instead it printed derefrenced pointer's value as 0
Next I created a few other programs to experiment with this. In my first program I created a pointer and asigned 'new int' to it. Then I checked the address of the int and manually asigned it to another pointer in my second program. Now when i tried to derefrence the ptr of my second program it did crash.
Could someone explain why the difference happened? And why was the derefrenced pointer 0?
Sorry for a possibly stupid question :/
This is because the addresses that your program prints for you to see are virtual addresses. Virtual addresses are relative to the memory space of each individual program. They get converted to physical memory addresses by the operating system during runtime.
So you didn't really access the real (physical) memory address of one of your programs from another one. This is also why the pointer value was set to 0.
I am working on a question from a practice computer organization exam
The Problem:
Which of the following instructions can reference a memory location that is #1000 locations from the instruction?
a.ADD
b.LD
c.STR
d.LEA
e.All of the above
f.None of the above
My Thought Process: I am using LC-3 as a reference to do this problem. I used a synonym of reference, mention from Reference to make the question more clear. Now I am down to the question of which one of the following instructions can mention a memory location that is #1000 locations from the instruction. Now, evaluating the individual choices
Add - This can reference a location that is 1000 away. Add can take data from two registers which can represent any memory location. YES!!
LD - LD uses PC relative mode, meaning it has 9 bits for offset or can access a memory location 256 spots away from the address in the program counter register(address of next instruction). So NO!!
STR - uses Base+Offset mode so the memory address it accesses is the address in the base register + offset6. But the address in the base register can already be 1000 memory locations away from the current instruction. So Yes!!
LEA - computes an address like PC Relative LD. So No!! (same justification as LD)
Off my justifications above, my final answer would be a.ADD and c.STR. Does everyone agree with my answer and justifications? Did I miss one?
I don't think ADD can directly reference memory at all in LC-3. I believe it can work either on registers (i.e. you would need to load memory into the register before performing the ADD) or with immediates. So:
ADD: immediate or register addressing only - no direct access to memory
LD: 9bit PC-relative only, cannot reach an offset of 1000
STR: base+offset only, can access memory at any address with an appropriate base address
LEA: 9bit PC-relative only, cannot reach an offset of 1000 (and doesn't really look at the memory anyway)
Check out these slides by Cyrus Bazeghi / Andrea di Blas / Alex Holloway: https://classes.soe.ucsc.edu/cmpe012/Summer08/notes/06_LC3_ISA_markup.pdf. They show the instruction flow through the architecture, which is pretty useful for understanding addressing modes.
I am fairly new to programming and am starting to learn the ins and outs of memory allocation. One question that recently occurred to me that I haven't yet been able to find a clear answer to is do memory addresses themselves take up memory. For example, in a 32-bit system, the way I understand it is that each address in 4 bytes and they will typically refer to an empty 'bucket' in memory that is capable of storing 1 byte of data. Does this mean that for each memory location in a 32-bit system, we are actually using 5 bytes of memory(meaning 4 for the address and 1 for the empty bucket)? I'm sure I am missing something here but any clarification would be much appreciated. Thanks!
To reference a memory address you need to express that memory address somehow, and on 32 bit system a memory reference takes 4 bytes indeed. So for any addressable memory address, somewhere else in memory there are 4 bytes that have that address.
But this does not cascade to an x5 multiplication, because a program does not need to reference every byte of memory. It only needs the address where something in memory starts, and then it can work its way to every byte of that 'something' using arithmetic.
To give an example: you have a string in memory Justin Foss. Is it at address 0x10000000, and this address is stored in a variable. So the actual variable value is 0x10000000, pointing to the string Justin Foss. But at 0x10000000 you only have one byte, the J. At 0x10000001 there is the u, at 0x10000002 is the s and so on. Your application does not need a variable for each character, it only needs one variable (4 bytes) to the beginning of the string. Same for object (fields): you only store the address where the objects starts, and the compiler know how to do the arithmetic to find the field it needs, by adding the necessary offset. In general memory objects are quite large, and a few 4 byte variables in the program reference quite a bit of memory.
(at the risk of oversimplification) Memory is sequential. Address 123 is the one-hundred and twenty third byte from the first (zeroth) by in the system. There is no memory devoted to indicating byte 123 is 123. The byte that comes after that is 124.
Taking my first course in assembly language, I am frustrated with cryptic error messages during debugging... I acknowledge that the following information will not be enough to find the cause of the problem (given my limited understanding of the assembly language, ColdFire(MCF5307, M68K family)), but I will gladly take any advice.
...
jsr out_string
Address Error (format 0x04 vector 0x03 fault status 0x1 status reg 0x2700)
I found a similar question on http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=271, regarding on ADDRESS ERROR in general.
The answer to the question states that the address error is because the code is "incorrectly" trying to execute on a non-aligned boundary (or accessing non-aligned memory).
So my questions will be:
What does it mean to "incorrectly" trying to execute a non-aligned boundary/memory? If there is an example, it would help a lot
What is non-aligned boundary/memory?
How would you approach fixing this problem, assuming you have little debugging technique(eg. using breakpoints and trace)
First of all, it is possible that isn't the instruction causing the error. Be sure to see if the previous or next instruction could have caused it. However, assuming that exception handlers and debuggers have improved:
An alignment exception is what occurs when, say 32 bit (4 byte) data is retrieved from an address which is not a multiple of 4 bytes. For example, variable x is 32 bits at address 2, then
const1: dc.w someconstant
x: dc.l someotherconstant
Then the instruction
mov.l x, %r0
would cause a data alignment fault on a 68000 (and 68010, IIRC). The 68020 eliminated this restriction and performs the unaligned access, but at the cost of decreased performance. I'm not aware of the jsr (jump to subroutine) instruction requiring alignment, but it's not unreasonable and it's easy to arrange—Before each function, insert the assembly language's macro for alignment:
.align long
func: ...
It has been a long time since I've used a 68K family processor, but I can give you some hints.
Trying to execute on an unaligned boundary means executing code at an odd address. If out_string were at an address with the low bit set for example.
The same holds true for a data access to memory of 2 or 4 byte data. I'm not sure if the Coldfire supports byte access to odd memory addresses, but the other 68K family members did.
The address error occurs on the instruction that causes the error in all cases.
Find out what instruction is there. If the pc matches (or is close) then it is an unaligned execution. If it is a memory access, e.g. move.w d0,(a0), then check to see what address is being read/written, in this case the one pointed at by a0.
I just wanted to add that this is very good stuff to figure out. I program high end medical imaging devices in my day job, but occasionally I need to get down to this level. I have found and fixed more than one COTS OS problem by being able to track down just this sort of problem.