Re: Basic compiler

[pausch@saaf.se (Paul Schlyter)]

In article <LcWdnWeI_a3-nKDYnZ2dnUVZ_oudnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

> Paul Schlyter wrote:
>> In article <RJSdnZaZsbfEtaHYnZ2dnUVZ_tSdnZ2d@comcast.com>,
>> Michael J. Mahon <mjmahon@aol.com> wrote:
>> 
>>>Unlike most 8-bit microcontrollers today, the 6502 has *very* few
>>>*real* compilers (that compile to machine language).
>> 
>> There were some though.  Two Applesoft compilers which produced
>> stand-alone executables in machine code were the "Einstein Compiler"
>> (aka "Expediter II"), and Microsoft's TASC (The AppleSoft Compiler).
> 
> Both of those either loaded or "compiled in" runtimes.

:-) ....virtually any compiler will have runtime libraries which are
linked in with the compiled code to produce a stand-alone executable.
Remember good ol' Turbo Pascal for CP/M?  The first 8 kBytes of any
.COM file produced by Turbo Pascal was the runtime library.

> The "machine code" that they produced was mostly calls to
> runtime routines.

That was the norm of code for 8-bit CPU's generated by compilers:
after all, these CPU's had a quite limited instruction set, so mostly
anything beyond integer add and subtract was done by calling a
subroutine in the runtime library.  You wouldn't expect floating-point
arithmetic to be performed by 6502 inline code, would you?

Also, since Applesoft has no integer arithmetic (all arithmetic is
done in floating-point in Applesoft), there isn't much you can inline
when compiling Applesoft to 6502 machine code -- unless you want a
REALLY bloated Applesoft program, where each and every arithmetic
operation would take some 500 bytes of machine code!  With such
bloated code, you wouldn't be able to do much within 48K of memory.

> While this is to be expected as a time-for-space tradeoff for
> large programs, it results in code that is much inferior to
> the in-line code that most people associate with compilation
> to machine language.

With modern CPU's which have much more powerful instruction sets,
one can do much more with inline code.  But if the inline code
for one single operation would occupy hundreds of bytes, the
overhead of putting it in a subroutine would be quite negligible.

> In fact, the architecture of the 6502 pretty much dictates this
> kind of approach, though it would have been possible to only load
> the parts of the runtime that were actually needed instead of the
> whole thing, as is usually done.

Loading runtime libraries "as needed" as you suggest here would
require relocation of machine code to the addresses currently
avaiable - and code relocation is another weak point of the 6502....

> My point is that there are no BASIC compilers that I know of for
> the Apple II that will compile *directly* to *in-line* machine code.

Indeed very true --- and I don't think you'll find such a BASIC
compiler for any other system either.  They all have runtime libraries.

Nevertheless, Applesoft programs compiled with Expediter II runs many
times faster than the same program run on the Applesoft Interpreter.

> If you really feel you need the "level" of BASIC and the speed of
> machine language, then your best approximation will probably be one
> of the BASIC-like macro assembler packages.  I believe that Nibble
> offered such a package (maybe "Macrosoft"?).

If you really need that speed, you should forget about the Apple II
and go for a modern computer instead!  An interpreted language on a
modern CPU runs much faster than even the most skillfully hand
optimized assembly code for the 6502 -- after all, Apple II emulators
nowadays run some 10+ times faster than the original hardware.
 
> -michael
> 
> NadaNet networking for Apple II computers!
> Home page:  http://members.aol.com/MJMahon/
> 
> "The wastebasket is our most important design
> tool--and it's seriously underused."
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/