By: Doug S (foo.delete@this.bar.bar), July 30, 2022 10:43 pm
Room: Moderated Discussions
David Hess (davidwhess.delete@this.gmail.com) on July 30, 2022 3:44 pm wrote:
> David Hess (davidwhess.delete@this.gmail.com) on July 29, 2022 8:59 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 29, 2022 11:20 am wrote:
> > >
> > > You simply don't want a situation where all your memory is your long-term image. The whole "if
> > > you lose power, you reboot and just continue" thing is mindless blathering. Exactly because it
> > > makes a fundamental mistake in assuming that everything is always perfect and bug-free.
> >
> > I have developed small embedded systems which could do that with critical state stored in either EEPROM
> > or CMOS SRAM with backup power. Some old test instrumentation used battery backed up SRAM as main memory,
> > and would pick up exactly where it lost power, but I do not think that would be practical now at least
> > in that way. At the time, common CMOS SRAM was fast enough to be treated as main memory.
> >
> > It is not quite the same thing, but I have done some application programming where it was
> > convenient to keep state on mass storage which allowed the program to be modified and then
> > restarted without interrupting operation. This required an entire section of code for loading
> > external state at startup, and then continuously updating state as required.
>
> Last night I remembered another computer system which could start up exactly where it
> left off after power loss; this was a feature of some systems which used core memory.
> It was a small step from relying on core memory for program and data storage, to including
> circuits to safely shut down and restart after power loss by saving CPU state.
>
> This could also have been done with a microprocessor and CMOS SRAM or even DRAM, but
> I do not remember any systems which did it that way. Someone must have though.
This is before my time but in the core memory days booting was kind of a pain in the ass, was it not? Even if you had the luxury of a hard drive you probably had to either toggle in a bootloader or load it via paper tape.
That was probably the main reason that was used, not necessarily because they wanted to pick up where they left off - but if the PC, SP and registers were themselves stored in a type of core memory (or there was a big capacitor or something allowing a split second for them to be saved to core memory) then I guess theoretically it could simply pick up where it left off once power returns.
> David Hess (davidwhess.delete@this.gmail.com) on July 29, 2022 8:59 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 29, 2022 11:20 am wrote:
> > >
> > > You simply don't want a situation where all your memory is your long-term image. The whole "if
> > > you lose power, you reboot and just continue" thing is mindless blathering. Exactly because it
> > > makes a fundamental mistake in assuming that everything is always perfect and bug-free.
> >
> > I have developed small embedded systems which could do that with critical state stored in either EEPROM
> > or CMOS SRAM with backup power. Some old test instrumentation used battery backed up SRAM as main memory,
> > and would pick up exactly where it lost power, but I do not think that would be practical now at least
> > in that way. At the time, common CMOS SRAM was fast enough to be treated as main memory.
> >
> > It is not quite the same thing, but I have done some application programming where it was
> > convenient to keep state on mass storage which allowed the program to be modified and then
> > restarted without interrupting operation. This required an entire section of code for loading
> > external state at startup, and then continuously updating state as required.
>
> Last night I remembered another computer system which could start up exactly where it
> left off after power loss; this was a feature of some systems which used core memory.
> It was a small step from relying on core memory for program and data storage, to including
> circuits to safely shut down and restart after power loss by saving CPU state.
>
> This could also have been done with a microprocessor and CMOS SRAM or even DRAM, but
> I do not remember any systems which did it that way. Someone must have though.
This is before my time but in the core memory days booting was kind of a pain in the ass, was it not? Even if you had the luxury of a hard drive you probably had to either toggle in a bootloader or load it via paper tape.
That was probably the main reason that was used, not necessarily because they wanted to pick up where they left off - but if the PC, SP and registers were themselves stored in a type of core memory (or there was a big capacitor or something allowing a split second for them to be saved to core memory) then I guess theoretically it could simply pick up where it left off once power returns.
Topic | Posted By | Date |
---|---|---|
RIP Optane/XPoint | Wes Felter | 2022/07/28 07:53 PM |
RIP Optane/XPoint | Rayla | 2022/07/28 08:28 PM |
RIP Optane/XPoint | Doug S | 2022/07/28 09:00 PM |
RIP Optane/XPoint | NoSpammer | 2022/07/29 01:50 AM |
NVDIMM-N | Eric L | 2022/07/29 03:36 AM |
RIP Optane/XPoint | Michael S | 2022/07/29 04:02 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:40 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:43 AM |
RIP Optane/XPoint | Linus Torvalds | 2022/07/29 11:20 AM |
RIP Optane/XPoint | David Hess | 2022/07/29 08:59 PM |
RIP Optane/XPoint | David Hess | 2022/07/30 03:44 PM |
RIP Optane/XPoint | Doug S | 2022/07/30 10:43 PM |
RIP Optane/XPoint | rwessel | 2022/07/31 05:33 AM |
RIP Optane/XPoint | Konrad Schwarz | 2022/08/02 08:06 AM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:24 PM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:26 PM |
RIP Optane/XPoint | Adrian | 2022/08/03 01:19 AM |
RIP Optane/XPoint | anonymou5 | 2022/07/29 12:50 PM |
RIP Optane/XPoint | Gionatan Danti | 2022/07/29 09:09 AM |
RIP Optane/XPoint | Mark Roulo | 2022/07/29 10:02 AM |
RIP Optane/XPoint | dmcq | 2022/07/30 03:42 AM |
RIP Optane/XPoint | anon3 | 2022/07/31 10:19 PM |
RIP Optane/XPoint | anon2 | 2022/07/31 10:55 PM |
RIP Optane/XPoint | Doug S | 2022/08/01 08:37 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 01:33 PM |
RIP Optane/XPoint | NoSpammer | 2022/08/02 03:50 AM |
RIP Optane/XPoint | Doug S | 2022/08/02 09:24 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/02 10:34 AM |
RIP Optane/XPoint | --- | 2022/08/02 10:39 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 03:48 AM |
RIP Optane/XPoint | Michael S | 2022/08/03 06:04 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 08:56 AM |
RIP Optane/XPoint | Adrian | 2022/08/01 02:15 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 06:07 AM |
Losses vs not profitable enough | Mark Roulo | 2022/08/01 10:15 AM |
Losses vs not profitable enough | dmcq | 2022/08/01 11:50 AM |
Losses vs not profitable enough | Gionatan Danti | 2022/08/01 12:34 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 02:47 PM |
RIP Optane/XPoint | Anon | 2022/08/01 03:09 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 03:32 PM |
RIP Optane/XPoint | Groo | 2022/08/01 12:28 PM |
RIP Optane/XPoint | anon3 | 2022/08/01 10:33 PM |
RIP Optane/XPoint | Groo | 2022/08/03 11:15 AM |
RIP Optane/XPoint | --- | 2022/08/03 03:05 PM |
Latency | David Kanter | 2022/07/29 06:35 PM |
Operating system and driver overhead | Eric L | 2022/07/29 03:44 AM |
Operating system and driver overhead | Linus Torvalds | 2022/07/29 10:45 AM |
altrernatives? | Michael S | 2022/07/29 05:17 AM |
altrernatives? | Rayla | 2022/07/29 06:49 AM |