Re: Basic compiler

[pausch@saaf.se (Paul Schlyter)]

In article <9dmdnT8HA7U7_aPYnZ2dnUVZ_v-dnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

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

I fully agree with that.  Perhaps I expressed myself unclearly, but
I really meant pseudo-code which needs to be interpreted, rather than
machine code which mostly is a long string of CALL instructions.
 
>>>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.

Perhaps good ol' Integer Basic would then be a better language?
It has (only) integer arithmetic.

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

It does -- but Flash does not compile to 6502 machine code, but to
a Forth-like threaded code.  But that pseudo-code is interpreted
much more rapidly than Integer Basic programs.

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

Actually, Apple once made an effort to use the "R" file type in Apple
DOS, for relocatable 6502 object code.  That code was not executable
though until it had ben processed by a linker.

There was even a third-party Linker utility, which could be used with
any Apple II assembler.  Linker required you to follow specific
conventions in your assembly code, to mark and name entry points,
calls to external routines, and to mark blocks of code, relocatable
data, and non-relocatable data.  You could then build a library of
routines, where each routine resided in its own binary file.  Linker
linked it all together into one signle binary file, and could relocate
library modules but only by even multiples of 256 bytes.
 
>>>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.

With only 48K RAM available, that's an understandable trade-off.

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

Such comparisons were made back in the 1980's, and as far as I
remember, Microsoft's TASC (The AppleSoft Compilter) was the winner in
runtime speed but was much slower than all the others in compilation
speed.  Expediter II (the "Einstein" compiler) came second in runtime
speed, and was among the fastest in compilation speed.
 
>>>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.

What I meant is that it's not really fun to strain the ability of your
hardware, e.g. by writing huge programs which need 4711 chained modules
to fit at all.  Back in the early 1980's it could be understandable,
because then perhaps you couldn't afford more powerful hardware.  Today
that situation is drastically different.

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