[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Basic compiler

Paul Schlyter wrote:

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.


I was responding to your statement that appeared to contrast
compilers that loaded runtime packages with those that ran
"stand-alone" code.

Frankly, whether or not the runtime is included in the same file
as the executable is pretty irrelevant (except that many such programs
on a disk will require more space than a system that loads the runtime
as a separate file).


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?


Of course not, as I've commented elswhere in this thread.

But there's a big difference between a large, fixed-size runtime
and a "present only if used" runtime, particularly for simple
programs.

This seemed to be the point raised by the OP, to which I was
responding.


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.


But most Applesoft compilers understood the "%" integer datatype
(or had other REM-like declarations) to specify 16-bit integer
arithmetic, not floating-point.  It is reasonable to expand 16-bit
integer arithmetic, moves, and compares in-line.

In fact, for many "controller" apps, most of the program logic
could be expressed quite nicely in terms of 16-bit data and
operations, and something approximating real machine code could
be achieved.


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.


Exactly.  So the issue is whether the program can be largely
expressed as operations involving 16-bit integers.  (Which reminds
me, has the OP considered the Flash *Integer BASIC* compiler?  I'll
bet it does a pretty reasonable job.)


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....


I agree that it is non-trivial, and I know of no Apple BASIC compiler
that emits assembly code, which would solve that problem simply by
appending the required runtime routines to the assembly.

There are ways to handle it without reassembly, like writing
location-independent 6502 code (not bad for short non-self-modifying
routines), but they can cost speed, which is a problem.


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.


Of course, every language system has runtime libraries for complex
operations, but many Apple compiler writers seem to have been so
concerned with code expansion that they made their implementations
little more than calls to interpretive execution routines.


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


It would be quite interesting to see comparisons of code generated
by various compilers for the Apple II.  I expect there are some
significant differences.


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.


Sure, but that goes a bit beyond the scope of both this forum and
the OP's question...

There's quite a gap between the speed of interpreted Applesoft,
the speed of machine code on an Apple II, and the speed of modern
machines--plenty of room for applications in each speed range.

-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."