This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the |auto= parameter.
Stub? more like super-stub. I can't beleive this is the best result I can get for a Google search for "SASOS kernel"
What is definition of "shared" here? There is no memory protection and applications can pass data to each others without copying. I tried to find references but found nothing. The best description could be Exec message passing... Xorxos (talk) 19:57, 28 September 2011 (UTC)[reply]
The Amiga used the TRIPOS operating system, which was indeed an single address space system (necessary to hit the low price point, it used a stock 68000 without any MMU hardware).
The original MIT Lisp Machine and I think its successors were also single address space systems, check the 5th paragraph of the Technical overview section. Hga (talk) 13:08, 29 September 2011 (UTC)[reply]
Is a virtual address space really a necessary requirement for a SASOS? 130.232.38.206 (talk) 17:31, 22 June 2016 (UTC)[reply]
No - most do have memory mapping, but some don't. Guy Harris (talk) 17:57, 22 June 2016 (UTC)[reply]
Yes, else it's what's generally called a flat memory model. The point of a SASOS, as used in the OS literature, is that it has memory protection but that's orthogonal to translation. Which, btw, means that many projects in the list shouldn't be there, eg AmigaOS or bare metal. Gernot Heiser (talk) 19:16, 22 June 2016 (UTC)[reply]
Memory protection is so orthogonal to translation that there are systems whose hardware supports memory protection but not translation, e.g. those System/360 machines (other than the Model 67, which did have translation) that had protection keys.
So it's possible to have the address space be physical rather than virtual but still have protection. What does that leave as the sine qua non of an SASOS? Guy Harris (talk) 19:47, 22 June 2016 (UTC)[reply]
Sure. That's not much different from higher-end microcontrollers who have an MPU with (potentially multiple) base-limit-type segments. That doesn't give you a SASOS in the sense of how the term is used in the literature, which tends to assume that the SAS incorporates all data of the system (incl persistent data) and, importantly, that a datum's address is invariant over its lifetime. You can only get that with virtual memory.
All this shows that the article is fairly inadequate, it should be labelled a stub. Gernot Heiser (talk) 20:59, 22 June 2016 (UTC)[reply]
The article says: "This makes context switches on a SASOS faster than on operating systems that must change the page table and flush the TLB caches on every context switch." Even though all processes have the same virtual-to-physical page table mapping, shouldn't each process have its own page-level protection, thus still requiring page table switching? If I'm correct, then the only factor in favor of SASOS is avoiding TLB flushes (and even then systems that support PCIDs suffer less due to context switching). KhaledHammouda (talk) 23:21, 19 February 2023 (UTC)[reply]
You're absolutely right. There were architectures (Armv5 comes to mind) wherer there was an advantage in context-switching cost, these are exceptions. Even on x86 with untagged TLBs there is no advantage here.
The SAOS advantages are elsewhere: Shared datastructures with embedded pointers work, so you can share without serialisation/deserialisation overheads Gernot Heiser (talk) 15:58, 16 August 2023 (UTC)[reply]
