Apologies for not responding to this thread in a more timely fashion. I had a flood of emails after the initial post.
Speed OR Portability Adam is closer than he knows about the approach we have taken on z/VOS. First, he is right when he guessed "almost-certainly assembly". We have tried both QEMU and BOCH and you can forget your name before the target OS completes IPL in our current environment. This is not meant to be a criticism. Both of these systems were written for portability rather than platform specific speed. He is also on target about the instruction mapping. Obviously the closer you get to a one to one instruction relationship the better the performance. Pipeline/Instruction Overlap Making the instruction stream pipeline-friendly has been another consideration with z/VOS. David Bond gave a great presentation (Share Session 8192 in August 2006) on this so I leave it to you and Google if you are interested. Single Pass Translation For those of you that think emulation of x86 would be a bad idea, we agree. z/VOS translates guest OS code during initial execution. Code fragment storage, lookup, disposal and reuse for primary and sibling guests are addressed in a patent application. Suffice it to say that we don't interpret or emulate massive amounts of x86 code for use 2-n. z/VOS Development Environment Mantissa has a FLEX development environment that redefines and enhances the definition of "slow". We have two copies of VM operational at all times. One of the VM system supports z/OS and VSE development. The other system is dedicated to z/VOS development. Because Adam mentioned FreeDos, I will give this point of reference. Under z/VOS FreeDOS IPLs in 1 second with all debug logging interfaces enabled. After the IPL, it is split second responsive. --. .- .-. -.-- Gary Dennis Mantissa Corporation On 7/25/08 11:28 AM, "Adam Thornton" <[EMAIL PROTECTED]> wrote: > On Jul 25, 2008, at 8:48 AM, McKown, John wrote: >> >> Somewhat like BOCH? I remember somebody saying that they ran Windows >> on >> BOCH on an old P/390. > > A little more data: the straight-up portable-emulation x86 code-path > is still not a good idea. I got the current released bochs (20080720) > built (with all the cool stuff like x86_64, SSE, plenty of neat > features) on Linux s390x. The build was quite clean, actually. > > It is a lot less painful than on a P/390 or H70, but running Bochs on > a 2094 (z9 of some sort), where z/VM sees 2 CPUs but the Linux guest > has one, is still only giving me 3.4 to 4.0 million (x86) instructions > per second, which is...well, a LOT less than you'd get on a modern > Xeon. That's not to say that I'm necessarily CPU-bound. If I had > time to play with it, the VGA refresh rate is where I'd start, because > that probably isn't helping. > > FreeDOS installation was pokey but not really terrible. Performance > is, well pretty bad; it feels like working over a satellite link in > terms of latency. I think you'd have a really hard time making the > case to management that THIS was a good use for your zSeries. > > So here's hoping that the Mantissa product is focussed around an > efficient (and almost-certainly assembly) x86 emulation. Given the > richness of the s390x instruction set, and that a bunch of the > instructions fundamentally do the same thing in the x86 and the s390x > world (that is, "move something from a memory location to a named > register" is the same concept on either architecture), I would hope > that most of the user-mode instructions can be mapped close to 1-to-1, > and the mere fact of having to create an instruction translator is > going to mean that the actual performance will be several-host- > instructions-to-one-guest-instruction. Complicated instructions are > still going to be slowed significantly, of course. > > Adam > --. .- .-. -.-- Gary Dennis Mantissa Corporation 1121 Edenton Street Birmingham, Alabama 35242-9257 p: 205.968-3942 m: 205.218-3937 f: 205.968.3932 [EMAIL PROTECTED] http://www.mantissa.com http://www.idovos.com
