I will ask Semthex if he is intrested in this project.

That would be awesome, we could use a kernel guru like Semthex

Integrating the SSE2 and SSE3 emulation right into the kernel would give us the ultimate solution. If we can successfully trap the exceptions raised by those missing instructions (and surely we must be able to - given thats how the SSE3 emulation works) and call into routines borrowed from the qemu code, then SSE-only OSx86 will be a reality.

I have no idea how to even begin putting such a thing together, but i'd dearly love to see it

That's what I was thinking when I was first brainstorming the idea of OS X on SSE, but I figured it would require too much work for just a few of us to do. Semthex has the skills to patch it all together, I just hope he is interested.

Semthex being involved would be awesome!! However, one thing I just thought of is that we are going to need to write drivers for all this old hardware that is suddenly opening up to us. Just a thought.

you can replace anything except for the mobo and processor with supported parts.
you've got pci cards, usb devices, sound cards
the only thing that may be incompatible is the cpu and there isn't anything you can do about that. (just buy a p3 with a compatible processor or replace with another)

has anyone downloaded my "PearOS"?

if it works with 10.4.8 i will test on my 800mhz p3

Well, I downloaded the Slax Modules you posted, because I had already downloaded the Slax KillBill Edition.
I"ll try it this weekend, but the problem is my testing machine has SSE2.

You can't use killbill, because it's too big to fit into ram. My version is only 128mb.

i'm downloading now, will test on my athlon 1600+ machine with 768mb ram. will test when done

I will start testing on monday night - next available all nighter window

Why does it have to fit in RAM? Is that faster?

think that one through.

Reading from the cd causes slax to lag. When you copy it to ram it's reading it directly from memory so it will be almost instantaneous.

take a look Mac OS X/Darwin User space emulato(from qemu)

so your kernel will work natively, and all apps runned with qemu-darwin-i386 will be run in on emulated proc(sse2 sse3 emulation i guess)
http://qemu.org/qemu-doc.html#SEC61

That is very interesting. I am going to read more about it tomorrow morning. Sleep time here.

Still sleeping?

what about SSE3 emulation code from bochs ??? doesn´t it works better??

Sorry, I have a physics assessment tomorrow that i've been studying for.

About the user space emulator... I think that using it would increase the speed slightly, but because SSE2 is still being emulated, it will still be far from native speed. But unless we end up doing the SSE2 emulation, this is a good step towards native speed.

About the SSE2 emulator in qemu/bochs... somewhere in that code will be a function that gets the SSE2 instructions and translates them into SSE compatible instructions. I'm sure with a bit of modification, this code could be put into the OS X kernel. But since I don't know how to do that, we have to find someone that is able to do it. We Still don't have a reply from JaS or semthex, so i'm guessing they are either busy with something else, or not interested.

Anyways, after next week I am free from exams (for a while) so I will check up on this and reply more often.

Dragon

dont be sorry, we all appreciate the effort you're putting into this - i was just keen to hear good news

of course your studies should come first.

hopefully JaS or Semthex will becom einterested enough..

http://en.wikipedia.org/wiki/VirtualBox - interesting at all? Its a QEMU-based 'virtualizer' but has dynamic recompilation.

From the wikipedia entry:



Does that sound like it might possibly use QEMU's SSE-emulation code if it hits problems running it natively?

EDIT: Its guest OS page says Darwin doesnt work yet. dammit!

It would be the perfect solution if it worked, but i've already taken a look at VirtualBox and gave up when I saw that it wasn't working with darwin.
For the moment it would be good if some people tried running OS X using the slax I posted and maybe posting if it was slow/fast for them.
It was running at a decent speed for me, and I have a 450mhz p3.

I'm going away on school camp next week, but keep posting so I can read up when I get back.

It seems strange Darwin wont work, given that it supports other BSD unixes. Might give it a try sometime...

Will grab your slax at some point - gotta dig the P3 out of the garage first

I was reading this project since it started. I can help with testing and other things! Now I'm downloading the image at very slow speeds. I hate Megaupload.....

Just FYI, I grabbed VirtualBox and tried it on my hackintosh (Pentium D920, Intel D945 - see sig) and tried to boot the Myzar 10.4.5 disc (only one I had to hand at that moment).

After the BIOS screen, two capital E's appear in the corner and then it does nothing else.

Anyone any idea what this error code (if thats what it is) signifies in the darwin bootloader? I figured we could perhaps grab the opensource version of VirtualBox and set about fixing the Darwin support. I have a sneaking suspicion that its only listed as not working because there is some problem with the bootloader. If we could get it to work, and if it does indeed emulate SSE2/3 on SSE1 hardware, we'd be set

EDIT: I guess the thing to do would be to boot virtualbox on an SSE-only box, boot up an OS that works (ie not darwin/OS X) and try to run something which needs SSE2 and see what happens. If it doesnt emulate the SSE2 instruction, there's no point in continuing with VirtualBox, at least not for our purposes.

It could be the bootloader. it reminds me when lets say, LILO is screwed and it displays L's!!

can anyone point me in the direction of a windows program which *NEEDS* SSE2 ?

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...

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?

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.

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...

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.

That would be a good idea munky. Someone ask semthex if he can do it!

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.

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

hmm... putting sse2 emulation into the Darwin kernel.... daja vu...
http://forum.insanelymac.com/index.php?showtopic=26272

Its deja vu

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.

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).

wow déjà vu....

lol, déjà vu.

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.

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 shit 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?

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...

I'm thinking of it being hard enough to get SSE2 working correctly in the kernel. SSE to SSE3 sounds even more painful.

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.

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.

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.

Have you downloaded my SLAX iso?