Persistence and Newton OS...

[William Tanksley]

In an article, Fare Rideau <rideau@ens.fr> wrote:
>[Persistence]
>> The reason we're not considering that at the moment is that it's totally out
>> of reach.  The memory needed for that is SRAM or low-power DRAM, which is
>> either enormously expensive or immensely slow.

>Actually, we *are* seriously considering persistence,
>but in a software, not hardware, implementation.

That's what I was just saying.

>   The idea is that "main memory" DRAM should be considered
>as just another cache between computations and persistent storage on disk,
>much like registers and various levels of SRAMs before.
>The fact that DRAM be a software managed cache, not a hardware-managed one,
>is just irrelevant to the user/programmer
>(but the ones who do implement persistence;
>but there are implementers of hardware caches, too, so that's no big deal).

All true.  By the way, why do all of your posts have such odd line lengths?
This post is not that bad, but some of your previous posts have lines that
are so short that they're very difficult for me to read.

>   Of course, we do not guarantee *immediate* flushing of the DRAM "cache"
>into disk (or network store), so that to be resiliant to power shutdowns,
>we must ensure that at any time, a *consistent* version of the system
>is recoverable from disk, no older than some hardware-performance-dependent
>time (typically, from a few seconds to a few minutes).

Yes!  Also, we make no guerantees about the 'togetherness' of the updates;
documents will be statefiled a LOT more often than the global variables of
applications.  Geos has a VERY nice way of doing this :).

>   Feel free to contribute comments, reviews, etc.

Do you have info on Geos?  If not, it would be useful to get at least the
Concepts book from the company's web page -- http://www.geoworks.com.  The
whole thing's available, free, in Acrobat.  There are quite a few suprising
innovations there, as well as some interesting practical compromises (and,
of course, some instructive oversights).  Considering that they started
making this Geos in 1980 (as opposed to their seperate Commodore-Geos), they
did an amazingly good job.

BTW, will Tunes be using NASM for its assembler?  If not, I highly reccomend
it.  It's free, it's modular, and it's very functional.  Dolphin was
translated to it just recently (and Samuel wrote a NASM output module to get
NASM to output in Dolphin run-time-link executable format).

>== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==

-Billy