CompuServe Messages

> The biggest advantge with using the 060 over the PPC is code size > and cost. If you look at the PPC/040 apps for the MAC, they have > both the PPC native code as well as the standard 680×0 code… > the result is programs being nearly 3 times the size they once > were. This means that you have to buy more memory to run them > in, and larger hard drives to store them. _NOT_ true. Many people ship their stuff that way because they don't know who will buy it. The installer software can install only 68K version or only PowerPC version or a combined version. The customer can decide what he wants installed on his hard drive! Only the correct version would ever load in RAM! Did you _really_ think a PPC machine would be stupid enough to load the 68K parts of an application into RAM when the native parts were there also? The "Code Fragment Manager" makes sure only the correct code portions get loaded into RAM! Sheesh! <grin> If the user decides to install the combined version onto disk it will be about 30% to 50% larger than a pure 68K version. There are also free utilities to strip out the part you don't want on the disk. Pure PPC code is about 30% larger than pure 68K code, but runs 3-10 times faster depending on what you are doing. Memory is cheaper than an accelerator which could run my code that fast. Since a PowerPC chip is _cheaper_ for a specific power level than a 68060 is, I can put the money into more memory and end up lots faster! This saves software houses lots of money because they need only a single distribution and the dual compiler can compile a single source into 68K and PPC at the same time! This makes it very easy on the developer. Consider a "typical" application 1) 68K code 90K 2) PPC code 120K 3) Shared data 150K (strings, constants, data, window resources, etc) The data and resources of my programs are often much bigger than the actual code! The data being shared is the key! Even though a different code set might be carried, the typical data area is very large and makes the extra code not a big deal. Either way, program size does _NOT_ triple! I have several of these combined applications and they range from 30% to 50% larger. Remember they all share the same data area and RISC code does not bloat nearly as you might think. In fact many programs stay the same size when moved to RISC because of the extra registers and more flexible triple operand instructions. This combining of code is a _great_ way to make the transition as painless as possible. I can just move my hardrive from machine to machine and know it will work correctly. I don't have to care what CPU is in it! If the Amiga ever moves to RISC, then I bet they adopt the same solution. You have to make it easy on the customer to not have to care what's under the hood while transitioning to the RISC world. > Also, you will not find every piece of software written for the MAC > in PPC native code anytime soon, if ever. Yes, there will be PPC > native versions of most of the big software, but the base is still > much too large for developers to abandon the millions of 680×0 MACs > already out there. Apple intends to stop selling 68K Macs within two years. In fact, they expect to sell more PPC machines next year than 68K machines. That means that you stick with just 68K only if you want to live in the past and not keep up with a new market eager to buy new software. Building dual core applications is painless and will probably begin to fade in three years as most people make the switch. Those aiming at the older market may stick with that format for several more years. What you advocate is _exactly_ what has made the 80×86 such a PIG! They have to worry about carring a huge amount of CISC baggage. Apple has made the transition fairly easy with the payoff of screaming fast computers here and now. > PPC is fast in the floating point arena. Wow! You finally admit it! <GRIN> Weeks ago you told me that 68060 blew PowerPC out of the water for floating point! What caused this change of heart? <GRIN> > It also has some great >advantages for emulation of 80×86 processors. > For this reason, will we be looking at PPC? Yes. We plan to compete > against Insignia in the PC emulation market (MAC & PowerMAC). Our PC > emulation right now is so much faster than SoftPC, it's silly. It is > a given, to just move this code to the MAC and release it. Yes, the bi-endian load/store and the _killer_ bit masking instructions make PowerPC a real winner for that type thing! But be very careful. You may be able to emulate an 80×86 faster than they can, but they have one ace you don't. They have full source code rights to Windows 3/4.x. They have recompiled Windows to PPC native. Since user code spends much time in Windows, it will run lots of portions native and not need to emulate. If you just emulate 80×86 and ran shrinkwraped 80×86 install of Windows you will _really_ crawl. Do you have the rights to Microsoft source code like Insignia? As Microsoft makes changes they simply have to recompile and they are caught up. —— Andrew