Re: Basic compiler

["John B. Matthews" <nospam@nospam.com>]

In article <u4SdndTnZPVAJqPYnZ2dnUVZ_vOdnZ2d@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> BluPhoenyx wrote:
> > Michael J. Mahon wrote:
> > 
> >> 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.
> > 
> > An interesting alternative for speed and space would be ProBasic from 
> > Beagle Bros. This modular Applesoft is incredibly powerful and versatile 
> > for many programming tasks. One creates modules from either Applesoft or 
> > Machine language and/or incorporate external modules (as available). 
> > Speed is automatically increased by reducing the number of program lines 
> > in each module.
> 
> Not sure I know what you mean.
> 
> A program must always execute all the statements called for by
> the control flow, regardless of modularization.
> 
> Changing module size could only *add* to the number of module
> crossings required to execute a program, never subtract.
> 
> -michael

IIRC, when branching forward, Applesoft has to walk the pointers from 
one line to the next until the target line is located. I seem to recall 
some effort devoted to optimization by moving oft-used routines to the 
beginning of the program. Might this effect produce the (presumed) 
speedup for small modules?

Still, I have to wonder if the long disk-swap times wouldn't swamp the 
effect, at least when running from floppy.

-- 
John Matthews
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/