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

Re: Basic compiler

finksterj wrote:

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.


It's going to be near impossible to beat the space efficiency of
an interpretive system.  Small "code" size was a primary design
objective for microcomputer BASICs.

So, is your problem that the program you want to run is
very large (in which case, as Paul points out, a compiler
is not the answer)?  Or very slow?

If it's slow, then it is quite likely that a very little bit
of machine code would do wonders to speed it up.

Applesoft can CHAIN programs quite nicely, too.

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