Agreed, Micro XP is a huge difference over full XP.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Running Snow Leopard on a PowerPC Mac
- Thread starter foxlet
- Start date
- Sort by reaction score
Agreed, Micro XP is a huge difference over full XP.
I've made the experience that on early C2Ds it's not really a big difference. At least not in light usage daily tasks. Sometimes Leopard even felt to be faster
I think he is referring to the QEMU version used on your Tibook
That's right. My understanding is that there were fundamental changes to memory management in QEMU 2.5.0 and up which legacy OS X can't handle (as in PowerPC 10.5.8). But I was hoping to see the recent versions running on Leopard PPC because of all the improvements made for OS9 and OSX guest VMs
[doublepost=1501295126][/doublepost]
I haven't natively run Leopard on an Intel Mac in a long time, but between 2008 - 2011 I was using my MacBook unibody (C2D 2.0Ghz) for music performances and for the sake of stability and zero interruptions, I had a separate partition on a 7200rpm spinner which just had a clean install of 10.5.8 with Ableton Live and all my NI plugins. The other partition had Snow with all my work related programs, mods, etc and was noticeably slower to boot and slower to move.
Leopard would boot within seconds and wouldn't go down...
Except one time when someone kicked the power supply out of an extension lead and I didn't notice until the Macbook's battery went flat about an hour into the set... fortunately I moved quick enough to get Leopard and Ableton back up and going again within about 90 seconds and we just called it an intermission. At the time it felt like a lot longer though...
As said before in the conversation you don't need the modified kernel as QEMU emulates intel processors or something
But anyway, just search a hackingtosh distro it should have it
As said before in the conversation you don't need the modified kernel as QEMU emulates intel processors or something
But anyway, just search a hackingtosh distro it should have it
I would not suggest using a distro by any means, more often than not they're too bloated.
I understand there are existing CPU emulators/code translators like QEMU user mode and Unicorn, but I was just reading about a technology called PowerVM Lx86 which was used commercially by IBM to run x86 (32bit) instructions on their p series POWER architecture. It was developed by the same people who licensed Rosetta to Apple.
It used instruction caching without environment emulation to allow the POWER architecture to seamlessly run Intel code. It makes me wonder if there was source code floating around the net for this for some clever individual to port to Mac/PPC.
Given it is simply the inverse of Rosetta, something like this would open up massive software options to PPC, even if it did run that bit slower.
It used instruction caching without environment emulation to allow the POWER architecture to seamlessly run Intel code. It makes me wonder if there was source code floating around the net for this for some clever individual to port to Mac/PPC.
Given it is simply the inverse of Rosetta, something like this would open up massive software options to PPC, even if it did run that bit slower.
Ah the holy grail which was buried by IBM , Transitive created Rosetta indeed and the same inverse technology which was then bought by IBM but buried so they could sell their x86 Linux boxes.
I've been looking for it for the past years but no luck so far, there was alos a version that allowed to run SPARC binaries on x86 which was interesting when Cisco IOU only existed on SPARC in the beginning
The holy grail indeed. One mention was of a demo of PowerVM Lx86 running x86 Quake 2 at near native speeds on a PowerBook G4. Which is probably only barely possible with a G5 via VirtualPC and impossible with QEMU on any PPC host.
Who knows if it's true. But it would theoretically be quite possible.
Some interesting background reading here:
https://web.archive.org/web/20041109090012/http://www.wired.com/news/technology/0,1282,64914,00.html
80% speed of target architecture - that would've been nice
Here's the guy that did it:
Last edited:
I'm guessing it has no use to contact the creator since IBM bought the rights and buried it
https://www.itjungle.com/2011/09/26/tfh092611-story06/
https://www.itjungle.com/2011/09/26/tfh092611-story06/
The professor is easy to contact but yes I'd imagine he'd have the full weight of IBM's legal division on top of him if he even remotely visited those territories again.
The problem with a code translator is that it needs some OS to run first. You can't just run it on bare metal to boot Snow Leopard. At best, you would run it as a "background layer" inside the OS which would translate instructions, like Rosetta.
But even that would need proper OS support, since Mac OS X's Rosetta support had that baked in to act as the intermediary. So to even use something like that on Leopard to be able to run Intel-native software would need deep access to Mac OS X code.
Nope, running an in-OS emulator is really the easiest/best bet.
But even that would need proper OS support, since Mac OS X's Rosetta support had that baked in to act as the intermediary. So to even use something like that on Leopard to be able to run Intel-native software would need deep access to Mac OS X code.
Nope, running an in-OS emulator is really the easiest/best bet.
The difference in performance on VPC7 between G4's and G5's is mainly an endianness issue:
• x86 architecture is little-endian;
• Every ("original") PowerPC processor (which are big endian), from the 601 to the 7448, could in fact switch between big- and little-endian mode;
• From VPC4 onwards (which required a G3) the processor would switch to little endian mode in the context of the emulator instead of emulating reverse-order load-store word(haven't heard the exact reason pre-G3 processors wouldn't, but I think it is because the switch wouldn't be worthwhile, mainly because the G3 has backside L2 cache and a better Branch Processing Unit than his predecessors);
• The PowerPC 970, essentially a POWER4 with an SIMD unit, didn't support endianness switch, stuck at big endian. Therefore, Microsoft added back emulated reverse-order load-store words to the VPC G5 arch code, leaving it there, outperformed by the G4's.
It's also worth saying that the PowerPC ISA has in fact reverse byte-order load-store instructions. But C/C++ compilers aren't taking any advantage from them because they're not implemented on most CPU architectures. Only solution would have been assembly-level.
Plus, VPC cannot use CPU cycles of more than a single processor core. Thus, more than 2 cores won't help at all.
• x86 architecture is little-endian;
• Every ("original") PowerPC processor (which are big endian), from the 601 to the 7448, could in fact switch between big- and little-endian mode;
• From VPC4 onwards (which required a G3) the processor would switch to little endian mode in the context of the emulator instead of emulating reverse-order load-store word(haven't heard the exact reason pre-G3 processors wouldn't, but I think it is because the switch wouldn't be worthwhile, mainly because the G3 has backside L2 cache and a better Branch Processing Unit than his predecessors);
• The PowerPC 970, essentially a POWER4 with an SIMD unit, didn't support endianness switch, stuck at big endian. Therefore, Microsoft added back emulated reverse-order load-store words to the VPC G5 arch code, leaving it there, outperformed by the G4's.
It's also worth saying that the PowerPC ISA has in fact reverse byte-order load-store instructions. But C/C++ compilers aren't taking any advantage from them because they're not implemented on most CPU architectures. Only solution would have been assembly-level.
Plus, VPC cannot use CPU cycles of more than a single processor core. Thus, more than 2 cores won't help at all.
Not even a single version of GCC? Or any other compiler whatsoever?
Slightly offtopic: What would you consider to be the best assembly language compilers (and/or IDEs etc.) for PowerPC 970MP's assembly and PowerPC 970FX's assembly?
I tested WFL against MicroXP - MicroXP won hands down, though it is a chore to get working on hardware as it's so bare, you have to add dlls etc as and when they're needed.
That is the only issue that I forsee with the stripped XP variants, is that they are missing so much of the core files that even some programs will fail to function. Meanwhile, WFL seems to contain all that is necessary to run most any program, at the cost of lower performance.
This is a bit late, but (if you read this) AFAIK GCC absolutely won't. Since this is a hardware-specific case (even among POWER(PC) microprocessors), and C/C++ has a code portability philosophy, I wouldn't expect this to ever be addressed in a standard library. Of course modified functions/libraries are another case. Still, nothing is to be expected.
Thanks for the reply, a pity to know no (known) compiler will address this potential. I guess that leaves us with only one option, as you stated: assembly! I'm cool with that... Just downloaded over the past 30 days thousands upon thousands of pages of IBM and Apple and overall PowerPC & related documentation, especially focusing on the 970MP, to start writing 970MP-specific programs for Tiger and Leopard, with the Quad core (dual 970MP) in mind.
A long road stands before me... But if I come up with anything worthwhile I'll keep you guys updated. (May take over a year. LOL! But I'll be certainly on it, wiring the Shark and other CHUD & non-CHUD tools up!)
A long road stands before me... But if I come up with anything worthwhile I'll keep you guys updated. (May take over a year. LOL! But I'll be certainly on it, wiring the Shark and other CHUD & non-CHUD tools up!)
I don't intend to be mean here but this is no realistic undertaking. What you're talking about absolutely isn't writing some basic for your commodore 64.
This isn't just a matter of specific and carefully chosen instructions: Any statement that sounds like "..assembly language has less latency than compiled code.." will backfire for anything that grows larger than 3-4 modules, time-wise and often performance-wise too. While compiled languages statements will generate more and more of the necessary program structures at once compared to asm, dynamic library functions will still save code length. It also isolates you from instruction scheduling, cache and instruction throughput issues that practically any modern processor architecture has. Most compilers have become aware of these needs in code structure awhile ago.
Although you still can do library functions calls from assembly, there even is a certain learning curve on how to use function calls wisely from object-oriented languages. From there a proper start would be learning the basic powerpc C ABI (OSX doesn't use the same as other unix systems). By the way, to use system calls, learning the C ABI isn't an option. Leaving the debugging details aside and the fact you won't get any help from most communities if needed.
This isn't at all a reason to pay no interest to processor architectures and machine language. It'll end up paying after a moment. This isn't wasting time at all. But in this case you'll also end up learning it's something else than what you're saying here. To use handwritten assembly you must choose your fights. Assembly macros and inline functions combined with a compiled language is probably your best bet. If you go to IBM's own assembly tutorials, you'll see at the very start that they say so themselves.
I'm not lecturing anyone here; just felt like writing some huge paragraphs. I thought something among the lines of your post about 3 years ago myself.
This isn't just a matter of specific and carefully chosen instructions: Any statement that sounds like "..assembly language has less latency than compiled code.." will backfire for anything that grows larger than 3-4 modules, time-wise and often performance-wise too. While compiled languages statements will generate more and more of the necessary program structures at once compared to asm, dynamic library functions will still save code length. It also isolates you from instruction scheduling, cache and instruction throughput issues that practically any modern processor architecture has. Most compilers have become aware of these needs in code structure awhile ago.
Although you still can do library functions calls from assembly, there even is a certain learning curve on how to use function calls wisely from object-oriented languages. From there a proper start would be learning the basic powerpc C ABI (OSX doesn't use the same as other unix systems). By the way, to use system calls, learning the C ABI isn't an option. Leaving the debugging details aside and the fact you won't get any help from most communities if needed.
This isn't at all a reason to pay no interest to processor architectures and machine language. It'll end up paying after a moment. This isn't wasting time at all. But in this case you'll also end up learning it's something else than what you're saying here. To use handwritten assembly you must choose your fights. Assembly macros and inline functions combined with a compiled language is probably your best bet. If you go to IBM's own assembly tutorials, you'll see at the very start that they say so themselves.
I'm not lecturing anyone here; just felt like writing some huge paragraphs. I thought something among the lines of your post about 3 years ago myself.
This thread is FUTILE.. Snow Leopard will never run on a PPC.. unless one got the code and even then that doesn't mean it will work.
Although this doesn't count as OS X, up to Darwin 10.8 (which SL 10.6.8 is built upon) can still target powerpc as an architecture, including the kernel: https://opensource.apple.com/source/xnu/xnu-1504.15.3/config/
powerpc code was officially removed with Lion. Still, truth is snow leopard will not run on a powermac.
Last edited:
This 100%. Although people still have issues compiling that (and newer) versions of Darwin from what I've heard, but there's work being done in that direction, too: http://www.puredarwin.org/
Also @XaPHER, your concerns are perfectly valid, although from the way you worded your post, it seems I came off as incredibly naive. For clarity, my main goal is to get as familiar and intimate with the 970MP as possible, regardless of how fruitless and "backwards" any code I create for it becomes. My point was to simply mention that if (a VERY big "if") anything worthwhile pops out of that process, be it even in years, I'll keep people updated, since I know this kind of passion and love for PowerPC, IBM 970 MP and/or Mac OS X (and earlier) is shared among many here! This is a thread for those that care. I'm positive you relate to this.
I also am completely aware about the pitfalls regarding notions such as the one you mentioned (basically how assembly code can't be written with anywhere near as much performance, in practice, as C code with an optimized compiler, especially as a program's codebase gets larger, and so on), but my approach mandatorily includes always, always writing equivalent:
- Assembly code;
- C with inline assembly code;
- C with zero or an absolute minimum of inline assembly code.
Else I'd have very little metric to be able to measure much of what I'd like to. As for code maintainability, that's currently not so much a priority as the learning process itself, but I believe my OCD-esque level of identation and means of organization may aid me a bit nonetheless!
I don't expect any "BASIC-level" cake walk task. I also am not counting on community support for this, as I know there's nearly none, and for the few good fellows knowledgeable on the matter, I wouldn't want to eat up their precious time with my whimsies.
Lastly, there is this:
"But in this case you'll also end up learning it's something else than what you're saying here."
One way or another, I'm absolutely certain that is true! In fact, I'm diving full head in 100% precisely because I know of this fact too well myself! I believe any well-seasoned developer (or overall learner) knows that's part of the drill. I'm thirsty to feel the horrors of all this and learn from them the hard way!
In any case, I appreciate your input and insight. It is valuable, not only for me, but for anyone else in the future in similar or even different situations.
No offense taken, and I hope I came off as neutral as possible, too.In any case, I appreciate your input and insight. It is valuable, not only for me, but for anyone else in the future in similar or even different situations.
What a positive reaction towards my (usual)cold replies. Well, I fully agree with your explanation. I think as long as expectations do not overgrow The Flow it's worthwhile.
I was kinda the upside-down guy on many levels. I learned how to use raw hexadecimal input as machine language even before learning assembly itself. My experience(s) later became an asset, and a big problem at the same time. Your previous post brought me back there for a short moment. Sorry about that.
Cameron Kaiser has gathered quite a number of observations on the 970 on his TenFourFox blog posts over time as the 970 is often to be treated separately from 'pure' PowerPC processors as it would immensely impact his project's performance on G5-based machines otherwise. Most of that also reminds the G5 is really more a POWER-relative. That's probably good tracks, if not obvious ones.
Just continue experimenting, that's probably all I can say.