Segmentation fault protection: Difference between revisions
no edit summary
m (→{{header|Wren}}: Minor edit to example.) |
Puppydrum64 (talk | contribs) No edit summary |
||
Line 59:
However, when Wren is embedded in a C host, segfaults are certainly possible and there is no protection against them whatsoever. As Wren's virtual machine is not re-entrant a common source of segfaults is trying to treat it as if it was!
=={{header|Z80 Assembly}}==
The Z80, like the 6502, considers the entire address space of the CPU as a valid place to read, write, or execute. As a result, the hardware itself will not deny your program access to anything in the 64k address space. Writes to ROM will be at best silently ignored, or, in the case of certain Game Boy cartridges, be interpreted as a command to the bankswitching hardware.
Overwriting executable RAM and executing the stack/heap are both perfectly legal in the eyes of the CPU, and many Z80 programs took advantage of this to save memory or increase the speed of a subroutine. (It takes fewer clock cycles to store the accumulator as the operand of a future <code>LD A,#</code> instruction than it does to execute <code>PUSH AF</code> and <code>POP AF</code>.) The Z80 has no pipeline, branch prediction, or speculative execution so performing such self-modifying code tricks won't result in problems if done correctly.
Dereferencing a null pointer will return one or two arbitrary bytes that aren't particularly useful. It won't cause a crash, however. The first 8 bytes of the Z80's address space are used for a small subroutine that can be called with <code>RST 0</code> or <code>CALL &0000</code>, which is such a small section of memory that most programmers will place a jump to the actual code they want to run at that address instead.
| |||