(MoC) Posted February 26, 2007 Share Posted February 26, 2007 It could be the bootloader. it reminds me when lets say, LILO is screwed and it displays L's!! Link to comment Share on other sites More sharing options...
munky Posted March 1, 2007 Share Posted March 1, 2007 can anyone point me in the direction of a windows program which *NEEDS* SSE2 ? Link to comment Share on other sites More sharing options...
Dragon Posted March 2, 2007 Author Share Posted March 2, 2007 hey, just got back from school camp. i found a seti@home client which uses sse2 http://setiweb.ssl.berkeley.edu/forum_thread.php?id=15102 going to sleep for a bit now... Link to comment Share on other sites More sharing options...
Embio Posted March 3, 2007 Share Posted March 3, 2007 The reason OS X needs SSE2 and SSE3 is that Apple never intended for it to be run on something without, so why not utilise them? Link to comment Share on other sites More sharing options...
munky Posted March 3, 2007 Share Posted March 3, 2007 uh... yeah, we know that...? the point is that we should be able to emulate the SSE2 and SSE3 instructions on a non-SSE2/3 capable processor at reasonable speed, and thus open up running Mac OS X on machines which would otherwise have no hope. nice work dragon - i'll try out VirtualBox with XP SP2 and one of those SSE2 or SSE3 binaries. Link to comment Share on other sites More sharing options...
Guest bikedude880 Posted March 3, 2007 Share Posted March 3, 2007 Well then, someone might want to get to work with coding it in ASM... otherwise you're gonna have a hell of a time... heck, you'll even have a hell of a time writing an emulator in ASM... it would be over 100,000 lines... Link to comment Share on other sites More sharing options...
munky Posted March 3, 2007 Share Posted March 3, 2007 Well, QEMU is out there already, and can emulate SSE2/3 on non-SSE hardware... so I dont see why you think its so impossible. QEMU is open-source, so theoretically the emulation code could be integrated into a custom mach_kernel which could allow Mac OS X to run on non-SSE2 hardware directly. Link to comment Share on other sites More sharing options...
(MoC) Posted March 4, 2007 Share Posted March 4, 2007 That would be a good idea munky. Someone ask semthex if he can do it! Link to comment Share on other sites More sharing options...
Dragon Posted March 4, 2007 Author Share Posted March 4, 2007 Looks like somebody isn't reading previous posts... *points fingers at bikedude880 and MasterofComputers* JaS posted a message saying that he was going to chat with Semthex about it, but neither have replied yet. Link to comment Share on other sites More sharing options...
Embio Posted March 4, 2007 Share Posted March 4, 2007 thats what I suggested on the old thread munky, and I think its the best solution. But we need someone like Semthex that knows the source code backwards to tell us if its possible or not - I'm guessing we missed a step somewhere Link to comment Share on other sites More sharing options...
SenVa Posted March 4, 2007 Share Posted March 4, 2007 hmm... putting sse2 emulation into the Darwin kernel.... daja vu... http://forum.insanelymac.com/index.php?showtopic=26272 Link to comment Share on other sites More sharing options...
(MoC) Posted March 5, 2007 Share Posted March 5, 2007 Its deja vu Link to comment Share on other sites More sharing options...
SenVa Posted March 5, 2007 Share Posted March 5, 2007 pshh... whatever. Has anyone got qemu to run a semthex kernel? I seem to get kernel panics for them, but I'm able to run the official darwin kernel. Link to comment Share on other sites More sharing options...
Dragon Posted March 5, 2007 Author Share Posted March 5, 2007 haven't tried semthex kernel yet, but 10.4.1/3/5/6 works fine. btw SenVa, there is no 10.4.0 for x86 (just the kernel). Link to comment Share on other sites More sharing options...
consolation Posted March 5, 2007 Share Posted March 5, 2007 Its deja vu wow déjà vu.... Link to comment Share on other sites More sharing options...
Dragon Posted March 5, 2007 Author Share Posted March 5, 2007 lol, déjà vu. Link to comment Share on other sites More sharing options...
JCC Posted March 5, 2007 Share Posted March 5, 2007 Ok, I guess I need to step in now, just kidding. I know most of you have probably done a lot of homework but a few things: 1. Straight QEMU PPC emulation doesn't run OSX PPC. 2. Straight QEMU x86 emulation is slightly faster then BOCHS (which is by far a better x86 emulator) 3. Straight QEMU x86 running OSX x86 vs PearPC running OSX PPC will probably lose to the PearPC since emulating a G3 (PPC's target platform though some G4 is implimented) is a lot easier then emulating the x86 extremely bad evolution 4. QVM86 is buggy and is not maintained anymore. KQEMU is mostly closed source and has many licensing issues. 5. Using a hypervisor method is out of the question since that requires VTX or AMDV which are both way past SSE in the evolutionary chain Ok that said. If you are going to use QEMU with KQEMU which is way faster the PearPC then are you going to use the SDL interface or a X widget interface? If you are going to use X then is 3d acceleration an issue? If not then kdrive anyone? If SDL vesafb anyone? Boot process once kernel loads should be 5-10 seconds depending on the IDE bus scan of the platform's IDE driver. The funny thing is that all drivers should be made as modules and then wrapped into a cpiogz file that is then embedded into the kernel so that the entire boot process is 1 file. The init process could be busybox.... actually it should be busybox with a few shell scripts. Autodetection could be done by knoppix hwdetect tool which is gpled and already ported over to so many version of linux. I don't see why this couldn't be done under 20-30mb of ram and storage, bearing that the whole OS is in ram. You could even shave off 10MB if you dropped GLIBC in favor of uclibc. So where do you guys want me to post the rough draft of the howto? BTW we need to answer a few questions 1st since I don't want to write a howto that takes many if directions like if you want uclibc do this, if you want to use X over SDL do this, etc. Also what about wifi nics? A few things to ponder. Also will the project leads PM so I can clearify that I'm not making an ASS out of myself by doing something you guys don't want or aren't looking for. Link to comment Share on other sites More sharing options...
munky Posted March 5, 2007 Share Posted March 5, 2007 I guess this thread has evolved into two main areas of thinking: 1) Hardware -> Minimalist Linux -> QEMU/BOCHS -> Mac OS X 2) Hardware -> Mac OS X + SSE2+3 emulator kernel The idea behind #2 (my favoured approach) goes something like this: If QEMU can emulate the SSE2 and SSE3 instruction set, and is open source, couldnt we theoretically take that emulation code and insert it into the XNU (mach_kernel) source (which is also open source) to trap errors which occour when things call SSE2 or 3 opcodes, and invoke the correct emulation functions instead? 'Proof' that such a thing could work exists in the form of Semthex's SSE2 kernel - it already traps and emulates SSE3 instructions on processors who lack SSE3. Now, since SSE3 is somehting like 13 instructions, thats not too bad. SSE2 however is something like 144 instructions, so obviously its a much bigger challenge. The code should exist in the QEMU source, however, so theoretically 'all' we need to do is figure out how to integrate it as an SSE2/3 emulator in place of Semthex's SSE3 emulator in the mach_kernel (XNU) source. It would be interesting to know how much overhead will be involved, and how much slower it will be. But I guess if it runs at usable speed on a P3 machine running Linux + QEMU, then surely it will run better than that native? Finally, I wanted to say, just because doing it this way would be my favoured approach, doesnt mean i'm trying to {censored} on the work done by Dragon et al in pursuing option 1, which in the short term at least, is far more viable. I think both options should be pursued. However, what we lack for #2 is a kernel haXx0r. I'd love to be able to rise to the challenge, but my spare time is severely limited, and I think others would be able to get up to speed quicker than I could. Anyone want to take the challenge? Link to comment Share on other sites More sharing options...
joe75 Posted March 5, 2007 Share Posted March 5, 2007 (edited) I think it would be too hard to get all the emulated instructions running at any kind of usable speed in a kernel hack I know Dragon has allot of time wrapped up in this, but it would be beneficial to collaborate with JCC Edited March 5, 2007 by joe75 Link to comment Share on other sites More sharing options...
munky Posted March 5, 2007 Share Posted March 5, 2007 I think it would be too hard to get all the emulated instructions running at any kind of usable speed in a kernel hack I know Dragon has allot of time wrapped up in this, but it would be beneficial to collaborate with JCC With respect, that makes no sense. If the emulation is fast enough in QEMU under a linux distro, why shouldnt it be fast enough running native in the kernel? Unless the time taken to trap a missing instruction and emulate it is greater than the time to emulate it all up front anyway, but I doubt it... Link to comment Share on other sites More sharing options...
joe75 Posted March 5, 2007 Share Posted March 5, 2007 With respect, that makes no sense. If the emulation is fast enough in QEMU under a linux distro, why shouldnt it be fast enough running native in the kernel? Unless the time taken to trap a missing instruction and emulate it is greater than the time to emulate it all up front anyway, but I doubt it... I'm thinking of it being hard enough to get SSE2 working correctly in the kernel. SSE to SSE3 sounds even more painful. Link to comment Share on other sites More sharing options...
JCC Posted March 5, 2007 Share Posted March 5, 2007 Putting SSE2 emulation into the XNU kernel I believe is going to be hard if you are using QEMU as the source. The reason is: 1. The QEMU source is a bit hard to follow, sorry to the author but I looked at it more then once and have gotten lost in it. 2. The QEMU emulation is going to be geared towards the QEMU CPU Emulator and not to the XNU kernel's APIs. That being said if anyone is going to do this then I recommend: 1. Get the source for the current SSE3 emulation 2. Use the Intel Ref Docs and do a clean room implimentation of the SSE2 instruction set 3. .... 4. Profit! LOL But seriously I will take a crack at the qemu thin linux distro method sometime tomorrow, I can use one of my smaller custom linux distros as a starting point. The only question I have is that if anyone has a qemu image of osx86 running in it so I don't have to recreate one. All my macs are real macs and I would love to have this CD available to me to use on x86 hardware. The one HUGE advantage to using a virtualization layer is that it doesn't matter what video card, what sound card or what network card you have they will all show up as the same brand, model and version to the mac osx. Link to comment Share on other sites More sharing options...
SenVa Posted March 6, 2007 Share Posted March 6, 2007 (edited) when I said 10.4.0 I meant any version of 10.4... but that doesn't matter. I totally agree with munky about needed to work at both of these options... The emulated way is moving right along, but the sse2 emulation layer defiantly has a way to go... I'd be willing to do what I can... I'm not a kernel hacker, but I could do some work on drivers for older hardware... I guess we wouldn't need that until some thing is done tho. Edited March 6, 2007 by SenVa Link to comment Share on other sites More sharing options...
JCC Posted March 6, 2007 Share Posted March 6, 2007 I simply don't have the time to hack the XNU kernel otherwise I would. That being said I would enjoy the benefits of having the qemu route for my own personal fun. Link to comment Share on other sites More sharing options...
Dragon Posted March 6, 2007 Author Share Posted March 6, 2007 Have you downloaded my SLAX iso? Link to comment Share on other sites More sharing options...
Recommended Posts