https://cpulator.01xz.net/mw/api.php?action=feedcontributions&feedformat=atom&user=HenryCPUlator Wiki - User contributions [en]2026-05-13T03:41:31ZUser contributionsMediaWiki 1.42.1https://cpulator.01xz.net/mw/index.php?title=MediaWiki:Privacy&diff=122MediaWiki:Privacy2024-10-02T11:36:46Z<p>Henry: Created page with "-"</p>
<hr />
<div>-</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=MediaWiki:Disclaimers&diff=121MediaWiki:Disclaimers2024-10-02T11:36:21Z<p>Henry: Created page with "-"</p>
<hr />
<div>-</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=MediaWiki:Contactpage-subject-feedback&diff=120MediaWiki:Contactpage-subject-feedback2024-10-02T09:10:10Z<p>Henry: </p>
<hr />
<div>CPUlator feedback</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=MediaWiki:Contactpage-subject-feedback&diff=119MediaWiki:Contactpage-subject-feedback2024-10-02T09:09:47Z<p>Henry: Created page with "CPUlator wiki feedback"</p>
<hr />
<div>CPUlator wiki feedback</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=MediaWiki:Contactpage-pagetext-feedback&diff=118MediaWiki:Contactpage-pagetext-feedback2024-10-02T09:05:50Z<p>Henry: Created page with "Use this form if you have a suggestion or a bug to report."</p>
<hr />
<div>Use this form if you have a suggestion or a bug to report.</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=MediaWiki:Mainpage-title&diff=117MediaWiki:Mainpage-title2024-10-02T06:51:39Z<p>Henry: Created page with "CPUlator Help"</p>
<hr />
<div>CPUlator Help</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryStackRedZone&diff=114Msg/MemoryStackRedZone2019-09-30T00:50:55Z<p>Henry: /* Debugging */</p>
<hr />
<div>A stack frame is a region of memory used by an executing function. The memory region at or above the stack pointer is allocated stack space that may be used, while addresses less than the stack pointer may not be used until allocated first. This warning tells you that a memory access attempted to use memory that is near, but below the stack pointer. It is likely (but not necessarily) a bug in allocating, using, and deallocating stack space.<br />
<br />
=== Example ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane <br />
bl Func<br />
<br />
Func:<br />
str r0, [sp, #-4] // Store to stack space we haven't allocated yet<br />
sub sp, #4 // Allocate stack space: Too late.<br />
add sp, #4 // Deallocate stack space<br />
bx lr<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP to something sane <br />
call Func<br />
<br />
Func:<br />
stw r0, -4(sp) # Store to stack space we haven't allocated yet<br />
subi sp, sp, 4 # Allocate stack space: Too late.<br />
addi sp, sp, 4 # Deallocate stack space<br />
ret<br />
</syntaxhighlight><br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
li $sp, 0x1000 # Initialize SP to something sane <br />
jal Func<br />
<br />
Func:<br />
sw $0, -4($sp) # Store to stack space we haven't allocated yet<br />
addiu $sp, $sp, -4 # Allocate stack space: Too late.<br />
addiu $sp, $sp, 4 # Deallocate stack space<br />
jr $ra<br />
</syntaxhighlight><br />
<br />
In the above examples, the stack pointer is 0x1000, but a memory access occurred to 0x0ffc, which is not part of the stack because it is below the stack pointer value (0x1000). <br />
<br />
=== Debugging ===<br />
* Check that any stack space needed by a function is allocated before being used. Also ensure that stack space is not used after being deallocated.<br />
* Another common cause is overrunning the beginning of arrays that are located on the stack while iterating over them (also called a "buffer overflow", a well-known cause of security vulnerabilities). Check the addresses of the memory access and ensure that it makes sense.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and compares the address of each memory access to the stack pointer at the beginning of the function. This warning is generated if a memory access hits the 128-byte region immediately below the stack pointer. This warning is generated at the memory load or store.<br />
<br />
{{DisableMsg|Memory access to unallocated stack space}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/StackDeallocatedParentFrame&diff=113Msg/StackDeallocatedParentFrame2019-03-17T04:14:51Z<p>Henry: </p>
<hr />
<div>A stack frame is a region of memory used by an executing function. When calling a function, the child function's stack frame is at a lower address than the caller's stack frame. New stack space is allocated by decrementing the stack pointer, and stack space is deallocated by incrementing the stack pointer. However, a function should not deallocate the parent function's stack frame. In other words, the stack pointer should never be greater than the value at the beginning of the function. This warning tells you that the stack pointer has increased past the value it had at the beginning of the current function.<br />
<br />
This is a more stringent requirement than simply requiring the stack pointer to be restored to its original value at the end of the function. Because an interrupt can occur at any moment, if the stack pointer increases beyond the current stack frame (deallocating the parent's stack frame) even momentarily, the parent function may lose some of its stack values because an interrupt handler may have executed and used the "free" stack space below the stack pointer.<br />
<br />
=== Example ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane <br />
bl Func<br />
<br />
Func:<br />
add sp, #4 // Deallocate 4 bytes of the caller's stack frame<br />
sub sp, #4 // Can't do this even if the operation is reverted<br />
bx lr<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP to something sane <br />
call Func<br />
<br />
Func:<br />
addi sp, sp, 4 # Deallocate 4 bytes of the caller's stack frame<br />
subi sp, sp, 4 # Can't do this even if the operation is reverted<br />
ret<br />
</syntaxhighlight><br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
li $sp, 0x1000 # Initialize SP to something sane <br />
jal Func<br />
<br />
Func:<br />
addiu $sp, $sp, 4 # Deallocate 4 bytes of the caller's stack frame<br />
addiu $sp, $sp, -4 # Can't do this even if the operation is reverted<br />
jr $ra<br />
</syntaxhighlight><br />
<br />
In the above examples, the stack pointer is initialized to 0x1000. The child function Func can allocate and deallocate stack space below the stack pointer (currently 0x1000). It is not allowed to deallocate the parent's stack frame. The child function here attempts to move the stack pointer to 0x1004. This results in the warning: '''Stack pointer moved beyond current stack frame. sp at beginning of current function was 00001000'''<br />
<br />
The message also reminds you that the stack pointer was 0x1000 at the beginning of the function, and that the stack pointer has increased beyond this point (to 0x1004).<br />
<br />
=== Debugging ===<br />
* Normally, all stack pointer manipulations are matched: decrease the stack pointer when entering a function, and increase the stack pointer immediately before returning. <br />
* Carefully trace through any operations that change the stack pointer. Make sure they're all matched (every decrement is matched by an increment of the same amount). Ensure that the function prologue and epilogue only execute once (not accidentally part of a loop).<br />
* The two places where stack pointer manipulations often occur are at the function prologue and epilogue, and allocating and deallocating arguments passed on the stack when calling a function. These operations are all matched. If your function uses the stack pointer for other purposes, this is an easy source of bugs.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and compares the current stack pointer to the stack pointer at the beginning of the function. This warning is generated at the instruction that modifies the stack pointer.<br />
<br />
{{DisableMsg|SP moved beyond current stack frame}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryStackRedZone&diff=112Msg/MemoryStackRedZone2019-03-17T04:12:05Z<p>Henry: </p>
<hr />
<div>A stack frame is a region of memory used by an executing function. The memory region at or above the stack pointer is allocated stack space that may be used, while addresses less than the stack pointer may not be used until allocated first. This warning tells you that a memory access attempted to use memory that is near, but below the stack pointer. It is likely (but not necessarily) a bug in allocating, using, and deallocating stack space.<br />
<br />
=== Example ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane <br />
bl Func<br />
<br />
Func:<br />
str r0, [sp, #-4] // Store to stack space we haven't allocated yet<br />
sub sp, #4 // Allocate stack space: Too late.<br />
add sp, #4 // Deallocate stack space<br />
bx lr<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP to something sane <br />
call Func<br />
<br />
Func:<br />
stw r0, -4(sp) # Store to stack space we haven't allocated yet<br />
subi sp, sp, 4 # Allocate stack space: Too late.<br />
addi sp, sp, 4 # Deallocate stack space<br />
ret<br />
</syntaxhighlight><br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
li $sp, 0x1000 # Initialize SP to something sane <br />
jal Func<br />
<br />
Func:<br />
sw $0, -4($sp) # Store to stack space we haven't allocated yet<br />
addiu $sp, $sp, -4 # Allocate stack space: Too late.<br />
addiu $sp, $sp, 4 # Deallocate stack space<br />
jr $ra<br />
</syntaxhighlight><br />
<br />
In the above examples, the stack pointer is 0x1000, but a memory access occurred to 0x0ffc, which is not part of the stack because it is below the stack pointer value (0x1000). <br />
<br />
=== Debugging ===<br />
* Check that any stack space needed by a function is allocated before used.<br />
* Another common cause is overrunning the beginning of arrays that are located on the stack while iterating over them (also called a "buffer overflow", a well-known cause of security vulnerabilities). Check the addresses of the memory access and ensure that it makes sense.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and compares the address of each memory access to the stack pointer at the beginning of the function. This warning is generated if a memory access hits the 128-byte region immediately below the stack pointer. This warning is generated at the memory load or store.<br />
<br />
{{DisableMsg|Memory access to unallocated stack space}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryMisaligned&diff=111Msg/MemoryMisaligned2019-03-17T04:07:21Z<p>Henry: </p>
<hr />
<div>Memory accesses need to be aligned. The memory address must be a multiple of the size of the access. For example, a 4-byte load must use an address that is a multiple of 4 bytes. This message says that the memory access was not properly aligned.<br />
<br />
Attempting a misaligned memory access may throw an exception, or result in a load or store that doesn't behave as you would expect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="3"><br />
.global _start<br />
_start:<br />
ldr r0, [pc,#1] // Load 4-byte word from a misaligned address<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="3"><br />
.global _start<br />
_start:<br />
ldw r2, 1(r0) # Load 4-byte word from a misaligned address<br />
</syntaxhighlight><br />
<br />
==== MIPS ====<br />
<syntaxhighlight lang="Asm" line highlight="3"><br />
.global _start<br />
_start:<br />
lw $v0, 1($0) # Load 4-byte word from a misaligned address<br />
</syntaxhighlight><br />
<br />
The above examples try to load from an address that isn't a multiple of 4, but a 4-byte (word-sized) access must be to an address that is a multiple of 4 bytes. The warning message tells you the address the memory access attempted to access.<br />
<br />
=== Debugging ===<br />
* Start by looking at the address used for the memory access (which base register and what offset). Then look at how the address is calculated and why it became incorrect.<br />
* Also check that you are using the correct size memory access. For example, when iterating over a byte array (also called a "string"), each element is one byte, so a byte-sized load or store needs to be used.<br />
<br />
=== Implementation ===<br />
The simulator checks alignment for all memory accesses. This warning is generated while executing the load or store.<br />
<br />
{{DisableMsg|Memory access misaligned}} If the processor throws an alignment exception, disabling the warning message does not change the behaviour of the processor, and the alignment exception will still be thrown.</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FunctionNestCount&diff=110Msg/FunctionNestCount2019-03-17T04:06:03Z<p>Henry: </p>
<hr />
<div>A function is called from a caller, runs some code, and then returns to its caller. Although a function may call other functions (possibly recursively), it is unusual for the function call depth to be very large. This warning tells you that you have exceeded 32 nested function calls.<br />
<br />
Deep function call nesting isn't technically an error. If your program really uses more than 32 nested functions, disable this warning. If not, this is likely indicative of a bug.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
nop<br />
bl NotAFunction // This is a function call, but the target doesn't behave like a function (no return).<br />
nop<br />
NotAFunction: <br />
b _start<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
nop<br />
call NotAFunction # This is a function call, but the target doesn't behave like a function (no return).<br />
nop<br />
NotAFunction: <br />
br _start<br />
</syntaxhighlight><br />
<br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
nop<br />
jal NotAFunction # This is a function call, but the target doesn't behave like a function (no return).<br />
nop<br />
NotAFunction: <br />
b _start<br />
</syntaxhighlight><br />
<br />
The call at line 4 repeatedly calls a function that never returns. The function call depth increases by one every time the call is executed. The Call stack will show a stack of calls originating from line 4.<br />
<br />
=== Debugging ===<br />
* Make sure functions are returning, not stuck in an unending recursion.<br />
* Make sure you do not use a call (or branch-and-link) instruction when the intention is to use a regular branch instruction.<br />
* Use the [https://cpulator.01xz.net/doc/#callstack '''Call stack window'''] (located in the same panel as the registers window) to see where the function calls are occurring. The top entry is the current PC. Each entry below that is the location of the call instruction in the function one nesting level up.<br />
* The [https://cpulator.01xz.net/doc/#callstack '''Trace window'''] may also be useful to see the last 200 instructions executed.<br />
<br />
=== Implementation ===<br />
The simulator tracks idiomatic call and return instructions and counts the function call nesting depth. This message is generated at a call instruction when the new call depth exceeds 32.<br />
<br />
{{DisableMsg|Function nesting too deep}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=109Msg/FetchSelfModifyingCode2019-03-17T04:04:44Z<p>Henry: </p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
li $v0, 0x24630001 # An opcode<br />
sw $v0, 0x10($0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an addiu (opcode 0x24630001)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined until you've flushed the instruction cache and flushed the instruction pipeline.<br />
<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchBadPC&diff=108Msg/FetchBadPC2019-03-17T04:00:04Z<p>Henry: /* ARMv7 */</p>
<hr />
<div>Normally, the CPU should execute code that came from a code section (such as <code>.text</code>) from an executable file generated by an assembler or compiler. This message tells you that the simulator thinks you're currently executing outside a code section.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
nop<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
(This example uses two nops in the .text section for ARM because the assembler pads the length of the .text section to a multiple of 8 bytes.)<br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="5"><br />
.global _start<br />
_start:<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
<br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="5"><br />
.global _start<br />
_start:<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
<br />
As the examples above show, one of the common reasons for encountering this warning is that the program runs past the end of the <code>.text</code> section and starts executing in the <code>.data</code> section. Although the first 32-bit word of the <code>.data</code> section is a valid opcode in this example, executing instructions from the <code>.data</code> section is usually unintended.<br />
<br />
=== Debugging ===<br />
* As in the examples above, make sure your program isn't executing past the end of the <code>.text</code> section.<br />
* Executing from a bad location could also be due to a branch with an incorrect target address. To find the offending branch, try using the [https://cpulator.01xz.net/doc/#callstack <b>Trace window</b>] (located in the same panel as the registers window by default) to look backwards in the program execution.<br />
<br />
=== Implementation ===<br />
ELF executables contain "sections" of bytes that define where in memory each blob of bytes in the executable should be loaded. The ELF executable also includes information on whether each section is intended for executable code (e.g., the <code>.text</code> section contains code) or for data (the <code>.data</code> section is marked as containing data). The simulator tracks the sections defined in the most recently loaded ELF executable, and checks each instruction fetch against the sections. This message is generated at the instruction fetch.<br />
<br />
There may be uncommon cases where the simulator's idea of what is a code section doesn't match reality, and you may want to disable this warning. Some examples:<br />
* Your program writes code into a data section and then executes it. In this case, executing from a data section really is the right thing to do.<br />
* Your program has multiple ELF executables. The simulator uses the section boundaries defined in the most recently loaded ELF executable.<br />
<br />
{{DisableMsg|Instruction fetch: Outside a code section}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchBadPC&diff=107Msg/FetchBadPC2019-03-17T03:59:55Z<p>Henry: /* ARMv7 */</p>
<hr />
<div>Normally, the CPU should execute code that came from a code section (such as <code>.text</code>) from an executable file generated by an assembler or compiler. This message tells you that the simulator thinks you're currently executing outside a code section.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
nop<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
(The example uses two nops in the .text section for ARM because the assembler pads the length of the .text section to a multiple of 8 bytes.)<br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="5"><br />
.global _start<br />
_start:<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
<br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="5"><br />
.global _start<br />
_start:<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
<br />
As the examples above show, one of the common reasons for encountering this warning is that the program runs past the end of the <code>.text</code> section and starts executing in the <code>.data</code> section. Although the first 32-bit word of the <code>.data</code> section is a valid opcode in this example, executing instructions from the <code>.data</code> section is usually unintended.<br />
<br />
=== Debugging ===<br />
* As in the examples above, make sure your program isn't executing past the end of the <code>.text</code> section.<br />
* Executing from a bad location could also be due to a branch with an incorrect target address. To find the offending branch, try using the [https://cpulator.01xz.net/doc/#callstack <b>Trace window</b>] (located in the same panel as the registers window by default) to look backwards in the program execution.<br />
<br />
=== Implementation ===<br />
ELF executables contain "sections" of bytes that define where in memory each blob of bytes in the executable should be loaded. The ELF executable also includes information on whether each section is intended for executable code (e.g., the <code>.text</code> section contains code) or for data (the <code>.data</code> section is marked as containing data). The simulator tracks the sections defined in the most recently loaded ELF executable, and checks each instruction fetch against the sections. This message is generated at the instruction fetch.<br />
<br />
There may be uncommon cases where the simulator's idea of what is a code section doesn't match reality, and you may want to disable this warning. Some examples:<br />
* Your program writes code into a data section and then executes it. In this case, executing from a data section really is the right thing to do.<br />
* Your program has multiple ELF executables. The simulator uses the section boundaries defined in the most recently loaded ELF executable.<br />
<br />
{{DisableMsg|Instruction fetch: Outside a code section}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchBadPC&diff=106Msg/FetchBadPC2019-03-17T03:57:30Z<p>Henry: </p>
<hr />
<div>Normally, the CPU should execute code that came from a code section (such as <code>.text</code>) from an executable file generated by an assembler or compiler. This message tells you that the simulator thinks you're currently executing outside a code section.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
nop<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="5"><br />
.global _start<br />
_start:<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
<br />
==== MIPS ====<br />
<syntaxhighlight line lang="Asm" highlight="5"><br />
.global _start<br />
_start:<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
<br />
As the examples above show, one of the common reasons for encountering this warning is that the program runs past the end of the <code>.text</code> section and starts executing in the <code>.data</code> section. Although the first 32-bit word of the <code>.data</code> section is a valid opcode in this example, executing instructions from the <code>.data</code> section is usually unintended.<br />
<br />
=== Debugging ===<br />
* As in the examples above, make sure your program isn't executing past the end of the <code>.text</code> section.<br />
* Executing from a bad location could also be due to a branch with an incorrect target address. To find the offending branch, try using the [https://cpulator.01xz.net/doc/#callstack <b>Trace window</b>] (located in the same panel as the registers window by default) to look backwards in the program execution.<br />
<br />
=== Implementation ===<br />
ELF executables contain "sections" of bytes that define where in memory each blob of bytes in the executable should be loaded. The ELF executable also includes information on whether each section is intended for executable code (e.g., the <code>.text</code> section contains code) or for data (the <code>.data</code> section is marked as containing data). The simulator tracks the sections defined in the most recently loaded ELF executable, and checks each instruction fetch against the sections. This message is generated at the instruction fetch.<br />
<br />
There may be uncommon cases where the simulator's idea of what is a code section doesn't match reality, and you may want to disable this warning. Some examples:<br />
* Your program writes code into a data section and then executes it. In this case, executing from a data section really is the right thing to do.<br />
* Your program has multiple ELF executables. The simulator uses the section boundaries defined in the most recently loaded ELF executable.<br />
<br />
{{DisableMsg|Instruction fetch: Outside a code section}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedSP&diff=105Msg/ClobberedSP2019-03-17T03:55:56Z<p>Henry: </p>
<hr />
<div>A function should always ensure that the stack pointer is the same at the entry and exit of the function. This message tells you that this didn't happen: the stack pointer was different at the function return than when the function was first called.<br />
<br />
If you also clobbered ra, see also [[Msg/ClobberedRA]]<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop<br />
nop<br />
# ...<br />
<br />
MyFunction:<br />
push {r4} // Change SP<br />
bx lr // SP is different at return<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop<br />
nop<br />
<br />
Function:<br />
subi sp, sp, 4 # Modify SP<br />
ret # SP is different at return<br />
</syntaxhighlight><br />
==== MIPS ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
addiu $sp, $0, 0x1000 # Initialize SP<br />
jal Function<br />
nop<br />
nop<br />
<br />
Function:<br />
subu $sp, $sp, 4 # Modify SP<br />
jr $ra # SP is different at return<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* This message is complaining that the stack pointer differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the stack pointer at both the function entry and return. Are they the same?<br />
* The most common way to use the stack pointer is to modify it while pushing and popping values on the stack. When pushes and pops are mismatched, there is a net change in the stack pointer in the function.<br />
* The two places where stack pointer manipulations often occur are at the function prologue and epilogue, and allocating and deallocating arguments passed on the stack when calling a function. These operations are all matched. If your function modifies the stack pointer for other purposes, change your code so that this doesn't happen (e.g., copy the stack pointer to another register and modify that, instead of modifying the stack pointer).<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies that they haven't changed when executing the matching function return. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}} <br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedRegs&diff=104Msg/ClobberedRegs2019-03-17T03:52:27Z<p>Henry: </p>
<hr />
<div>A calling convention defines which registers a function is allowed to modify (caller-saved), and which registers a function should preserve (callee-saved). Clobbering a register means overwriting its value. This message tells you that there were callee-saved registers (those a function should not modify) that were changed inside the current function.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="8"><br />
.global _start<br />
_start:<br />
bl Func<br />
nop<br />
<br />
Func:<br />
add r4, #1 // Modify a callee-saved register<br />
bx lr<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="8"><br />
.global _start<br />
_start:<br />
call Func<br />
nop<br />
<br />
Func:<br />
addi r16, r16, 1 # Modify a callee-saved register<br />
ret<br />
</syntaxhighlight><br />
<br />
==== MIPS ====<br />
<syntaxhighlight lang="Asm" line highlight="8"><br />
.global _start<br />
_start:<br />
jal Func<br />
nop<br />
<br />
Func:<br />
addiu $s0, $s0, 1 # Modify a callee-saved register<br />
jr $ra<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* This message is complaining that one or more registers differ between the start of the function and at the function return. Use breakpoints and make a note of the value of those registers at both the function entry and return. Are they the same?<br />
* If your function wants to (temporarily) modify callee-saved registers, it should preserve its value first, usually by storing the old value onto the stack and restoring it just before leaving the function. Saving and restoring (also called spilling and filling) can go wrong in many ways, such placing the stack at a location that doesn't contain memory.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies that callee-saved registers haven't changed when executing the matching function return. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered callee-saved register}}<br />
The main reason you might consider disabling this warning is if you are intentionally using a non-standard calling convention.</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedRA&diff=103Msg/ClobberedRA2019-03-17T03:50:06Z<p>Henry: </p>
<hr />
<div>A function should normally return to the instruction after the call instruction in the caller that called this function. This message tells you that this didn't happen: the function return is returning somewhere other than the instruction following the matching call.<br />
<br />
If you also clobbered sp, see also [[Msg/ClobberedSP]]<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
bl MyFunction<br />
nop // Should return here<br />
nop // Actually returns here<br />
# ...<br />
<br />
MyFunction:<br />
add lr, #4 // Change LR<br />
bx lr // return to a different location<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="9"><br />
.global _start<br />
_start:<br />
call Function<br />
nop # Should return here<br />
nop # Actually returns here<br />
<br />
Function:<br />
addi ra, ra, 4 # Modify ra<br />
ret # return to a different location<br />
</syntaxhighlight><br />
<br />
==== MIPS ====<br />
<syntaxhighlight lang="Asm" line highlight="9"><br />
.global _start<br />
_start:<br />
jal Function<br />
nop # Should return here<br />
nop # Actually returns here<br />
<br />
Function:<br />
addiu $ra, $ra, 4 # Modify ra<br />
jr $ra # return to a different location<br />
</syntaxhighlight><br />
<br />
<br />
=== Debugging ===<br />
* This message is complaining that the return address (or link address for ARM) differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the return address (ra or lr) at both the function entry and return. Are they the same?<br />
* Typically, the return address register is not used in a function body except for saving and restoring it to the stack when there is a nested function call. A common cause of the return address changing is a problem during save and restore, e.g., popping from a different location than the corresponding push, or modifying the value that was on the stack. Watch the return address's save and restore and ensure that both the location on the stack and values are the same.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies at return instructions that the return address matches the location of the matching call. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}}<br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/DevGpio&diff=102Msg/DevGpio2019-03-12T09:37:08Z<p>Henry: </p>
<hr />
<div>This page is about the warning messages that can are produced by the GPIO I/O devices. On the Altera University Program computer systems, the same GPIO device is used for switches, push buttons, LEDs, and the 40-pin expansion header.<br />
<br />
==== The GPIO device may not support byte, half-word, or misaligned stores. Use aligned word-sized stores. ====<br />
<br />
The GPIO devices only work correctly with word-sized accesses. Narrower stores produce undefined results.<br />
<br />
The GPIO device hardware ignores the byte-enable signals, so the device treats every access as if it were a word-sized access. This is generally ok with loads, because the device replies with the entire 32-bit value and the CPU extracts part of the word for a narrow (16 or 8 bit) load. This fails for narrow stores because the GPIO device will capture all 32 bits of data, but it is not known what the values of the unused data lines are. (It is probably not random, but it is almost certainly not what you want.)<br />
<br />
==== Each bit of the GPIO device's edge capture register is cleared when a 1 is written to the corresponding bit position. Writing 0 does not clear any edge capture register bits. ====<br />
<br />
The edge capture register hardware is designed to clear a bit only when a 1 is written to it. <br />
<br />
A long time ago (around Quartus version 13.1 and earlier), writing any value into the edge capture register would clear all bits of the GPIO port's edge capture register. This was changed somewhere around version 14.0 to require writing a 1 to clear (allowing partially clearing the register), but Altera's computer system manuals are ''still'' incorrect (as of version 18.0). This warning was added because a non-negligible number of users believed the incorrect documentation and wrote 0 to clear the edge capture register, causing wasted debugging effort.<br />
<br />
Here's a snippet of Verilog code from the GPIO port device (comments added by me), showing the behaviour of one bit slice of the edge capture register:<br />
<syntaxhighlight line lang="Verilog" highlight="8,9"><br />
assign edge_capture_wr_strobe = chipselect && ~write_n && (address == 3);<br />
<br />
always @(posedge clk or negedge reset_n)<br />
begin<br />
if (reset_n == 0)<br />
edge_capture[0] <= 0;<br />
else if (clk_en)<br />
if (edge_capture_wr_strobe && writedata[0]) // When writing a 1, clear the edge capture bit.<br />
edge_capture[0] <= 0;<br />
else if (edge_detect[0]) // When an edge is detected, set the edge capture bit.<br />
edge_capture[0] <= -1;<br />
end<br />
<br />
//...[snip: Replicate once per edge capture bit]<br />
<br />
always @(posedge clk or negedge reset_n)<br />
begin<br />
if (reset_n == 0)<br />
begin<br />
d1_data_in <= 0;<br />
d2_data_in <= 0;<br />
end<br />
else if (clk_en)<br />
begin<br />
d1_data_in <= data_in;<br />
d2_data_in <= d1_data_in; // Two cycles of past history for the data inputs<br />
end<br />
end<br />
<br />
assign edge_detect = ~d1_data_in & d2_data_in; // two_cycles_ago=1 and one_cycle_ago=0 is an "edge".<br />
</syntaxhighlight><br />
<br />
<br />
{{DisableMsg|Device-specific warnings}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/DevGpio&diff=101Msg/DevGpio2019-03-12T09:35:36Z<p>Henry: </p>
<hr />
<div>This page is about the warning messages that can are produced by the GPIO I/O devices. On the Altera University Program computer systems, the same GPIO device is used for switches, push buttons, LEDs, and the 40-pin expansion header.<br />
<br />
==== The GPIO device may not support byte, half-word, or misaligned stores. Use aligned word-sized stores. ====<br />
<br />
The GPIO devices only work correctly with word-sized accesses. Narrower stores produce undefined results.<br />
<br />
The GPIO device hardware ignores the byte-enable signals, so the device treats every access as if it were a word-sized access. This is generally ok with loads, because the device replies with the entire 32-bit value and the CPU extracts part of the word for a narrow (16 or 8 bit) load. This fails for narrow stores because the GPIO device will capture all 32 bits of data, but it is not known what the values of the unused data lines are. (It is probably not random, but it is almost certainly not what you want.)<br />
<br />
==== Each bit of the GPIO device's edge capture register is cleared when a 1 is written to the corresponding bit position. Writing 0 does not clear any edge capture register bits. ====<br />
<br />
The edge capture register hardware is designed to clear a bit only when a 1 is written to it. <br />
<br />
A long time ago (around Quartus version 13.1 and earlier), writing any value into the edge capture register would clear all bits of the GPIO port's edge capture register. This was changed somewhere around version 14.0 to require writing a 1 to clear (allowing partially clearing the register), but Altera's computer system manuals are ''still'' incorrect (as of version 18.0). This warning was added because a non-negligible number of users believed the incorrect documentation and wrote 0 to clear the edge capture register, causing wasted debugging effort.<br />
<br />
Here's a snippet of Verilog code from the GPIO port device (comments added by me), showing the behaviour of one bit slice of the edge capture register:<br />
<syntaxhighlight line lang="Verilog" highlight="8,9"><br />
assign edge_capture_wr_strobe = chipselect && ~write_n && (address == 3);<br />
<br />
always @(posedge clk or negedge reset_n)<br />
begin<br />
if (reset_n == 0)<br />
edge_capture[0] <= 0;<br />
else if (clk_en)<br />
if (edge_capture_wr_strobe && writedata[0]) // When writing a 1, clear the edge capture bit.<br />
edge_capture[0] <= 0;<br />
else if (edge_detect[0]) // When an edge is detected, set the edge capture bit.<br />
edge_capture[0] <= -1;<br />
end<br />
<br />
...[snip]<br />
<br />
always @(posedge clk or negedge reset_n)<br />
begin<br />
if (reset_n == 0)<br />
begin<br />
d1_data_in <= 0;<br />
d2_data_in <= 0;<br />
end<br />
else if (clk_en)<br />
begin<br />
d1_data_in <= data_in;<br />
d2_data_in <= d1_data_in; // Two cycles of past history for the data inputs<br />
end<br />
end<br />
<br />
assign edge_detect = ~d1_data_in & d2_data_in; // two_cycles_ago=1 and one_cycle_ago=0 is an "edge".<br />
</syntaxhighlight><br />
<br />
<br />
{{DisableMsg|Device-specific warnings}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/DevGpio&diff=100Msg/DevGpio2019-03-12T09:34:44Z<p>Henry: /* Each bit of the GPIO device's edge capture register is cleared when a 1 is written to the corresponding bit position. Writing 0 does not clear any edge capture register bits. */</p>
<hr />
<div>This page is about the warning messages that can are produced by the GPIO I/O devices. On the Altera University Program computer systems, the same GPIO device is used for switches, push buttons, LEDs, and the 40-pin expansion header.<br />
<br />
==== The GPIO device may not support byte, half-word, or misaligned stores. Use aligned word-sized stores. ====<br />
<br />
The GPIO devices only work correctly with word-sized accesses. Narrower stores produce undefined results.<br />
<br />
The GPIO device hardware ignores the byte-enable signals, so the device treats every access as if it were a word-sized access. This is generally ok with loads, because the device replies with the entire 32-bit value and the CPU extracts part of the word for a narrow (16 or 8 bit) load. This fails for narrow stores because the GPIO device will capture all 32 bits of data, but it is not known what the values of the unused data lines are. (It is probably not random, but it is almost certainly not what you want.)<br />
<br />
==== Each bit of the GPIO device's edge capture register is cleared when a 1 is written to the corresponding bit position. Writing 0 does not clear any edge capture register bits. ====<br />
<br />
The edge capture register hardware is designed to clear a bit only when a 1 is written to it. <br />
<br />
A long time ago (around Quartus version 13.1 and earlier), writing any value into the edge capture register would clear all bits of the GPIO port's edge capture register. This was changed somewhere around version 14.0 to require writing a 1 to clear (allowing partially clearing the register), but Altera's computer system manuals are ''still'' incorrect (as of version 18.0). This warning was added because a non-negligible number of users believed the incorrect documentation and wrote 0 to clear the edge capture register, causing wasted debugging effort.<br />
<br />
Here's a snippet of Verilog code from one bit slice of the edge capture register from the GPIO port device (comments added by me):<br />
<syntaxhighlight line lang="Verilog" highlight="8,9"><br />
assign edge_capture_wr_strobe = chipselect && ~write_n && (address == 3);<br />
<br />
always @(posedge clk or negedge reset_n)<br />
begin<br />
if (reset_n == 0)<br />
edge_capture[0] <= 0;<br />
else if (clk_en)<br />
if (edge_capture_wr_strobe && writedata[0]) // When writing a 1, clear the edge capture bit.<br />
edge_capture[0] <= 0;<br />
else if (edge_detect[0]) // When an edge is detected, set the edge capture bit.<br />
edge_capture[0] <= -1;<br />
end<br />
<br />
...[snip]<br />
<br />
always @(posedge clk or negedge reset_n)<br />
begin<br />
if (reset_n == 0)<br />
begin<br />
d1_data_in <= 0;<br />
d2_data_in <= 0;<br />
end<br />
else if (clk_en)<br />
begin<br />
d1_data_in <= data_in;<br />
d2_data_in <= d1_data_in; // Two cycles of past history for the data inputs<br />
end<br />
end<br />
<br />
assign edge_detect = ~d1_data_in & d2_data_in; // two_cycles_ago=1 and one_cycle_ago=0 is an "edge".<br />
</syntaxhighlight><br />
<br />
<br />
{{DisableMsg|Device-specific warnings}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/DevGpio&diff=99Msg/DevGpio2019-03-12T09:30:39Z<p>Henry: Created page with "This page is about the warning messages that can are produced by the GPIO I/O devices. On the Altera University Program computer systems, the same GPIO device is used for swit..."</p>
<hr />
<div>This page is about the warning messages that can are produced by the GPIO I/O devices. On the Altera University Program computer systems, the same GPIO device is used for switches, push buttons, LEDs, and the 40-pin expansion header.<br />
<br />
==== The GPIO device may not support byte, half-word, or misaligned stores. Use aligned word-sized stores. ====<br />
<br />
The GPIO devices only work correctly with word-sized accesses. Narrower stores produce undefined results.<br />
<br />
The GPIO device hardware ignores the byte-enable signals, so the device treats every access as if it were a word-sized access. This is generally ok with loads, because the device replies with the entire 32-bit value and the CPU extracts part of the word for a narrow (16 or 8 bit) load. This fails for narrow stores because the GPIO device will capture all 32 bits of data, but it is not known what the values of the unused data lines are. (It is probably not random, but it is almost certainly not what you want.)<br />
<br />
==== Each bit of the GPIO device's edge capture register is cleared when a 1 is written to the corresponding bit position. Writing 0 does not clear any edge capture register bits. ====<br />
<br />
The edge capture register hardware is designed to clear a bit only when a 1 is written to it. <br />
<br />
A long time ago (around Quartus version 13.1 and earlier), writing any value into the edge capture register would clear all bits of the GPIO port's edge capture register. This was changed somewhere around version 14.0 to require writing a 1 to clear (allowing partially clearing the register), but Altera's computer system manuals are ''still'' incorrect (as of version 18.0). This warning was added because a non-negligible number of users believed the incorrect documentation and wrote 0 to clear the edge capture register, causing wasted debugging effort.<br />
<br />
{{DisableMsg|Device-specific warnings}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FunctionNestCount&diff=98Msg/FunctionNestCount2019-03-11T08:49:01Z<p>Henry: </p>
<hr />
<div>A function is called from a caller, runs some code, and then returns to its caller. Although a function may call other functions (possibly recursively), it is unusual for the function call depth to be very large. This warning tells you that you have exceeded 32 nested function calls.<br />
<br />
Deep function call nesting isn't technically an error. If your program really uses more than 32 nested functions, disable this warning. If not, this is likely indicative of a bug.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
nop<br />
bl NotAFunction // This is a function call, but the target doesn't behave like a function (no return).<br />
nop<br />
NotAFunction: <br />
b _start<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
nop<br />
call NotAFunction # This is a function call, but the target doesn't behave like a function (no return).<br />
nop<br />
NotAFunction: <br />
br _start<br />
</syntaxhighlight><br />
<br />
The call at line 4 repeatedly calls a function that never returns. The function call depth increases by one every time the call is executed. The Call stack will show a stack of calls originating from line 4.<br />
<br />
=== Debugging ===<br />
* Make sure functions are returning, not stuck in an unending recursion.<br />
* Make sure you do not use a call (or branch-and-link) instruction when the intention is to use a regular branch instruction.<br />
* Use the [https://cpulator.01xz.net/doc/#callstack '''Call stack window'''] (located in the same panel as the registers window) to see where the function calls are occurring. The top entry is the current PC. Each entry below that is the location of the call instruction in the function one nesting level up.<br />
* The [https://cpulator.01xz.net/doc/#callstack '''Trace window'''] may also be useful to see the last 200 instructions executed.<br />
<br />
=== Implementation ===<br />
The simulator tracks idiomatic call and return instructions and counts the function call nesting depth. This message is generated at a call instruction when the new call depth exceeds 32.<br />
<br />
{{DisableMsg|Function nesting too deep}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FunctionNestCount&diff=97Msg/FunctionNestCount2019-03-11T08:47:22Z<p>Henry: </p>
<hr />
<div>A function is called from a caller, runs some code, and then returns to its caller. Although a function may call other functions (possibly recursively), it is unusual for the function call depth to be very large. This warning tells you that you have exceeded 32 nested function calls.<br />
<br />
This isn't technically an error, but if this behaviour is not expected, it is likely indicative of a bug.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
nop<br />
bl NotAFunction // This is a function call, but the target doesn't behave like a function (no return).<br />
nop<br />
NotAFunction: <br />
b _start<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
nop<br />
call NotAFunction # This is a function call, but the target doesn't behave like a function (no return).<br />
nop<br />
NotAFunction: <br />
br _start<br />
</syntaxhighlight><br />
<br />
The call at line 4 repeatedly calls a function that never returns. The function call depth increases by one every time the call is executed. The Call stack will show a stack of calls originating from line 4.<br />
<br />
=== Debugging ===<br />
* Make sure functions are returning, not stuck in an unending recursion.<br />
* Make sure you do not use a call (or branch-and-link) instruction when the intention is to use a regular branch instruction.<br />
* Use the [https://cpulator.01xz.net/doc/#callstack '''Call stack window'''] (located in the same panel as the registers window) to see where the function calls are occurring. The top entry is the current PC. Each entry below that is the location of the call instruction in the function one nesting level up.<br />
* The [https://cpulator.01xz.net/doc/#callstack '''Trace window'''] may also be useful to see the last 200 instructions executed.<br />
<br />
=== Implementation ===<br />
The simulator tracks idiomatic call and return instructions and counts the function call nesting depth. This message is generated at a call instruction when the new call depth exceeds 32.<br />
<br />
{{DisableMsg|Function nesting too deep}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FunctionNestCount&diff=96Msg/FunctionNestCount2019-03-11T08:32:41Z<p>Henry: </p>
<hr />
<div>A function is called from a caller, runs some code, and then returns to its caller. Although a function may call other functions (possibly recursively), it is unusual for the function call depth to be very large. This warning tells you that you have exceeded 32 nested function calls.<br />
<br />
This isn't technically an error, but if this behaviour is not expected, it is likely indicative of a bug.<br />
<br />
=== Debugging ===<br />
* Make sure functions are returning, not stuck in an unending recursion.<br />
* Make sure you do not use a call (or branch-and-link) instruction when the intention is to use a regular branch instruction.<br />
* Use the [https://cpulator.01xz.net/doc/#callstack '''Call stack window'''] (located in the same panel as the registers window) to see where the function calls are occurring. The top entry is the current PC. Each entry below that is the location of the call instruction in the function one nesting level up.<br />
* The [https://cpulator.01xz.net/doc/#callstack '''Trace window'''] may also be useful to see the last 200 instructions executed.<br />
<br />
=== Implementation ===<br />
The simulator tracks idiomatic call and return instructions and counts the function call nesting depth. This message is generated at a call instruction when the new call depth exceeds 32.<br />
<br />
{{DisableMsg|Function nesting too deep}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FunctionNestCount&diff=95Msg/FunctionNestCount2019-03-11T08:29:38Z<p>Henry: Created page with "A function is called from a caller, runs some code, and then returns to its caller. Although a function may call other functions (possibly recursively), it is unusual for the..."</p>
<hr />
<div>A function is called from a caller, runs some code, and then returns to its caller. Although a function may call other functions (possibly recursively), it is unusual for the function call depth to be very large. This warning tells you that you have exceeded 32 nested function calls.<br />
<br />
This isn't technically an error, but if this behaviour is not expected, it is likely indicative of a bug.<br />
<br />
=== Debugging ===<br />
* Make sure functions are returning, not stuck in an unending recursion.<br />
* Make sure you do not use a call (or branch-and-link) instruction when the intention is to use a regular branch instruction.<br />
* Use the [https://cpulator.01xz.net/doc/#callstack '''Call stack window'''] (located in the same panel as the registers window) to see where the function calls are occurring. The top entry is the current PC. Each entry below that is the location of the call in the caller one nesting level up.<br />
* The [https://cpulator.01xz.net/doc/#callstack '''Trace window'''] may also be useful to see the last 200 instructions executed.<br />
<br />
=== Implementation ===<br />
The simulator tracks idiomatic call and return instructions and counts the function call nesting depth. This message is generated at a call instruction when the new call depth exceeds 32.<br />
<br />
{{DisableMsg|Function nesting too deep}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=94Msg/FetchSelfModifyingCode2019-03-11T07:12:36Z<p>Henry: /* Examples */</p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined until you've flushed the instruction cache and flushed the instruction pipeline.<br />
<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=93Msg/FetchSelfModifyingCode2019-03-11T07:11:07Z<p>Henry: /* ARMv7 */</p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=92Msg/FetchSelfModifyingCode2019-03-11T07:10:47Z<p>Henry: /* Nios II */</p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=91Msg/FetchSelfModifyingCode2019-03-11T07:10:37Z<p>Henry: /* Nios II */</p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=90Msg/FetchSelfModifyingCode2019-03-11T07:10:06Z<p>Henry: /* ARMv7 */</p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #4] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=89Msg/FetchSelfModifyingCode2019-03-11T07:08:20Z<p>Henry: </p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #0] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can pause the program (like a breakpoint) whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=88Msg/FetchSelfModifyingCode2019-03-11T07:07:00Z<p>Henry: /* Debugging */</p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #0] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. Also, the code currently shown in the disassembly window may not match the code that was originally loaded into memory. The objective is to find which part of the program stored values into the memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can interrupt the program whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=87Msg/FetchSelfModifyingCode2019-03-11T07:04:20Z<p>Henry: </p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #0] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. The main objective is to find which part of the program stored values into memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can interrupt the program whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
=== Implementation ===<br />
The simulator keeps the most recently-loaded ELF executable in memory. During every instruction fetch, it compares the fetched opcode to the bytes in the ELF executable, and complains if they are different. This message is generated at the instruction fetch.<br />
<br />
If you are really using self-modifying code, you can disable this warning. But make sure you've followed all of the prescribed rules regarding instruction cache flushing and pipeline flushing defined by the architecture. Nearly all architectures (except x86) will produce undefined results (unknown whether old or new instruction are executed) unless instruction cache and pipeline flushing is correctly done. The simulator does not model any of this complex behaviour: the simulator always executes the modified (new) instructions.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchSelfModifyingCode&diff=86Msg/FetchSelfModifyingCode2019-03-11T06:55:37Z<p>Henry: Created page with "Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly..."</p>
<hr />
<div>Normally, the CPU should execute code that came from an executable file generated by an assembler or compiler. Normally, this code shouldn't be changed at runtime by directly modifying the instructions in memory. A program that (intentionally or unintentionally) modifies its own instructions and then executes them is called self-modifying code. This warning tells you that the instruction being executed came from an executable, and that the instruction is now different that what was in the executable.<br />
<br />
There are some cases where intentional self-modifying code is useful. But unintentional self-modifying code is almost certainly incorrect.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe2822001 // An opcode<br />
str r0, [pc, #0] // Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop // This instruction gets changed to an add (opcode 0xe2822001)<br />
nop<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
movia r2, 0x18c00044 # An opcode<br />
stw r2, 0x10(r0) # Modify instruction at address 0x10. Click "Refresh" to see the new instruction.<br />
nop<br />
nop # This instruction gets changed to an add (opcode 0x18c00044)<br />
nop<br />
</syntaxhighlight><br />
<br />
On the simulator, the highlighted instruction executes as an add (r3 gets incremented), and not the original nop, because the opcode was changed in memory before execution. On real hardware, the behaviour is typically undefined (you may execute the old or new instruction) until you've flushed the instruction cache and flushed the instruction pipeline.<br />
=== Debugging ===<br />
<br />
Unintended self modifying code is notoriously hard to debug. The modified code is not detected until it is next executed, and it may have been modified a very long time ago, so it is often not easy to find the part of the program that actually did the modification. The main objective is to find which part of the program stored values into memory space used by your program's instructions.<br />
<br />
* A common cause of this problem is a memory store somewhere in your program that uses a bad pointer value. This could be simply computing the pointer incorrectly, or overrunning an array bound and overwriting a large swath of memory. Look at the value of the new "opcode" and see if it matches any data pattern that you might have been writing.<br />
* Use a data watchpoint ([https://cpulator.01xz.net/doc/#watchpoints '''Watchpoints window'''], located in the same panel as the registers window by default). A watchpoint can interrupt the program whenever a memory load or store occurs to a range of addresses. Use a watchpoint to look for memory writes to the range of addresses used by your code (set the start and end addresses), and set Pause on Write. Then reload and restart your program. The watchpoint will stop your program whenever a store occurs to your selected region (your instructions), which will hopefully get you much closer to finding the root cause of the problem.<br />
<br />
{{DisableMsg|Instruction fetch: Modified opcode}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/FetchBadPC&diff=85Msg/FetchBadPC2019-03-11T06:26:00Z<p>Henry: Created page with "Normally, the CPU should execute code that came from a code section (such as <code>.text</code>) from an executable file generated by an assembler or compiler. This message te..."</p>
<hr />
<div>Normally, the CPU should execute code that came from a code section (such as <code>.text</code>) from an executable file generated by an assembler or compiler. This message tells you that the simulator thinks you're currently executing outside a code section.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="6"><br />
.global _start<br />
_start:<br />
nop<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="5"><br />
.global _start<br />
_start:<br />
nop<br />
.data<br />
nop<br />
</syntaxhighlight><br />
<br />
As the examples above show, one of the common reasons for encountering this warning is that the program runs past the end of the <code>.text</code> section and starts executing in the <code>.data</code> section. Although the first 32-bit word of the <code>.data</code> section is a valid opcode, executing instructions from the <code>.data</code> section is usually unintended.<br />
<br />
=== Debugging ===<br />
* As in the examples above, make sure your program isn't executing past the end of the <code>.text</code> section.<br />
* Executing from a bad location could also be due to a branch with an incorrect target address. To find the offending branch, try using the [https://cpulator.01xz.net/doc/#callstack <b>Trace window</b>] (located in the same panel as the registers window by default) to look backwards in the program execution.<br />
<br />
=== Implementation ===<br />
ELF executables contain "sections" of bytes that define where in memory each blob of bytes in the executable should be loaded. The ELF executable also includes information on whether each section is intended for executable code (e.g., the <code>.text</code> section contains code) or for data (the <code>.data</code> section is marked as containing data). The simulator tracks the sections defined in the most recently loaded ELF executable, and checks each instruction fetch against the sections. This message is generated at the instruction fetch.<br />
<br />
There may be uncommon cases where the simulator's idea of what is a code section doesn't match reality, and you may want to disable this warning. Some examples:<br />
* Your program writes code into a data section and then executes it. In this case, executing from a data section really is the right thing to do.<br />
* Your program has multiple ELF executables. The simulator uses the section boundaries defined in the most recently loaded ELF executable.<br />
<br />
{{DisableMsg|Instruction fetch: Outside a code section}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryNoDevice&diff=84Msg/MemoryNoDevice2019-03-11T05:51:31Z<p>Henry: </p>
<hr />
<div>The computer system has a 32-bit address space (addresses are 32 bits, and there is 2<sup>32</sup> bytes = 4 gigabytes of address space), but usually only part of that space actually contains memory or I/O devices. This message tells you that a memory access (or instruction fetch) tried to access a location within the address space that is not used by any memory or I/O devices.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe0000000 // Somewhere outside memory and I/O devices.<br />
ldr r1, [r0] // Where is this reading from? Nothing.<br />
<br />
bx r0 // Branch to nowhere<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
movia r2, 0xe0000000 # Somewhere outside memory and I/O devices.<br />
ldw r3, 0(r2) # Where is this reading from? Nothing.<br />
<br />
jmp r2 # Branch to nowhere<br />
</syntaxhighlight><br />
<br />
Note that these examples assume you're using a computer system other than the "generic" systems, which have 4 GB memory mapped to the entire 32-bit address space. Since there is memory mapped to the entire address space, there are no addresses that are mapped to nothing.<br />
<br />
=== Debugging ===<br />
* Check the address used for the memory access.<br />
* For instruction fetches, it means that the PC value is very incorrect. This is often caused by a branch with an incorrect target address. To find the offending branch, try using the [https://cpulator.01xz.net/doc/#callstack <b>Trace window</b>] (located in the same panel as the registers window by default) to look backwards in the program execution.<br />
<br />
=== Implementation ===<br />
For every memory access (including instruction fetches), the simulator needs to find the memory or I/O device that services the address used by the request, and complains if none is found. This warning is generated while executing the load, store, or instruction fetch.<br />
<br />
{{DisableMsg|Memory access out of range}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryNoDevice&diff=83Msg/MemoryNoDevice2019-03-11T05:35:28Z<p>Henry: </p>
<hr />
<div>The computer system has a 32-bit address space (addresses are 32 bits, and there is 2<sup>32</sup> bytes = 4 gigabytes of address space), but usually only part of that space actually contains memory or I/O devices. This message tells you that a memory access tried to access a location within the address space that is not used by any memory or I/O devices.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe0000000 // Somewhere outside memory and I/O devices.<br />
ldr r1, [r0] // Where is this reading from? Nothing.<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
movia r2, 0xe0000000 # Somewhere outside memory and I/O devices.<br />
ldw r3, 0(r2) # Where is this reading from? Nothing.<br />
</syntaxhighlight><br />
<br />
Note that these examples assume you're using a computer system other than the "generic" systems, which have 4 GB memory mapped to the entire 32-bit address space. Since there is memory mapped to the entire address space, there are no addresses that are mapped to nothing.<br />
<br />
=== Debugging ===<br />
* Check the address used for the memory access.<br />
<br />
=== Implementation ===<br />
For every memory access, the simulator needs to find the memory or I/O device that services the address used by the request, and complains if none is found. This warning is generated while executing the load or store.<br />
<br />
{{DisableMsg|Memory access out of range}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryNoDevice&diff=82Msg/MemoryNoDevice2019-03-11T05:33:16Z<p>Henry: Created page with "The computer system has a 32-bit address space (addresses are 32 bits, and there is 2<sup>32</sup> bytes = 4 gigabytes of address space), but usually only part of that space a..."</p>
<hr />
<div>The computer system has a 32-bit address space (addresses are 32 bits, and there is 2<sup>32</sup> bytes = 4 gigabytes of address space), but usually only part of that space actually contains memory or I/O devices. This message tells you that a memory access tried to access a location within the address space that is not used by any memory or I/O devices.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
ldr r0, =0xe0000000 // Somewhere outside memory and I/O devices.<br />
ldr r1, [r0] // Where is this reading from? Nothing.<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="4"><br />
.global _start<br />
_start:<br />
movia r2, 0xe0000000 # Somewhere outside memory and I/O devices.<br />
ldw r3, 0(r2) # Where is this reading from? Nothing.<br />
</syntaxhighlight><br />
<br />
Note that these examples assume you're using a computer system other than the base "4GB memory" systems, which have memory mapped to the entire 32-bit address space, so does not actually have any addresses that aren't mapped to something.<br />
<br />
=== Debugging ===<br />
* Check the address used for the memory access.<br />
<br />
=== Implementation ===<br />
For every memory access, the simulator needs to find the memory or I/O device that services the address used by the request, and complains if none is found. This warning is generated while executing the load or store.<br />
<br />
{{DisableMsg|Memory access out of range}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryCacheBypass&diff=81Msg/MemoryCacheBypass2019-03-11T05:02:33Z<p>Henry: /* Nios II */</p>
<hr />
<div>Memory accesses to memory-mapped I/O should not be cached (or the devices will not see the memory access), while accesses to regular memory should be cached (cache consistency problems if you bypass the cache and the requested address is in the cache). The Nios II uses software-controlled cache bypass, where the "io" variants of loads and stores (ldwio, stwio) bypass the cache and the regular versions (ldw, stw) do not. This message reports that either a regular load/store was done to an I/O device, or a cache-bypassing load/store was done to regular memory.<br />
<br />
=== Examples ===<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="3,6"><br />
.global _start<br />
_start:<br />
ldwio r2, 0(r0) # Read memory using ldwio: Cache bypass should not be used for memory.<br />
<br />
movhi r2, 0xff20 # DE1-SoC LEDs are at ff200000<br />
stw r0, 0(r2) # Write to I/O using stw: Cache bypass should be used for I/O device.<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* Check that the load or store is accessing the correct address. If it is, consider whether it is an I/O device or regular memory, and choose the appropriate instruction type.<br />
<br />
=== Implementation ===<br />
The simulator knows the memory ranges used by the regular memory devices and I/O devices, and checks that the instruction type used (regular vs. I/O) matches the memory type (regular vs. I/O) at the accessed address. This warning is generated while executing the load or store.<br />
<br />
There is some flexibility in interpretation for what can and cannot be safely cached, so there are cases where the memory type assumed by the simulator may be inappropriate. If you're sure that the simulator's expectations do not match reality, you may disable the warning. (An example might be if you want to cache the VGA frame buffer for performance, and then manually flush the data cache at end of drawing each frame.)<br />
<br />
It is also possible that you wish the simulator to ignore the cacheability issue entirely, such as if you're using a computer system that does not have a data cache. If so, it is safe to disable this warning. The Altera University Program Nios II computer systems typically do not have a data cache, so the hardware doesn't actually care which instruction you use, but we still taught this concept at the University of Toronto and expected students to choose the right instruction type.<br />
<br />
{{DisableMsg|Memory: Suspicious use of cache bypass}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/MemoryCacheBypass&diff=80Msg/MemoryCacheBypass2019-03-11T05:01:41Z<p>Henry: Created page with "Memory accesses to memory-mapped I/O should not be cached (or the devices will not see the memory access), while accesses to regular memory should be cached (cache consistency..."</p>
<hr />
<div>Memory accesses to memory-mapped I/O should not be cached (or the devices will not see the memory access), while accesses to regular memory should be cached (cache consistency problems if you bypass the cache and the requested address is in the cache). The Nios II uses software-controlled cache bypass, where the "io" variants of loads and stores (ldwio, stwio) bypass the cache and the regular versions (ldw, stw) do not. This message reports that either a regular load/store was done to an I/O device, or a cache-bypassing load/store was done to regular memory.<br />
<br />
=== Examples ===<br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm"><br />
.global _start<br />
_start:<br />
ldwio r2, 0(r0) # Read memory using ldwio: Cache bypass should not be used for memory.<br />
<br />
movhi r2, 0xff20 # DE1-SoC LEDs are at ff200000<br />
stw r0, 0(r2) # Write to I/O using stw: Cache bypass should be used for I/O device.<br />
</syntaxhighlight><br />
<br />
<br />
=== Debugging ===<br />
* Check that the load or store is accessing the correct address. If it is, consider whether it is an I/O device or regular memory, and choose the appropriate instruction type.<br />
<br />
=== Implementation ===<br />
The simulator knows the memory ranges used by the regular memory devices and I/O devices, and checks that the instruction type used (regular vs. I/O) matches the memory type (regular vs. I/O) at the accessed address. This warning is generated while executing the load or store.<br />
<br />
There is some flexibility in interpretation for what can and cannot be safely cached, so there are cases where the memory type assumed by the simulator may be inappropriate. If you're sure that the simulator's expectations do not match reality, you may disable the warning. (An example might be if you want to cache the VGA frame buffer for performance, and then manually flush the data cache at end of drawing each frame.)<br />
<br />
It is also possible that you wish the simulator to ignore the cacheability issue entirely, such as if you're using a computer system that does not have a data cache. If so, it is safe to disable this warning. The Altera University Program Nios II computer systems typically do not have a data cache, so the hardware doesn't actually care which instruction you use, but we still taught this concept at the University of Toronto and expected students to choose the right instruction type.<br />
<br />
{{DisableMsg|Memory: Suspicious use of cache bypass}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/&diff=79Msg/2019-03-10T23:33:34Z<p>Henry: Redirected page to Msg</p>
<hr />
<div>#REDIRECT [[Msg]]</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedRA&diff=78Msg/ClobberedRA2019-03-10T09:58:01Z<p>Henry: </p>
<hr />
<div>A function should normally return to the instruction after the call instruction in the caller that called this function. This message tells you that this didn't happen: the function return is returning somewhere other than the instruction following the matching call.<br />
<br />
If you also clobbered sp, see also [[Msg/ClobberedSP]]<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop // Should return here<br />
nop // Actually returns here<br />
# ...<br />
<br />
MyFunction:<br />
add lr, #4 // Change LR<br />
bx lr // return to a different location<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop # Should return here<br />
nop # Actually returns here<br />
<br />
Function:<br />
addi ra, ra, 4 # Modify ra<br />
ret # return to a different location<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* This message is complaining that the return address (or link address for ARM) differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the return address (ra or lr) at both the function entry and return. Are they the same?<br />
* Typically, the return address register is not used in a function body except for saving and restoring it to the stack when there is a nested function call. A common cause of the return address changing is a problem during save and restore, e.g., popping from a different location than the corresponding push, or modifying the value that was on the stack. Watch the return address's save and restore and ensure that both the location on the stack and values are the same.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies at return instructions that the return address matches the location of the matching call. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}}<br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedSP&diff=77Msg/ClobberedSP2019-03-10T09:54:59Z<p>Henry: </p>
<hr />
<div>A function should always ensure that the stack pointer is the same at the entry and exit of the function. This message tells you that this didn't happen: the stack pointer was different at the function return than when the function was first called.<br />
<br />
If you also clobbered ra, see also [[Msg/ClobberedRA]]<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop<br />
nop<br />
# ...<br />
<br />
MyFunction:<br />
push {r4} // Change SP<br />
bx lr // SP is different at return<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop<br />
nop<br />
<br />
Function:<br />
subi sp, sp, 4 # Modify SP<br />
ret # SP is different at return<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* This message is complaining that the stack pointer differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the stack pointer at both the function entry and return. Are they the same?<br />
* The most common way to use the stack pointer is to modify it while pushing and popping values on the stack. When pushes and pops are mismatched, there is a net change in the stack pointer in the function.<br />
* The two places where stack pointer manipulations often occur are at the function prologue and epilogue, and allocating and deallocating arguments passed on the stack when calling a function. These operations are all matched. If your function modifies the stack pointer for other purposes, change your code so that this doesn't happen (e.g., copy the stack pointer to another register and modify that, instead of modifying the stack pointer).<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies that they haven't changed when executing the matching function return. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}} <br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedRA&diff=76Msg/ClobberedRA2019-03-10T09:54:54Z<p>Henry: </p>
<hr />
<div>A function should normally return to the instruction after the call instruction in the caller that called this function. This message tells you that this didn't happen: the function return is returning somewhere other than the instruction following the matching call.<br />
<br />
If you also clobbered sp, see also [[Msg/ClobberedSP]]<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop // Should return here<br />
nop // Actually returns here<br />
# ...<br />
<br />
MyFunction:<br />
add lr, #4 // Change LR<br />
bx lr // return to a different location<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop # Should return here<br />
nop # Actually returns here<br />
<br />
Function:<br />
addi ra, ra, 4 # Modify ra<br />
ret # return to a different location<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* Fundamentally, this message is complaining that the return address differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the return address (ra or lr) at both the function entry and return. Are they the same?<br />
* Typically, the return address register is not used in a function body except for saving and restoring it to the stack due to the need for a nested function call. A common cause of the return address changing is a problem during save and restore, e.g., popping from a different location than the corresponding push, or modifying the value that was on the stack. Watch the return address's save and restore and ensure that both the location on the stack and values are the same.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies at return instructions that the return address matches the location of the matching call. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}}<br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedRA&diff=75Msg/ClobberedRA2019-03-10T07:40:18Z<p>Henry: </p>
<hr />
<div>A function should normally return to the instruction after the call instruction in the caller that called this function. This message tells you that this didn't happen: the function return is returning somewhere other than the instruction following the matching call.<br />
<br />
If you clobbered sp, see also [[Msg/ClobberedSP]]<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop // Should return here<br />
nop // Actually returns here<br />
# ...<br />
<br />
MyFunction:<br />
add lr, #4 // Change LR<br />
bx lr // return to a different location<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop # Should return here<br />
nop # Actually returns here<br />
<br />
Function:<br />
addi ra, ra, 4 # Modify ra<br />
ret # return to a different location<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* Fundamentally, this message is complaining that the return address differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the return address (ra or lr) at both the function entry and return. Are they the same?<br />
* Typically, the return address register is not used in a function body except for saving and restoring it to the stack due to the need for a nested function call. A common cause of the return address changing is a problem during save and restore, e.g., popping from a different location than the corresponding push, or modifying the value that was on the stack. Watch the return address's save and restore and ensure that both the location on the stack and values are the same.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies at return instructions that the return address matches the location of the matching call. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}}<br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedSP&diff=74Msg/ClobberedSP2019-03-10T07:40:15Z<p>Henry: </p>
<hr />
<div>A function should always ensure that the stack pointer is the same at the entry and exit of the function. This message tells you that this didn't happen: the stack pointer was different at the function return than when the function was first called.<br />
<br />
If you clobbered ra, see also [[Msg/ClobberedRA]]<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop<br />
nop<br />
# ...<br />
<br />
MyFunction:<br />
push {r4} // Change SP<br />
bx lr // SP is different at return<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop<br />
nop<br />
<br />
Function:<br />
subi sp, sp, 4 # Modify SP<br />
ret # SP is different at return<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* This message is complaining that the stack pointer differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the stack pointer at both the function entry and return. Are they the same?<br />
* The most common way to use the stack pointer is to modify it while pushing and popping values on the stack. When pushes and pops are mismatched, there is a net change in the stack pointer in the function.<br />
* The two places where stack pointer manipulations often occur are at the function prologue and epilogue, and allocating and deallocating arguments passed on the stack when calling a function. These operations are all matched. If your function modifies the stack pointer for other purposes, change your code so that this doesn't happen (e.g., copy the stack pointer to another register and modify that, instead of modifying the stack pointer).<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies that they haven't changed when executing the matching function return. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}} <br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedSP&diff=73Msg/ClobberedSP2019-03-10T07:27:26Z<p>Henry: /* Debugging */</p>
<hr />
<div>A function should always ensure that the stack pointer is the same at the entry and exit of the function. This message tells you that this didn't happen: the stack pointer was different at the function return than when the function was first called.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop<br />
nop<br />
# ...<br />
<br />
MyFunction:<br />
push {r4} // Change SP<br />
bx lr // SP is different at return<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop<br />
nop<br />
<br />
Function:<br />
subi sp, sp, 4 # Modify SP<br />
ret # SP is different at return<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* This message is complaining that the stack pointer differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the stack pointer at both the function entry and return. Are they the same?<br />
* The most common way to use the stack pointer is to modify it while pushing and popping values on the stack. When pushes and pops are mismatched, there is a net change in the stack pointer in the function.<br />
* The two places where stack pointer manipulations often occur are at the function prologue and epilogue, and allocating and deallocating arguments passed on the stack when calling a function. These operations are all matched. If your function modifies the stack pointer for other purposes, change your code so that this doesn't happen (e.g., copy the stack pointer to another register and modify that, instead of modifying the stack pointer).<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies that they haven't changed when executing the matching function return. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}} <br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/StackDeallocatedParentFrame&diff=72Msg/StackDeallocatedParentFrame2019-03-10T07:24:28Z<p>Henry: </p>
<hr />
<div>A stack frame is a region of memory used by an executing function. When calling a function, the child function's stack frame is at a lower address than the caller's stack frame. New stack space is allocated by decrementing the stack pointer, and stack space is deallocated by incrementing the stack pointer. However, a function should not deallocate the parent function's stack frame. In other words, the stack pointer should never be greater than the value at the beginning of the function. This warning tells you that the stack pointer has increased past the value it had at the beginning of the current function.<br />
<br />
This is a more stringent requirement than simply requiring the stack pointer to be restored to its original value at the end of the function. Because an interrupt can occur at any moment, if the stack pointer increases beyond the current stack frame (deallocating the parent's stack frame) even momentarily, the parent function may lose some of its stack values because an interrupt handler may have executed and used the "free" stack space below the stack pointer.<br />
<br />
=== Example ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane <br />
bl Func<br />
<br />
Func:<br />
add sp, #4 // Deallocated 4 bytes of the caller's stack frame<br />
sub sp, #4 // Can't do this even if the operation is reverted<br />
bx lr<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight line lang="Asm" highlight="7"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP to something sane <br />
call Func<br />
<br />
Func:<br />
addi sp, sp, 4 # Deallocated 4 bytes of the caller's stack frame<br />
subi sp, sp, 4 # Can't do this even if the operation is reverted<br />
ret<br />
</syntaxhighlight><br />
<br />
In the above examples, the stack pointer is initialized to 0x1000. The child function Func can allocate and deallocate stack space below the stack pointer (currently 0x1000). It is not allowed to deallocate the parent's stack frame. The child function here attempts to move the stack pointer to 0x1004. This results in the warning: '''Stack pointer moved beyond current stack frame. sp at beginning of current function was 00001000'''<br />
<br />
The message also reminds you that the stack pointer was 0x1000 at the beginning of the function, and that the stack pointer has increased beyond this point (to 0x1004).<br />
<br />
=== Debugging ===<br />
* Normally, all stack pointer manipulations are matched: decrease the stack pointer when entering a function, and increase the stack pointer immediately before returning. <br />
* Carefully trace through any operations that change the stack pointer. Make sure they're all matched (every decrement is matched by an increment of the same amount). Ensure that the function prologue and epilogue only execute once (not accidentally part of a loop).<br />
* The two places where stack pointer manipulations often occur are at the function prologue and epilogue, and allocating and deallocating arguments passed on the stack when calling a function. These operations are all matched. If your function uses the stack pointer for other purposes, this is an easy source of bugs.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and compares the current stack pointer to the stack pointer at the beginning of the function. This warning is generated at the instruction that modifies the stack pointer.<br />
<br />
{{DisableMsg|SP moved beyond current stack frame}}</div>Henryhttps://cpulator.01xz.net/mw/index.php?title=Msg/ClobberedRA&diff=71Msg/ClobberedRA2019-03-10T07:13:59Z<p>Henry: </p>
<hr />
<div>A function should normally return to the instruction after the call instruction in the caller that called this function. This message tells you that this didn't happen: the function return is returning somewhere other than the instruction following the matching call.<br />
<br />
=== Examples ===<br />
==== ARMv7 ====<br />
<br />
<syntaxhighlight lang="Asm" line highlight="11"><br />
.global _start<br />
_start:<br />
mov sp, #0x1000 // Initialize SP to something sane<br />
bl MyFunction<br />
nop // Should return here<br />
nop // Actually returns here<br />
# ...<br />
<br />
MyFunction:<br />
add lr, #4 // Change LR<br />
bx lr // return to a different location<br />
</syntaxhighlight><br />
==== Nios II ====<br />
<syntaxhighlight lang="Asm" line highlight="10"><br />
.global _start<br />
_start:<br />
movi sp, 0x1000 # Initialize SP<br />
call Function<br />
nop # Should return here<br />
nop # Actually returns here<br />
<br />
Function:<br />
addi ra, ra, 4 # Modify ra<br />
ret # return to a different location<br />
</syntaxhighlight><br />
<br />
=== Debugging ===<br />
* Fundamentally, this message is complaining that the return address differs between the start of the function and at the function return. Use breakpoints and make a note of the value of the return address (ra or lr) at both the function entry and return. Are they the same?<br />
* Typically, the return address register is not used in a function body except for saving and restoring it to the stack due to the need for a nested function call. A common cause of the return address changing is a problem during save and restore, e.g., popping from a different location than the corresponding push, or modifying the value that was on the stack. Watch the return address's save and restore and ensure that both the location on the stack and values are the same.<br />
<br />
=== Implementation ===<br />
The simulator identifies idiomatic call and return instructions executed at runtime. It records the values of registers when executing call instructions, and verifies at return instructions that the return address matches the location of the matching call. This warning is generated at the return instruction.<br />
<br />
{{DisableMsg|Function clobbered ra or sp}}<br />
<br />
ARMv7: <b>Function clobbered sp, or bad return</b></div>Henry