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

Re: Basic compiler



Michael J. Mahon wrote:
> Paul Schlyter wrote:
> > In article <RJSdnZaZsbfEtaHYnZ2dnUVZ_tSdnZ2d@comcast.com>,
> > Michael J. Mahon <mjmahon@aol.com> wrote:
> >
> >
> >>art wrote:
> >>
> >>>Hello all,
> >>>
> >>>I have joined this group in hopes to get back up to speed as I picked
> >>>up a couple of apple IIes to use as embedded controllers.  Does anyone
> >>>know where I can get a copy with manual of a BASIC compiler that will
> >>>produce executable code?
> >>
> >>Just out of curiosity, is your program so big and so slow that
> >>you need to compile it, as opposed to just running it in Applesoft?
> >
> >
> > .....well, if the program is too BIG to run in Applesoft, compiling it will
> > just make matters worse, since after compilation the program will become
> > even bigger - at least if you compile it to machine code.
>
> Right--I should have just said "slow".  ;-)
>
> >>If you have a few routines that need machine language speed, they
> >>can be easily crafted in an assembler and called from BASIC.
> >>
> >>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.
> The "machine code" that they produced was mostly calls to
> runtime routines.
>
> 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.
>
> 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.
>
> 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.
>
> 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"?).
>
> -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."

You're right about those older BASIC compilers creating code that was
much larger than the original because of the runtime libraries added.
On the other hand, the Beagle Compiler produces code smaller than the
original, but you need the COMPILER.SYSTEM to run them.

Although Macrosoft doesn't add a runtime library, it still produces
code that is larger than the same Applesoft code-typically 3-5X or
larger. Of course the limitation of Macrosoft is you have to convert
your Applesoft code and use the Mindcraft Assembler, but it produces
standalone code.

As the Beagle COMPILER.SYSTEM is about 6-7K larger than BASIC.SYSTEM,
depending on how many programs you need compiled, I think the Beagle
Compiler is probably more space-efficient than the older compilers that
added a runtime package to each program compiled (which typically was
about 15K).

I know the Beagle Compiler can "chain" multiple programs together, so
the limitation on program size is moot as you can split your code into
smaller segments and chain them using common variables.