> Software for the Macintosh was, and is, mostly written in C > (or C++). This made the switch much easier, especially since > much of the OS itself was written in C++. Actually I think > there was a lot of old Pascal code that was re-written in C++ > for the PPC port.
I would think it wasn't the language the software was written in, but how Apple forced you to access system resources via a well-defined API that made it easy to change the CPU architecture -- and deliberately broke things if you circumvented the API. Remember the woes software vendors had when the Mac II came out and all their neat hacks to go around the ROM routines broke miserably? That was *deliberate*, and most of the vendors learned their lesson. After that, changing the CPU architecture wasn't all that hard -- you set up the same structures using the new archictecture instructions, and jumped into the ROMs. > Much of z/OS seems to be written in assembly language. I > wonder how much work it would be to re-write this into C, or > any other language. I think that interpreting 370 machine > code would be too slow, even on a 3GHz system. It would > almost be like running Hercules on a 3GHz Pentium. Although if you use processor microcode to make the CPU execute the 390 instruction set instead of the PPC, it's not emulation, and the processor runs at or near rated speed. A group at the University of Utah did a similar trick with emulating the DECSystem-20 on the Alpha by using the ability of the Alpha to handle unimplemented instructions via microcode. The processor ran DEC-20 instructions natively, but was physically a Alpha chipset. Microcoding a CPU is non-trivial, but not impossible -- especially if you're the vendor. > I am thinking that the Register may have misunderstood IBMs statement. Even if they did, it's still a good idea...8-) -- db
