Mini vMac Updates: September 18
Posted: Sun Sep 25, 2016 5:44 am
Mini vMac development continues apace!
"The latest Mini vMac Development source snapshot improves instruction fetching. A badly behaved program can cause Mini vMac to crash, attempting to fetch an emulated instruction from random memory, which memory protection on a modern computer prevents. Since this is only a bad read, I don’t think any further harm is possible besides crashing Mini vMac. Most kinds of memory access emulated by Mini vMac have for a quite while have been designed to always be accurate and safe. But for speed, fetching the next instruction would simply increment a pointer to where the instruction is in real memory, and relative branches would just offset this pointer. Only for certain long branches would Mini vMac work out from scratch where the instruction is in real memory. This is good enough for all known correctly working software. But it is in theory possible to write code so that the pointer to the next instruction gets set to arbitrary memory that the operating system may not allow Mini vMac to access, resulting in a crash. And not just in theory, I have seen this happen in programs running in Mini vMac that were malfunctioning.
This bug is fixed by keeping low and high limits for the instruction pointer, and checking against them as the pointer is changed. When fetching the next instruction, it only needs to check against the high limit. And the increment and check is done after the current instruction is fetched, and so it could be done in parallel with other things. A modern computer can do several things at once as long as they don’t interfere with each other. So it shouldn’t affect speed too much.
Actually, at first it slowed things down a lot. But then I figured out it was because the compiler I use for development messed up with the C inline directive. I figured out how to get the compiler to inline if and only if I tell it to, which gained back all speed lost, and a little bit more. So now the build system defined macros MayNotInline or MayInline are used for every function in Mini vMac.
The ability to turn off USE_POINTER and FastRelativeJump for greater accuracy is removed from the source code, since they are now always accurate and safe.
These changes have only been made in the C implementation of CPU emulation so far. The PowerPC and x86 assembly languages versions are to be fixed next.
The same thing has been done to the assembly language source as previously was done API, sound, and language sources. They have been given unique names and moved to the main source folder. (Which has been renamed from “c_src” to “src” since it is no longer just C.) Also, instead of the build system transforming the PowerPC code for MPW, there are two PowerPC versions, and some scripts (in the new file “trans”) to help keep them in sync. The idea being moved to is that the build system only generates configuration files, and the source folder is the source, basically the same in the source archive and when being compiled.
The motivation for working on the CPU emulation is that I would like to make assembly language versions for ARM and X86-64, but there are issues, such as today’s safe instruction fetching, that would be a lot easier to deal with first, before there are more versions to keep in sysnc."
Source:
http://www.gryphel.com/index.html#news
"The latest Mini vMac Development source snapshot improves instruction fetching. A badly behaved program can cause Mini vMac to crash, attempting to fetch an emulated instruction from random memory, which memory protection on a modern computer prevents. Since this is only a bad read, I don’t think any further harm is possible besides crashing Mini vMac. Most kinds of memory access emulated by Mini vMac have for a quite while have been designed to always be accurate and safe. But for speed, fetching the next instruction would simply increment a pointer to where the instruction is in real memory, and relative branches would just offset this pointer. Only for certain long branches would Mini vMac work out from scratch where the instruction is in real memory. This is good enough for all known correctly working software. But it is in theory possible to write code so that the pointer to the next instruction gets set to arbitrary memory that the operating system may not allow Mini vMac to access, resulting in a crash. And not just in theory, I have seen this happen in programs running in Mini vMac that were malfunctioning.
This bug is fixed by keeping low and high limits for the instruction pointer, and checking against them as the pointer is changed. When fetching the next instruction, it only needs to check against the high limit. And the increment and check is done after the current instruction is fetched, and so it could be done in parallel with other things. A modern computer can do several things at once as long as they don’t interfere with each other. So it shouldn’t affect speed too much.
Actually, at first it slowed things down a lot. But then I figured out it was because the compiler I use for development messed up with the C inline directive. I figured out how to get the compiler to inline if and only if I tell it to, which gained back all speed lost, and a little bit more. So now the build system defined macros MayNotInline or MayInline are used for every function in Mini vMac.
The ability to turn off USE_POINTER and FastRelativeJump for greater accuracy is removed from the source code, since they are now always accurate and safe.
These changes have only been made in the C implementation of CPU emulation so far. The PowerPC and x86 assembly languages versions are to be fixed next.
The same thing has been done to the assembly language source as previously was done API, sound, and language sources. They have been given unique names and moved to the main source folder. (Which has been renamed from “c_src” to “src” since it is no longer just C.) Also, instead of the build system transforming the PowerPC code for MPW, there are two PowerPC versions, and some scripts (in the new file “trans”) to help keep them in sync. The idea being moved to is that the build system only generates configuration files, and the source folder is the source, basically the same in the source archive and when being compiled.
The motivation for working on the CPU emulation is that I would like to make assembly language versions for ARM and X86-64, but there are issues, such as today’s safe instruction fetching, that would be a lot easier to deal with first, before there are more versions to keep in sysnc."
Source:
http://www.gryphel.com/index.html#news