Path: utzoo!attcan!uunet!microsoft!brianw From: brianw@microsoft.UUCP (Brian Willoughby) Newsgroups: comp.sys.apple Subject: Re: Computer languages on the various Apple Corp computers Summary: A few things people need to realize about the 65xxx Message-ID: <5806@microsoft.UUCP> Date: 24 May 89 19:04:56 GMT References: <8905211959.AA07195@crash.cts.com> Reply-To: brianw@microsoft.UUCP (Brian Willoughby) Organization: Microsoft Corp., Redmond WA Lines: 80 In article <8905211959.AA07195@crash.cts.com> pnet01!pro-nsfmat!pro-europa!nelson@nosc.mil writes: >David Wood (cs472226@umbc5.umbc.edu (I think)), in his posting concerning the >latest APDA log, brought up the fact that there are more languages for the Mac >and the GS than the //. > >The reason for this is simple - high-level languages are terribly impractical >on the 6502 based //. They are fairly tough to make run on the 65816. Take a >look at Aztec C sometime on a //e - its miserable. For the same price >one can purchase a halfway decent IBM (yech) system that will run Turbo C 2.0, >a quite wonderful package. The // line lacks the power to effectively run high >level languages.. > >nelson@pro-europa.cts.com cogito ergo non sum >...!crash!pnet01!pro-nsfmat!pro-europa!nelson I must disagree with the above statement on several counts: First of all, Aztec C could be much improved, even on a 6502-based //e. A great deal of time is wasted pushing objects on the 'real' stack, only to COPY them byte-by-byte to a software stack. I must admit that a software stack is slower, but it can be optimized better than in Aztec. Also, the A,X and Y registers are loaded with preset values at each function boundary (i.e. when a function returns), thus prohibiting register passing of variables. I got so tired of the slow text from Aztec's printf() that I hand-coded an assembly language version that followed the same C protocols of a control statement and variable parameters. The result: my printf() fills the entire screen with text in the blink of an eye. If only I had time to rewrite the entire library, but then the rest of the code wouldn't be optimized, either. We need a newer generation C compiler for the non-GS. Second, the 65816 overcomes several of the remaining restrictions to high level languages on the 6502. There are 128 variable size 'register' variables that can be instantly switched by reloading the Direct Page pointer. The stack is a true 16 bits, allowing faster and smaller code for dealing with the stack. Also, several 16 bit push instructions have been added for pushing addresses and relative addresses - perfect for pushing string addresses in C. The 65816 also runs up to 8 MHz, which competes with a fictional IBM/XT running at 38.16 MHz (considering that the 4.77 MHz 8086 was stomped by a 1 MHz 6502). Of course the 80386 is more efficient (takes fewer clock cycles to do the same thing) than an 8086, so this figure would have to be adjusted. Third, regarding the IBM. The 80x86 programming model does not include general purpose registers, has a segmented architecture and breaks a few other C standards. You don't get the full speed of general purpose registers (like on the 68000) because the C 'register' is implemented by moving SI and DI registers back and forth between the working registers AX, BX, CX and DX. This lack of processor power didn't stop Borlin from creating a C which added support for segmented address (a real pain when your program grows outside of 64K, or the data area grows beyond 64K, OR the stack gets too much pushed on it). The 8086 is quite inefficient with data larger than 64K, because every address must load two registers before you can access it. Finally, (since some of you will obviously point out that the PC-based software runs faster) the reason the Apple II suffers in high-level languages is that a far smaller group has been attacking the problem when compared to the PC clones. Microsoft, Borlin, several smaller companies, and IBM themselves have devoted a greater number of people to overcome the problems with the 80x86. The result being that I can use Turbo C to generate better assembly code (usually) than I could hand-code. It is inexcusable that I can find several errors in efficiency when looking at Aztec C's Apple II code output. Being an EE, I have never written a compiler, but it seems like some of the wizards of the CS field could do much better if they wrote a REAL compiler for the Apple II. P.S. the PRICE of a IBM PC clone system, or of a PC-based compiler, has nothing to do with high-level languages on the II. It just happens that there is (unfortunately) a higher demand for the PC, so it gets most of the attention, and all the discounts of high volume. With the Apple II, its a Catch 22; no one writes software because of the lack of decent high-level language support, and no one writes serious compilers because there isn't a high market (yet) for writing programs on the II (at least not compared to the money they'll make on compatible software). Brian Willoughby ...!uw-beaver!microsoft!brianw or microsoft!brianw@uunet.UU.NET or just brianw@microsoft.UUCP