Re: ProDOS Plus

["Michael J. Mahon" <mjmahon@aol.com>]

BluPhoenyx wrote:
> Michael J. Mahon wrote:
>
> > Much of the ProDOS "RWTS" would certainly have to be machine code, since
> > it is timing critical.  But virtually everything else can run at almost
> > any speed, and most of ProDOS is never used by any one application.
>
>
> This is pretty much how I understand the kernel to be. I'm guessing this 
> interpreter is based on tokens, correct?

Most interpreters work from a stream of "operations" and "operands",
constructed according to a simple syntax.  The semantic level of the
operations should be as high as possible consistent with minimizing
the number required and the amount of decoding required.

For a recursive-descent compiler, the usual operands were indexes to
stacks or streams (input, listing, and object code streams).  The
appropriate operations and operands for a disk OS is an open question.

A general consideration is that most of the interpreted operations
should be at a sufficiently high semantic level that most of the time
spent in fetching and executing them is in their execute phase.  It
would be costly to have many operations that are at essentially the
same semantic level as the host machine's native opcodes.

> > > Well that certainly limits things but I think it would be a 
> > > subjective matter based on the enthusiast's enthusiasm level.
> >
> >
> > My test is quite simple--can it be reduced to practice?
>
>
> Ah, absolute practicality. A point of view which even I can understand. :)
>
> > Properly applied, interpretation only slows down infrequent paths,
> > so the actual user-perceived performance impact can be quite low--
> > particularly since interpretation "gives back" RAM that can be used
> > to speed up overall functioning (or to add more functionality).
>
> ....
>
> > Some profiling of ProDOS while running typical apps would be very
> > helpful in assessing what needs to be fast and what doesn't.  Of course,
> > that profile will differ from application to application, but if there
> > is a substantial commonality, it can be statically exploited.
> >
> > The ultimate way of tuning this approach to a *variable* profile
> > (a result of running different loads) is an adaptive approach in
> > which an interpretive routine counts its executions and at some
> > threshold, it swaps in a less-interpretive version of itself.
> >
> > To complete the picture, the less-interpretive routines also count
> > their frequencies, and if they drop below a threshold, they swap
> > in the more-interpretive version of themselves.
> >
> > Taken to the limit, this is profile-driven dynamic optimization with
> > code caching, but that approach seems impractical for an Apple II OS.
>
>
> This is an interesting idea for the proper hardware but you are correct, 
> the II needs something simpler.

But simple counting and segment swapping, with the goal of reaching
a no-swapping equilibrium, is well within the parameters of a feasible
Apple II implementation.

To minimize overhead, one would only need to count relatively costly
operations, not the cheap ones.  Only every hundred (or 256?) counts
would decisions be made about whether or not to swap segments, so the
decision overhead would be amortized over many executions.

If the counts were cleared at each decision time, then 1-byte counters
would be fine, and simple thresholds would respond to the relative
frequencies of the operations.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."