Menu
▾
▴
Re: [B2-devel] Macintosh memory information?
|
From: Michael S. <msb...@me...> - 2012-07-20 00:09:43
|
On Jul 19, 2012, at 7:23 AM, Alexander von Gluck wrote: > On 18.07.2012 23:01, Michael Schmitt wrote: >> Inside Macintosh: Memory is available at >> >> <http://developer.apple.com/legacy/mac/library/#documentation/mac/Memory/Memory-2.html> >> >> As far as I can tell (and I could be wrong)... >> >> Basilisk II supports three types of memory access modes. Which one to use >> is selected at compile time: >> >> REAL: The addresses seen inside the emulated machine are exactly the same >> as the host memory address. >> >> DIRECT: The addresses are shifted by a fixed offset. It calculates it at >> runtime, by allocating the guest memory >> block anywhere the host can find space, and then calculating the offset >> between the guest and host addresses. >> >> VIRTUAL: The guest address space is broken down into banks, e.g. the RAM, >> ROM and frame buffer are handled >> separately. It uses some kind of address translation logic. > > These definitions seem to be swapped (as far as I can tell) > https://github.com/kallisti5/sheepshear/blob/master/src/platform/Unix/main_unix.cpp#L944 > > The UNIX code above seems to allocate the memory anywhere available with > REAL addressing, and at a fixed location > with DIRECT addressing. > > I haven't seen and references to VIRTUAL memory access mode though. That's because first I was describing how the Basilisk II code works, from which SheepShaver is derived. BII has VIRTUAL, SS doesn't. In REAL mode SS allocates the HOST block where ever it can. But once it is allocated, the address the guest sees is exactly the host address where the block was allocated. In DIRECT mode the memory is allocated at a fixed address (that in SS is determined at compile time), and then the addresses are translated so the guest sees RAM starting at zero. >> SheepShaver (at least the 32-bit version, I don't know about 64-bit) >> supports REAL and DIRECT addressing modes, but >> not VIRTUAL. >> >> I don't know if anyone uses DIRECT in SheepShaver, because it has a fatal >> flaw. Unlike Basilisk II, the offset is >> calculated at *compile* time. But this only works if each user compiles >> the code! And if something changes the >> library address randomization (such as applying an upgrade) it invalidates >> the compiled-in offset. You would need to >> keep recompiling it. Of course this is completely non-portable. > > This may explain some of the large emulation problems seen on newer gcc + > x86_64 Does it use DIRECT mode? I've only used SheepShaver in REAL mode. >> That leaves REAL mode. >> >> When running on PPC, REAL mode allows it to run virtualized instead of >> emulated, where it can just let the native >> processor loose on the code. Running on Intel there shouldn't be a >> penalty for doing an address shift, since it has >> to emulate the CPU and anyway. But it doesn't shift it, due to the way >> DIRECT is implemented as described above. > > > Given these limitations, can we put a wrapper around memory calls and adjust > the memory offsets at run time? (enabling > us to cherrypick whichever host memory we want to? (but we should make sure > it is aligned to 1MB)) Remember it is the guest ROM rom address that needs to be aligned. It doesn't matter if the host address is aligned. > Example: > Mac2HostAddr, Host2MacAddr can do address translation, so why not do the > following: > > 1) Take a hunk of memory, allocate it large enough for RAM and ROM > (aligned) for easy debugging > 2) Set the RAMBaseHost to the start of the chunk of memory > 3) Set the ROMBaseHost to the start of the chunk of memory + RAM size > (which should be at least 1MB intervals) > > *) Mac2HostAddr - If we catch a RAM address (0 - 1GB) with Mac2HostAddr, > point it to RAMBaseHost + mac offset > *) Mac2HostAddr - If we catch a ROM address (0x40800000 - 0x40D00000), > point it to the ROMBaseHost + mac offset > *) Host2MacAddr - If we catch RAMBaseHost - RAM Size, subtract RAMBaseHost > *) Host2MacAddr - If we catch ROMBaseHost - 5MB, subtract ROMBaseHost > > I don't understand the JIT stuff enough yet though to see if this would work > with it. > > Thoughts? Essentially that would be changing SheepShaver to use the same DIRECT mode as Basilisk II (if all addresses are shifted by the same offset), or Basilisk II's VIRTUAL mode, which currently is not in SheepShaver. But since the Mac OS doesn't need to have the RAM and ROM at any particular address, simply shifting the host-to-guest RAM/ROM addresses doesn't buy us much. What we would want is to translate all of the addresses: the low system globals at 0x0, the special data areas, etc. When I looked at the DIRECT code I wasn't sure if it could handle 32-bit wrap-around access properly. Consider that if guest 0x0 is actually in the middle of the host space, then some of the high guest space is actually less than it. What happens when a guest memory operation needs to wrap from high host to low host? And there could be cases where SheepShaver is making an assumption that the distance between two guest addresses is the same as the distance between the two corresponding host addresses, and vice versa. In 64-bit mode we should have huge amounts of host address space. Can we map the entire guest address space, all 4 GB of it or whatever the classic Mac OS had, high up in 64-bit land and then shift everything -- including the 0x0 globals? Or do we still have the problem of Cocoa allocating stuff in our address space at initialization? > -- Alex > >> >> On Jul 18, 2012, at 7:20 AM, Alexander von Gluck wrote: >> >>> Does anyone have any documentation on the memory layout of the old world >>> Macintosh? (Performa 6400 era) >>> >>> I've been looking to rework how SheepShear manages memory and it's not >>> completely clear to me how it does >>> it's memory translation. Most of the bugs I've seen on x86_64 are due to >>> the exact memory mapping on emulated >>> powerpc systems (eg, hard coded memory addresses we *have* to map for >>> things >>> to function) and something getting mangled >>> on x86_64. >>> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089 >>> >>> I see memory maps for the really early Mac's, but am failing to find >>> anything for the later old world machines >>> online or in the old Macintosh service manuals. >>> >>> Here is what I know for a fact looking at the code: >>> >>> Low memory area, - 0x0 - 0x3000 (static 1:1 host:guest location) >>> RAM, 0x0 - (memory size selected less then 1GB) >>> ROM, 0x40800000 - 0x40C00000 (4MB mac rom) (static 1:1 >>> host:guest location) >>> >>> Real addressing == "normal" allocation where memory locations are >>> dynamic, >>> and we translate addresses to match >>> Direct addressing == memory is directly addressed, mostly used on native >>> PowerPC? >>> Nat_mem offset == ???, guessing it's for native PowerPC >>> >>> It looks given the code below that the Macintosh has to be patched to use >>> the host memory >>> addresses vs the emulator doing the memory translation (SheepShear acting >>> as >>> a mmu to the guest) >>> >>> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185 >>> >>> The reason I ask here is because these changes could be pulled upstream >>> to >>> SheepShaver. >>> >>> -- Thanks! >>> Alex >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> basilisk-devel mailing list >>> bas...@li... >>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> basilisk-devel mailing list >> bas...@li... >> https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
