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

Re: ProDOS Plus

mdj wrote:

On Jul 1, 5:03 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:



It's most certainly practical. Indeed, Apple Pascal is an
implementation of such an idea, albeit without the optimisation phase.



It should be noted however that Apple Pascal manages to use the entire
language card and then some to provide a pseudo-machine plus an
operating system that is considerably less sophisticated that ProDOS.


But the P-code interpreter is fully general-purpose, and relatively
low in semantic level.  Perhaps one could do much better for the
primitive operations of an OS, which need not be general purpose
at all.  For example, a single page could hold all the parameters,
variables, and pointers needed by the system.  A single operation
could gather all the parameters of a system call into the data area,
etc.

As a result, only a few bits would be needed to specify most operands,
and the operations could be quite semantically rich.  The question is
how much of the "test a bit/clear a field" code could be dealt with
in this way.



I agree. I'm just having a bit of trouble finding the 'seed thought'
of what these operations would be that provided enough compaction to
justify it. In the general p-Machine case, you've got the entire
semantic model of a high level language to work with. Were ProDOS
written in a high level language and compiled I'd agree, there's a lot
of room for shrinkage. However, it's hand coded, so a lot of the
redundancy and indirection caused by higher level languages just isn't
going to be there.

I fear that there's few enough cases that hand tuned machine code that
uses subroutines intelligently will probably end up being smaller. As
we all know, hand-crafted low level code can produce glorious cut
gems, and given the number of revisions ProDOS has had, it seems
unlikely there's a rich field of rough diamond to work with.

I would *love* to be proven wrong on this ...


I understand your concern.  I don't suspect ProDOS of being inefficient
code.

But I do think that it could be written more compactly in terms of a
different virtual machine.  This would preserve the functional behavior
of ProDOS while perhaps radically altering its internal data structures.

To accomplish this, certain limitations might be imposed that would not
impact practical use, like limiting open files to 8 or 16, for example.

<snip>


ProDOS 8 does a pretty good job of exploiting the 128k Apple II
platform, and there's little functionality you can practically add to
it within those constraints, with the exception of a couple of small
behavioral mods to remove some limitations.


It might be good to deal with those mods first.  ;-)



Agreed!



And ProDOS is really a 64K OS--128K is optional.



Yes. I think the decision to leave it as such and just establish
simple conventions for the other bank probably resulted in a lot more
available memory to programs than if they'd decided to make memory
management an OS level function.


A simple memory manager could have fit in half of AUX mem "bank 2".


<<snip>>



I agree, but note that there is not even a "steady trickle" of new
software for our platforms that is intended for general use.



Perhaps just as bad is the inability to extend existing application
functionality. Maintenance is an often overlooked process in software
development. I'm guilty of this myself as I often get occupied with yet
another project or some other task. Perhaps that is the difference in a
'hack' like myself and real programmers.



Overlooking maintenance has caused a lot of bad ideas to be
implemented, then depended on, only to become financial/productivity/
growth issues. This is *the* biggest recurring nasty surprise in the
software development industry.


The chain of temporal dependencies between levels of developers and
users almost *guarantees* that problems found will be worked around,
often in regrettable ways.  Most developers are unwilling to hold up
their money-making application until the OS or library guys fix a
problem properly.

At some point, one must acknowledge an unchangeable property of the
meta-system, and find ways to live with what will not change.  Kludges
are forever.  So it goes.

Once in a great while, it used to be possible to start over, "knowing
what we know now", and correct (many) system design problems.  I know
that is still the case, but the time constant may be much longer.



This is why systems built from simpler layers have greater longevity
than those that don't - the layered approach permits many limitations
to be engineered out without a codebase revolution.


But it seldom permits fixing errors in the layering itself.

Interfaces last a lot longer than implementations, and widely-used
interfaces have lives proportional to the number of their users.


I once heard the British software engineer Brian Randell say of such
a situation, "The theory of evolution, not revolution, is actually a
theory of fewer and bloodier revolutions."



:-) very true.



Eventually, we will be running systems that will not run any of the
code we are running today, but the capabilities of that system may
still be shaped by the limitations we forged today.

"New axe head, new axe handle--same axe."



Unix (in the broad sense of the term) is a great example of this. Code
written for a 1990-era box likely won't run on todays boxes without a
few modifications here and there to the source but are usually minor.
But great revolutions that sacrificed majority source level
compatibility have never been required since the whole system is a
taxonomy of KISS solutions.


The basic interface concepts of Unix were very simple and, as it turns
out, quite robust!

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