• OS emulation [was Re: Bootcamp]

    From Rich Alderson@21:1/5 to Too many levels to be certain who a on Thu Jul 3 15:14:11 2025
    cross@spitfire.i.gajendra.net (Dan Cross) writes:

    Too many levels to be certain who actually wrote the following quoted by Dan:

    5) The idea of emulating one OS on another OS is questionable
    in itself.

    This really needs to be qualified, as it is common and has been
    done for decades. Evaluation criteria must include a) the
    complexity of the emulation target, and b) its alignment with
    the existing system design.

    Agreed.

    Consider PA1050 on TOPS-20, for example: this was a type-2 hypervisor that allowed the DECSYSTEM-20 to provide very faithful emulation of TOPS-10. But TOPS-20 is argably closer to TOPS-10 than, say, VMS is to Linux.

    Boggle.

    Tops-10 and TENEX/TOPS-20 run on the same base hardware (the PDP-10), and TOPS-20 shares part of its name with Tops-10, but other than that they are entirely unrelated.

    PA1050 (which was written by the BBN folks who created TENEX, the ancestor of TOPS-20), emulates a subset of the system calls of Tops-10, in order to allow utilities like the FORTRAN and COBOL compilers to run on an OS for which they were not engineered. It does this by mapping a set of routines into the user program which then make TOPS-20 system calls invisibly. These routines are mapped in when the first Tops-10 system call (which is in essence an illegal instruction that thereby triggers a trap to the monitor) is encountered in the user program instruction stream.

    PA1050 is, in this sense, not a hypervisor but something equivalent to the Wine emulator on Linux ("Wine Is Not an Emulator", indeed).

    And since TOPS-20 used a different mechanism for trapping into the executive for system requests than TOPS-10, it was easy to distinguish between the two.

    At the base level, no, it does not. It simply uses a different "illegal" instruction to trigger the context switch from user mode to monitor mode than does Tops-10.

    On the other hand, things like gVisor, which emulates the Linux
    kernel interface, are very complex and difficult to get right.
    And of course the PDP-10 was a much simpler machine than x86_64.

    Agreed.

    --
    Rich Alderson news@alderson.users.panix.com
    Audendum est, et veritas investiganda; quam etiamsi non assequamur,
    omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
    --Galen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to news@alderson.users.panix.com on Thu Jul 3 20:32:31 2025
    In article <mddv7o9ccjg.fsf_-_@panix5.panix.com>,
    Rich Alderson <news@alderson.users.panix.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes:

    Too many levels to be certain who actually wrote the following quoted by Dan:

    Arne wrote that part.

    [snip]
    Consider PA1050 on TOPS-20, for example: this was a type-2 hypervisor that >> allowed the DECSYSTEM-20 to provide very faithful emulation of TOPS-10. But >> TOPS-20 is argably closer to TOPS-10 than, say, VMS is to Linux.

    Boggle.

    Tops-10 and TENEX/TOPS-20 run on the same base hardware (the PDP-10), and >TOPS-20 shares part of its name with Tops-10, but other than that they are >entirely unrelated.

    I will definitely defer to you on the specifics, Rich, but I
    should also take my own advice and qualify what I wrote...or at
    least attempt to explain it better.

    What I meant was that, as the machines that both TOPS-10 and
    TOPS-20 ran on, were so much more constrained, and the two
    systems so much smaller, that even though they were (as you
    rightly point out) unrelated, the differences were necessarily
    smaller simply because the total surface area of the two systems
    was so much smaller than either (modern) VMS or Linux.

    PA1050 (which was written by the BBN folks who created TENEX, the ancestor of >TOPS-20), emulates a subset of the system calls of Tops-10, in order to allow >utilities like the FORTRAN and COBOL compilers to run on an OS for which they >were not engineered. It does this by mapping a set of routines into the user >program which then make TOPS-20 system calls invisibly. These routines are >mapped in when the first Tops-10 system call (which is in essence an illegal >instruction that thereby triggers a trap to the monitor) is encountered in the >user program instruction stream.

    PA1050 is, in this sense, not a hypervisor but something equivalent to the Wine
    emulator on Linux ("Wine Is Not an Emulator", indeed).

    I'm going to disagree here. This is almost exactly the
    definition of a type-2 "trap and emulate" hypervisor, a la
    Goldberg's original.

    I've posted this before, but for reference, here's Goldberg's
    definition, as edited to update terminology by Bugnion et al:

    |The implementation requirement specifies that instructions
    |execute directly on the host. It does not indicate how the
    |hypervisor gains control for that subset of instructions that
    |must be interpreted. This may be done either by a program
    |running on the bare host machine or by a program running under
    |some operating system on the host machine. In the case of
    |running under an operating system, the host operating system
    |primitives may be used to simplify writing the virtual machine
    |monitor. Thus, two additional VMM categories arise:
    |
    | * type-1: the VMM runs on a bare machine,
    | * type-2: the VMM runs on an extended host, under the host
    | operating system
    |
    |[...] In both type-1 and type-2 VMM, the VMM creates the
    |virtual machine. However, in a type-1 environment, the VMM on
    |a bare machine must perform the system's scheduling and (real)
    |resource allocation. Thus, the type-1 VMM may include such
    |code not specifically needed for virtualization. In a type-2
    |system, the resource allocation and environment creation
    |functions for virtual machine are more clearly split. The
    |operating system does the normal system resource allocation and
    |provides a standard extended machine.

    With respect to "WINE", I suspect that the "emulator" they're
    referring to code/instruction emulation at the hardware level,
    not emulating the system interface. The terminology here is
    unfortunately somewhat ambiguous, but I imagine they were trying
    to contrast with Wabi, which did do hardware emulation (it
    originally ran on SPARC).

    And since TOPS-20 used a different mechanism for trapping into the executive >> for system requests than TOPS-10, it was easy to distinguish between the two.

    At the base level, no, it does not. It simply uses a different "illegal" >instruction to trigger the context switch from user mode to monitor mode than >does Tops-10.

    Well, picking a different instruction is certainly a different
    mechanism, and is what I meant. The point is that whatever is
    handling the trap in the monitor can look at how it was entered
    to determine how to respond.

    On the other hand, things like gVisor, which emulates the Linux
    kernel interface, are very complex and difficult to get right.
    And of course the PDP-10 was a much simpler machine than x86_64.

    Agreed.

    And to be clear, I consider gVisor a hypervisor, as well.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)