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

Re: ProDOS Plus

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?
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.
Probably not. At least not in a 100% compatible environment. However, 100% compatibility may not be attainable in any case. This might depend on how many application developers actually followed Apple's guidelines regarding ProDOS. 

Certainly lots more than followed them for DOS!  ;-)

There's a real advantage to providing an "official" way to do things
that applications frequently want to do.
Even more so for software which expects to function in a (semi-)homogenized OS environment. This is why I understand your concern for 100% compatibility. 


Developers are always out in front, and are the "gatekeepers" for
the user community.  My concern is that the community of both developers
and users is no longer large enough to support a significant OS rollout.
You are probably right. It seems the current level of response to this thread so far seems to prove this point. Of course it hasn't been here very long so this is probably not relevant yet. 


This problem does not arise if a few incremental enhancements are made
while retaining full compatibility.  Then *anyone* can adopt it without
trouble or risk for *existing* applications.
Agreed. One can only hope that future users would consider maintaining the project as well. 


One step at a time. :)


Usually, but there are important exceptions when it comes to systems.

It's just as hard to regression test one change as it is to regression
test ten changes (though it's harder to localize a problem if more than
one change was made ;-).

I advocate "one change at a time" for developers, but several changes
that make a logical package for users.

The pain of updates should be minimized, and spread out months apart.
(Fixes for show-stopping bugs are another matter.)


Agreed.

Cheers,
Mike T