On 10/8/2021 6:43 AM, David Brown wrote:
> On 07/10/2021 22:47, BGB wrote:
>> On 10/7/2021 2:35 PM, David Brown wrote:
>>> On 07/10/2021 12:52, clamky@hotmail.com wrote:
>>>> Might strike a cord with Anton and/or Mich
>>>>
>>>> https://www.yodaiken.com/2021/10/06/plos-2021-paper-how-iso-c-became-unusable-for-operating-system-development/
>>>>
>>>>
>>>
>>> It seems to me that the authors have misunderstood the language entirely.
>>>
>>> C was never meant to be a "high-level assembler" or a "portable
>>> assembler".  It was never intended that you could write low-level
>>> systems programs in portable C.  It was designed to reduce the need to
>>> write code in assembler, and to improve the portability of code.
>>> (Re-read that sentence if you like.)  It was intended to be useable for
>>> writing some kinds of code in a highly portable manner, and also to be
>>> useful in non-portable systems code that depended strongly on the target
>>> and the compiler.
>>>
>>>  From day one, operating systems "written in C" contained assembly code,
>>> compiler extensions, and other non-portable code.  That remains true
>>> today.  "Coding tricks" were often used to get efficient results due to
>>> more limited compilers - these are much less common now as compilers
>>> optimise better.
>>>
>>>
>>> As I got further in the document, it seems to be just another "the
>>> compiler should do what I want it to do, not necessarily what I /told/
>>> it to do" rant.  "C today should work the way /I/ want it to do - the
>>> way /I/ interpret the precise wording of what someone decades ago".
>>> "Thompson and Ritchie were saints and prophets, and their words were
>>> holy and eternal - regardless of how computers, languages, and
>>> programming needs have changed since the inception of C".  "We were all
>>> happy and no bugs existed in code until gcc sinned by optimising code,
>>> and we were thrown out of Eden into a hell of undefined behaviour".
>>> "Yes, we know that compilers often give us ways to get the semantics we
>>> want by specific flags, but that's not good enough - everyone else
>>> should get slower code so that we don't have to think as much or follow
>>> the rules of the language".
>>>
>>
>> The author of the paper (Victor Yodaiken) has sort of a long history of
>> "making a mountain out of a molehill" about all this stuff...
>>
>
> It seems that way. Often there are some good points - as I wrote, no
> language or tool is perfect, and it's important that people find weak
> points or make suggestions for improvement. Massively exaggerated
> rants, however, are worse than useless - they encourage other fanatics
> who feed on the same myths, doom-saying and exaggerations. And they
> ensure that those who actually have a say in the tools and language -
> the standards committees and compiler developers - will ignore all their
> concerns and write them off as fanatics. Good points they raise get
> thrown out and ignored along with the reams of rubbish,
> misunderstandings and misrepresentations that hide them.
>

Pretty much.

>>
>> I have my opinions, but will note that "the system" is self-regulating
>> to some extent, as compiler people would have a hard-time keeping people
>> using their compilers if they set out to break large amounts of existing
>> "real world" code (and will tend to back down when they face sufficient
>> backlash).
>
> Agreed. Compiler writers have no interest in making tools that people
> don't want to use. If feedback suggests a new compiler version does not
> work the way people expect and want, then the compiler developers take
> that seriously - they discuss matters with the users, they change the
> behaviour of the tools, they add flags or options to give users more
> control of the behaviour. In particular, they aim to test out new
> changes during pre-release and beta test stages so that potential
> problems get handled sooner.
>
> A similar process applies to language standards - there are long periods
> of proposals, discussions, and voting before changes are made. Big
> compiler users (like Linux distributions, corporations such as IBM,
> Microsoft, Google), big compiler implementers, researchers, and anyone
> else who is interested can get involved and share their opinion.
>
> You are never going to please everyone all of the time. And you are
> never going to please the small but vocal community who object to
> everything and accuse compiler writers and/or language committees of all
> sorts of evil motives and conspiracies. But they do a solid job
> overall, which is why languages like C are still a good choice for a lot
> of tasks.
>

Generally, it is tradeoffs.

Some people want "fastest possible", others want "existing code still
works unmodified".

Stuff should ideally still work even when the coding practices are
"kinda crap" so long as there is at least "some sane behavior which can
reasonably be expected from this".

So, code which casts pointers all over the place, should generally still
work IMO.

Whereas, things like taking the address of a stack local variable and
trying to use it to access contents in another unrelated stack local, or
code which overruns one array to access contents in another array (which
is assumed to be adjacent in memory), is stuff that is sufficiently
broken that I make little attempt at making it work (ROTT was a pretty
big offender with this sort of thing; Duke Nukem 3D also looks like an
awful mess which I have not yet gotten around to trying to port over...).

>>
>> In cases where stuff has broken in more significant ways, it has usually
>> been fairly isolated (a particular build of a particular compiler),
>> rather than a long-term change to the status quo.
>>
>
> And usually a "significant break" is found during testing stages, rather
> than post release.
>

Yeah, presumably. For mainline GCC and Clang, I am mostly using the ones
that come from the main repository.

Checking:
gcc 4.8.4
clang 3.3

Hmm, it appears that WSL's main repository is roughly 8 years behind the
"state of the art". Similarly, these versions somewhat predate WSL itself.

Note that according to "apt", this does appear to be "up to date".

Then again, back when I was mostly using Cygwin, I think I remember it
staying with GCC 0.97 for a very long time.

Checking the GCC version for my RISC-V cross-compiler toolchain:
11.1.0

Well, this seems a little newer...

>>>
>>> Are there imperfections in C as a language standard?  Sure.  Show me a
>>> perfect language standard as an alternative.  Are there questionable
>>> judgements in some of the design decisions of C toolchains?  Sure -
>>> again, show me a perfect toolchain.  Is C not quite an exact fit for all
>>> your needs for writing an OS?  Sure.  It's a general purpose language
>>> that is good for a very wide range of uses - but it's unlikely to be
>>> /perfect/ for any given use-case.  And it never has been, and it never
>>> will be.  Nor will anything else.  Modern C is a vastly better language
>>> than the earliest K&R C.  Modern C toolchains are vastly better than the
>>> tools of that era.  As well as the hundred steps forward, there have no
>>> doubt been a dozen steps backwards for some people and some uses.
>>> That's life.  If you don't like it, give up programming and stick to a
>>> safer hobby.
>>>
>>
>>>
>>> (For the record, I don't think type-based alias analysis actually gives
>>> very significant optimisation opportunities in most code.  On the other
>>> hand, I also don't think it causes problems very often - not nearly as
>>> often as the "optimisation is evil" crowd seem to behave.  I write
>>> low-level code all the time, and it is extraordinarily rarely that I
>>> have to find a way around it.)
>>>
>>
>> Will agree on this point.
>>
>> In my own testing, basic caching while also aggressively invalidating
>> the cached results (on any explicit memory store), can give much of the
>> same performance benefit, while still being fairly conservative
>> semantically.
>>
>
> There is a move towards "providence tracking" for memory and pointers as
> an alternative to things like type-based alias analysis. This is a lot
> more powerful, as it tracks when different references to the same type
> cannot alias, and thus can give much more optimisation opportunities and
> static error analysis benefits. It subsumes most TBAA, since pointers
> to different types usually have different providences. But in cases
> where the providence is actually the same, aliases (or potential
> aliases) are handled correctly. However, it turns out to be quite
> difficult to specify all this, and it is a work in progress (both for
> language standards and implementations).
>

On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
> Ivan Godard wrote:

> >
> > Because, for most current systems, a kernel thread switch is thousands
> > of cycles.
<
> According to the HTML paper dated 2002 titled
> "An Implementation of Scheduler Activations on the NetBSD Operating System"
> in the section "Performance Analysis"
> a Linux 2.4.19 kernel thread context switch is 82 us,
> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
> and Scheduler Activations on NetBSD is 225 us.
<
2002 was about the time of the 1GHz processor.
82µs = 82,000 cycles.
<
Almost anyone would consider this "slow". I was at AMD at the time, and it
was about 1,000 cycles from the arrival of the interrupt to delivery of control
at the interrupt handler.
<
Apparently "dealing" with said interrupt causes several more context switches
and wandered around large memory footprint before delivering control to the
desired thread.
>
> I don't know what that 2002 version of Linux scheduler did but
> around that time they used a single Big Lock for many OS resources.
<
2002 was before many were using more than one core.
<
> Since then much of the locking has been made finer grain and scheduling
> in particular is separated for each core so no locking is required.
> So kernel thread context switch should be proportionally even faster.

On 10/8/2021 12:45 PM, MitchAlsup wrote:
> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>> Ivan Godard wrote:
>
>>>
>>> Because, for most current systems, a kernel thread switch is thousands
>>> of cycles.
> <
>> According to the HTML paper dated 2002 titled
>> "An Implementation of Scheduler Activations on the NetBSD Operating System"
>> in the section "Performance Analysis"
>> a Linux 2.4.19 kernel thread context switch is 82 us,
>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>> and Scheduler Activations on NetBSD is 225 us.
> <
> 2002 was about the time of the 1GHz processor.
> 82µs = 82,000 cycles.
> <
> Almost anyone would consider this "slow". I was at AMD at the time, and it
> was about 1,000 cycles from the arrival of the interrupt to delivery of control
> at the interrupt handler.
> <
> Apparently "dealing" with said interrupt causes several more context switches
> and wandered around large memory footprint before delivering control to the
> desired thread.

This sort of thing is part of why my "TestKern" effort is aiming to cram
everything into a single big address space.

Granted, this does have the (fairly obvious) property that most
traditional schemes for memory protection, ..., kinda go out the window
when one has multiple logical processes within the same address space
(as do the traditional distinctions between threads and processes).

This is also related to the design of my own "PBO" ABI, and why (if
using ELF) I would prefer FDPIC (even if FDPIC also kinda sucks from an
overhead POV, which is also part of why I went with a seriously hacked
PE/COFF with a custom ABI rather than just reusing FDPIC).

Well, I also debated whether or not to go full custom for the binaries,
but my own design attempts didn't really lead to anything which had much
obvious advantage over a hacked up and LZ compressed version of PE/COFF.

Well, and also when one omits the MZ header, PE/COFF itself mostly
reduces to a COFF variant (just with an extra FOURCC on the front). One
could arguably debate if my PEL4 format (PE/COFF-(MZ Stub)+(LZ4
Compression)) is even really PE/COFF anymore, or some other form of COFF
derived executable format.

Had already gone and partly added an ELF loader as well, but then
debated whether to also support loading LZ compressed ELF (reusing the
existing LZ compressor and checksum logic), but, GNU LD doesn't exactly
support this, and otherwise this would require feeding the ELF binaries
through a standalone tool to convert them into an LZ compressed form,
which doesn't really seem worth the added hassle.

>>
>> I don't know what that 2002 version of Linux scheduler did but
>> around that time they used a single Big Lock for many OS resources.
> <
> 2002 was before many were using more than one core.
> <
>> Since then much of the locking has been made finer grain and scheduling
>> in particular is separated for each core so no locking is required.
>> So kernel thread context switch should be proportionally even faster.

On Thursday, October 7, 2021 at 6:46:28 PM UTC-6, MitchAlsup wrote:
> On Thursday, October 7, 2021 at 3:47:23 PM UTC-5, BGB wrote:

> > Whereas, say:
> > x=foo->bar->x;
> > y=foo->bar->y;
> > Becomes, effectively:
> > t0=foo->bar;
> > x=t0->x;
> > y=t0->y;

> In Operating System code; if one write the top 2 statements, one should
> get at least 4 loads--it is simply UNSAFE to assume otherwise--even
> if x happens to be allocated into a register (which may happen FAR after
> aliasing analysis is performed.)
>
> If the programmer KNOWS that there is no aliasing going on, the programmer
> should write the bottom set of code.

> If the programmer writes the top code and expects some kind of compiler
> flags (or magic) can translate it to the bottom--the programmer should be
> FIRED !

This is quite confusing to me.

It seems to me that both of those code samples should be
guaranteed to produce identical results, regardless of the
level of optimization selected.

It's
x=foo->bar->x;
*ptr = 3;
y=foo->bar->y;

where 'ptr' happens to have a... connection... with foo or bar
that might behave in the 'unexpected' way of not producing the
same result as

t0=foo->bar;
x=t0->x;
y=t0->y;
*ptr = 3;

Unless, of course, I'm missing something.

John Savard

On 10/8/2021 3:12 PM, BGB wrote:
> On 10/8/2021 12:45 PM, MitchAlsup wrote:
>> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>>> Ivan Godard wrote:
>>
>>>>
>>>> Because, for most current systems, a kernel thread switch is thousands
>>>> of cycles.
>> <
>>> According to the HTML paper dated 2002 titled
>>> "An Implementation of Scheduler Activations on the NetBSD Operating
>>> System"
>>> in the section "Performance Analysis"
>>> a Linux 2.4.19 kernel thread context switch is 82 us,
>>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>>> and Scheduler Activations on NetBSD is 225 us.
>> <
>> 2002 was about the time of the 1GHz processor.
>> 82µs = 82,000 cycles.
>> <
>> Almost anyone would consider this "slow". I was at AMD at the time,
>> and it
>> was about 1,000 cycles from the arrival of the interrupt to delivery
>> of control
>> at the interrupt handler.
>> <
>> Apparently "dealing" with said interrupt causes several more context
>> switches
>> and wandered around large memory footprint before delivering control
>> to the
>> desired thread.
>
> This sort of thing is part of why my "TestKern" effort is aiming to cram
> everything into a single big address space.

OK. This is generally called "Single Address Space". This is used by
such systems as the IBM System i, and the Mill.

> Granted, this does have the (fairly obvious) property that most
> traditional schemes for memory protection, ..., kinda go out the window
> when one has multiple logical processes within the same address space
> (as do the traditional distinctions between threads and processes).

Not necessarily. Just because multiple logical processes exist within
the same address space, doesn't mean that each process has legal access
to all the addresses within that space.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 10/8/2021 11:25 PM, Stephen Fuld wrote:
> On 10/8/2021 3:12 PM, BGB wrote:
>> On 10/8/2021 12:45 PM, MitchAlsup wrote:
>>> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>>>> Ivan Godard wrote:
>>>
>>>>>
>>>>> Because, for most current systems, a kernel thread switch is thousands
>>>>> of cycles.
>>> <
>>>> According to the HTML paper dated 2002 titled
>>>> "An Implementation of Scheduler Activations on the NetBSD Operating
>>>> System"
>>>> in the section "Performance Analysis"
>>>> a Linux 2.4.19 kernel thread context switch is 82 us,
>>>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>>>> and Scheduler Activations on NetBSD is 225 us.
>>> <
>>> 2002 was about the time of the 1GHz processor.
>>> 82µs = 82,000 cycles.
>>> <
>>> Almost anyone would consider this "slow". I was at AMD at the time,
>>> and it
>>> was about 1,000 cycles from the arrival of the interrupt to delivery
>>> of control
>>> at the interrupt handler.
>>> <
>>> Apparently "dealing" with said interrupt causes several more context
>>> switches
>>> and wandered around large memory footprint before delivering control
>>> to the
>>> desired thread.
>>
>> This sort of thing is part of why my "TestKern" effort is aiming to
>> cram everything into a single big address space.
>
> OK.  This is generally called "Single Address Space".  This is used by
> such systems as the IBM System i, and the Mill.
>
>> Granted, this does have the (fairly obvious) property that most
>> traditional schemes for memory protection, ..., kinda go out the
>> window when one has multiple logical processes within the same address
>> space (as do the traditional distinctions between threads and processes).
>
> Not necessarily.  Just because multiple logical processes exist within
> the same address space, doesn't mean that each process has legal access
> to all the addresses within that space.

An address space tells you what you can name; a protection domain tells
you whether naming it does you any good.

On 10/9/2021 1:25 AM, Stephen Fuld wrote:
> On 10/8/2021 3:12 PM, BGB wrote:
>> On 10/8/2021 12:45 PM, MitchAlsup wrote:
>>> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>>>> Ivan Godard wrote:
>>>
>>>>>
>>>>> Because, for most current systems, a kernel thread switch is thousands
>>>>> of cycles.
>>> <
>>>> According to the HTML paper dated 2002 titled
>>>> "An Implementation of Scheduler Activations on the NetBSD Operating
>>>> System"
>>>> in the section "Performance Analysis"
>>>> a Linux 2.4.19 kernel thread context switch is 82 us,
>>>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>>>> and Scheduler Activations on NetBSD is 225 us.
>>> <
>>> 2002 was about the time of the 1GHz processor.
>>> 82µs = 82,000 cycles.
>>> <
>>> Almost anyone would consider this "slow". I was at AMD at the time,
>>> and it
>>> was about 1,000 cycles from the arrival of the interrupt to delivery
>>> of control
>>> at the interrupt handler.
>>> <
>>> Apparently "dealing" with said interrupt causes several more context
>>> switches
>>> and wandered around large memory footprint before delivering control
>>> to the
>>> desired thread.
>>
>> This sort of thing is part of why my "TestKern" effort is aiming to
>> cram everything into a single big address space.
>
> OK.  This is generally called "Single Address Space".  This is used by
> such systems as the IBM System i, and the Mill.
>

Yeah.

>> Granted, this does have the (fairly obvious) property that most
>> traditional schemes for memory protection, ..., kinda go out the
>> window when one has multiple logical processes within the same address
>> space (as do the traditional distinctions between threads and processes).
>
> Not necessarily.  Just because multiple logical processes exist within
> the same address space, doesn't mean that each process has legal access
> to all the addresses within that space.
>

I was thinking of traditional schemes like "protection rings", ...

So, say, a protection ring scheme will be pretty ineffective at
protecting one program from another within a single address space.

I have my own scheme I am calling VUGID which can basically attach
UID/GID checks and/or ACLs to memory on a per-page basis (some of the
logic for dealing with this is basically integrated into the MMU/TLB).

On Fri, 08 Oct 2021 01:38:21 GMT, Branimir Maksimovic
<branimir.maksimovic@icloud.com> wrote:

>On 2021-10-08, MitchAlsup <MitchAlsup@aol.com> wrote:
>> On Thursday, October 7, 2021 at 3:47:23 PM UTC-5, BGB wrote:
>>> On 10/7/2021 2:35 PM, David Brown wrote:
>>> > On 07/10/2021 12:52, cla...@hotmail.com wrote:
>>> >> Might strike a cord with Anton and/or Mich
>>> >>
>>> >> https://www.yodaiken.com/2021/10/06/plos-2021-paper-how-iso-c-became-unusable-for-operating-system-development/
>>> >>
>>> >
>>>
>>> Under TBAA, the second "foo->x" may reuse the result of the first, but
>>> under more conservative semantics, the "*ptr=" would effectively
>>> invalidate the cached result regardless of the pointer type.
>>>
>>> Whereas, say:
>>> x=foo->bar->x;
>>> y=foo->bar->y;
>>> Becomes, effectively:
>>> t0=foo->bar;
>>> x=t0->x;
>>> y=t0->y;
>><
>> In Operating System code; if one write the top 2 statements, one should
>> get at least 4 loads--it is simply UNSAFE to assume otherwise--even
>> if x happens to be allocated into a register (which may happen FAR after
>> aliasing analysis is performed.)
>><
>> If the programmer KNOWS that there is no aliasing going on, the programmer
>> should write the bottom set of code.
>><
>> If the programmer writes the top code and expects some kind of compiler
>> flags (or magic) can translate it to the bottom--the programmer should be
>> FIRED !
>
>Isn't it that GC are always advertised as way to solve *cycling references*?

C is a hostile environment for most forms of GC.

On 2021-10-09, George Neuner <gneuner2@comcast.net> wrote:
> On Fri, 08 Oct 2021 01:38:21 GMT, Branimir Maksimovic
><branimir.maksimovic@icloud.com> wrote:
>
>>On 2021-10-08, MitchAlsup <MitchAlsup@aol.com> wrote:
>>> On Thursday, October 7, 2021 at 3:47:23 PM UTC-5, BGB wrote:
>>>> On 10/7/2021 2:35 PM, David Brown wrote:
>>>> > On 07/10/2021 12:52, cla...@hotmail.com wrote:
>>>> >> Might strike a cord with Anton and/or Mich
>>>> >>
>>>> >> https://www.yodaiken.com/2021/10/06/plos-2021-paper-how-iso-c-became-unusable-for-operating-system-development/
>>>> >>
>>>> >
>>>>
>>>> Under TBAA, the second "foo->x" may reuse the result of the first, but
>>>> under more conservative semantics, the "*ptr=" would effectively
>>>> invalidate the cached result regardless of the pointer type.
>>>>
>>>> Whereas, say:
>>>> x=foo->bar->x;
>>>> y=foo->bar->y;
>>>> Becomes, effectively:
>>>> t0=foo->bar;
>>>> x=t0->x;
>>>> y=t0->y;
>>><
>>> In Operating System code; if one write the top 2 statements, one should
>>> get at least 4 loads--it is simply UNSAFE to assume otherwise--even
>>> if x happens to be allocated into a register (which may happen FAR after
>>> aliasing analysis is performed.)
>>><
>>> If the programmer KNOWS that there is no aliasing going on, the programmer
>>> should write the bottom set of code.
>>><
>>> If the programmer writes the top code and expects some kind of compiler
>>> flags (or magic) can translate it to the bottom--the programmer should be
>>> FIRED !
>>
>>Isn't it that GC are always advertised as way to solve *cycling references*?
>
> C is a hostile environment for most forms of GC.
>

Only if you play with pointers. If you use tham wihtout masking. xoring
or shifting they can be scanned as such as Hans&Boehms GC does.
Only thing is that some number can be recognized as false positive :p

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 10/9/2021 12:50 AM, BGB wrote:
> On 10/9/2021 1:25 AM, Stephen Fuld wrote:
>> On 10/8/2021 3:12 PM, BGB wrote:
>>> On 10/8/2021 12:45 PM, MitchAlsup wrote:
>>>> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>>>>> Ivan Godard wrote:
>>>>
>>>>>>
>>>>>> Because, for most current systems, a kernel thread switch is
>>>>>> thousands
>>>>>> of cycles.
>>>> <
>>>>> According to the HTML paper dated 2002 titled
>>>>> "An Implementation of Scheduler Activations on the NetBSD Operating
>>>>> System"
>>>>> in the section "Performance Analysis"
>>>>> a Linux 2.4.19 kernel thread context switch is 82 us,
>>>>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>>>>> and Scheduler Activations on NetBSD is 225 us.
>>>> <
>>>> 2002 was about the time of the 1GHz processor.
>>>> 82µs = 82,000 cycles.
>>>> <
>>>> Almost anyone would consider this "slow". I was at AMD at the time,
>>>> and it
>>>> was about 1,000 cycles from the arrival of the interrupt to delivery
>>>> of control
>>>> at the interrupt handler.
>>>> <
>>>> Apparently "dealing" with said interrupt causes several more context
>>>> switches
>>>> and wandered around large memory footprint before delivering control
>>>> to the
>>>> desired thread.
>>>
>>> This sort of thing is part of why my "TestKern" effort is aiming to
>>> cram everything into a single big address space.
>>
>> OK.  This is generally called "Single Address Space".  This is used by
>> such systems as the IBM System i, and the Mill.
>>
>
> Yeah.
>
>
>>> Granted, this does have the (fairly obvious) property that most
>>> traditional schemes for memory protection, ..., kinda go out the
>>> window when one has multiple logical processes within the same
>>> address space (as do the traditional distinctions between threads and
>>> processes).
>>
>> Not necessarily.  Just because multiple logical processes exist within
>> the same address space, doesn't mean that each process has legal
>> access to all the addresses within that space.
>>
>
> I was thinking of traditional schemes like "protection rings", ...
>
> So, say, a protection ring scheme will be pretty ineffective at
> protecting one program from another within a single address space.

Not necessarily. Most modern systems conflate two totally different
ideas into mechanism, so most people seem to think they are really the
same. As I van pointed out in his response, don't confuse knowing where
something is with what rights to access it you have.

You can watch Ivan's description of how the Mill separates the two
concepts on the Mill web site.

> I have my own scheme I am calling VUGID which can basically attach
> UID/GID checks and/or ACLs to memory on a per-page basis (some of the
> logic for dealing with this is basically integrated into the MMU/TLB).

See, you are conflating protection (UID/GID or ACL) with memory
placement (MMU/TLB). They don't have to be conflated.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

MitchAlsup wrote:
> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>> Ivan Godard wrote:
>
>>> Because, for most current systems, a kernel thread switch is thousands
>>> of cycles.
> <
>> According to the HTML paper dated 2002 titled
>> "An Implementation of Scheduler Activations on the NetBSD Operating System"
>> in the section "Performance Analysis"
>> a Linux 2.4.19 kernel thread context switch is 82 us,
>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>> and Scheduler Activations on NetBSD is 225 us.
> <
> 2002 was about the time of the 1GHz processor.
> 82µs = 82,000 cycles.
> <
> Almost anyone would consider this "slow". I was at AMD at the time, and it
> was about 1,000 cycles from the arrival of the interrupt to delivery of control
> at the interrupt handler.
> <
> Apparently "dealing" with said interrupt causes several more context switches
> and wandered around large memory footprint before delivering control to the
> desired thread.

Test platform was an Apple iBook, with a 500 MHz G3 processor with
256k of L2 cache.

Wikipedia says that G3 is a family of processors in the PowerPC 7xx
series and that it was the PowerPC 750 in this laptop.
It says the 740 was roughly equivalent to a Pentium II and the
750 added off-die L2 cache that "increased performance by
approximately 30% in most situations".

>> I don't know what that 2002 version of Linux scheduler did but
>> around that time they used a single Big Lock for many OS resources.
> <
> 2002 was before many were using more than one core.

Yes, PowerPC 750 was single core.

> <
>> Since then much of the locking has been made finer grain and scheduling
>> in particular is separated for each core so no locking is required.
>> So kernel thread context switch should be proportionally even faster.

According to Ivan Godard <ivan@millcomputing.com>:
>>> Granted, this does have the (fairly obvious) property that most
>>> traditional schemes for memory protection, ..., kinda go out the
>>> window when one has multiple logical processes within the same address
>>> space (as do the traditional distinctions between threads and processes).
>>
>> Not necessarily.  Just because multiple logical processes exist within
>> the same address space, doesn't mean that each process has legal access
>> to all the addresses within that space.
>
>An address space tells you what you can name; a protection domain tells
>you whether naming it does you any good.

Quite right. Over fifty years ago S/360 put everything in one address space
and had a memory protection scheme so that programs couldn't stomp on (or in
some cases even look at) pages that weren't theirs.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Saturday, October 9, 2021 at 2:16:10 PM UTC-5, John Levine wrote:
> According to Ivan Godard <iv...@millcomputing.com>:
> >>> Granted, this does have the (fairly obvious) property that most
> >>> traditional schemes for memory protection, ..., kinda go out the
> >>> window when one has multiple logical processes within the same address
> >>> space (as do the traditional distinctions between threads and processes).
> >>
> >> Not necessarily. Just because multiple logical processes exist within
> >> the same address space, doesn't mean that each process has legal access
> >> to all the addresses within that space.
> >
> >An address space tells you what you can name; a protection domain tells
> >you whether naming it does you any good.
<
> Quite right. Over fifty years ago S/360 put everything in one address space
<
1963 (58+ YA) we got to see it.
<
> and had a memory protection scheme so that programs couldn't stomp on (or in
> some cases even look at) pages that weren't theirs.
<
Many others already had base and bounds.
<
Does anyone know if the Boroughs and ICL machines prevented applications
from creating their own descriptors ?
<
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On Sat, 09 Oct 2021 14:18:14 GMT, Branimir Maksimovic
<branimir.maksimovic@icloud.com> wrote:

>On 2021-10-09, George Neuner <gneuner2@comcast.net> wrote:
>
>> C is a hostile environment for most forms of GC.
>
>Only if you play with pointers. If you use tham wihtout masking. xoring
>or shifting they can be scanned as such as Hans&Boehms GC does.
>Only thing is that some number can be recognized as false positive :p

Actually, the main problem with C - and similar "uncooperative"
languages - is that the compiler often "misplaces" pointers to heap
allocations.

Consider a function that heap allocates an object, manipulates it, and
deletes it: in this case any and all pointers to the object will exist
only on the call stack. It doesn't matter whether the function calls
other functions - it only matters whether collection may be triggered
while the heap allocated object is alive.

In the course of manipulating an object, compilers routinely "lose" or
"misplace" the original pointer to it, e.g., by walking the pointer
across an array, or by indexing from it and not keeping the original
value.
[When the compiler knows the size of the object or array element, it
can easily undo any indexing math to recover the original pointer
value. Thus no need to store the original value.]

If you step through such code with your debugger, you will discover
that, quite often, the /only/ pointer to some object is pointing into
the middle of the object, or in the case of an array it could be
pointing outside of the array bounds. Most importantly, there may be
/no/ easily identifiable heap pointer for GC to find.

This is "compilation pointer masking" and it greatly increases the
effort required to identify live heap objects: the GC has to be able
to recognize references to any location inside any allocated block.

Just guaranteeing that compilers never "lose" original pointers would
make C (and similar "uncooperative" languages) a lot more friendly to
GC.

YMMV,
George

According to MitchAlsup <MitchAlsup@aol.com>:
>> >An address space tells you what you can name; a protection domain tells
>> >you whether naming it does you any good.
><
>> Quite right. Over fifty years ago S/360 put everything in one address space
><
>1963 (58+ YA) we got to see it.

>> and had a memory protection scheme so that programs couldn't stomp on (or in
>> some cases even look at) pages that weren't theirs.
><
>Many others already had base and bounds.

Right, but that's different. The PDP-6 had base and bounds so a program could only
address within the bounds, and the base provided dynamic relocation which S/360 didn't
have. On the 360 there was only one set of addresses but if you tried to fetch or store
into a block with the wrong protection key, it got a protection fault and your program
was generally killed.

>Does anyone know if the Boroughs and ICL machines prevented applications
>from creating their own descriptors ?

Burroughs certainly did. The protection scheme depended on compilers generating
secure code.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 10/9/2021 12:33 PM, MitchAlsup wrote:
> On Saturday, October 9, 2021 at 2:16:10 PM UTC-5, John Levine wrote:
>> According to Ivan Godard <iv...@millcomputing.com>:
>>>>> Granted, this does have the (fairly obvious) property that most
>>>>> traditional schemes for memory protection, ..., kinda go out the
>>>>> window when one has multiple logical processes within the same address
>>>>> space (as do the traditional distinctions between threads and processes).
>>>>
>>>> Not necessarily. Just because multiple logical processes exist within
>>>> the same address space, doesn't mean that each process has legal access
>>>> to all the addresses within that space.
>>>
>>> An address space tells you what you can name; a protection domain tells
>>> you whether naming it does you any good.
> <
>> Quite right. Over fifty years ago S/360 put everything in one address space
> <
> 1963 (58+ YA) we got to see it.
> <
>> and had a memory protection scheme so that programs couldn't stomp on (or in
>> some cases even look at) pages that weren't theirs.
> <
> Many others already had base and bounds.
> <
> Does anyone know if the Boroughs and ICL machines prevented applications
> from creating their own descriptors ?

The B5000 stream procedures did if you generated the code yourself; I
think so, anyway, it was before my time there. The B6500 secured the
compilers so it wasn't possible; the instruction to set the 3-bit tag
was only available from ESPOL, the OS flavor of Algol. Later on (after
my day) I think they realized that securing the compilers was
impractical and so the instruction was made privileged.

On Saturday, October 9, 2021 at 2:35:29 PM UTC-5, George Neuner wrote:
> On Sat, 09 Oct 2021 14:18:14 GMT, Branimir Maksimovic
> <branimir....@icloud.com> wrote:
<snip>
> In the course of manipulating an object, compilers routinely "lose" or
> "misplace" the original pointer to it, e.g., by walking the pointer
> across an array, or by indexing from it and not keeping the original
> value.
> [When the compiler knows the size of the object or array element, it
> can easily undo any indexing math to recover the original pointer
> value. Thus no need to store the original value.]
>
> If you step through such code with your debugger, you will discover
> that, quite often, the /only/ pointer to some object is pointing into
> the middle of the object, or in the case of an array it could be
> pointing outside of the array bounds. Most importantly, there may be
> /no/ easily identifiable heap pointer for GC to find.
<
I consider not having convenient indexing forms for LD and ST
bad ISA design. My 66000 LD and ST instructions have such
indexing and in _most_ cases using indexing results in smaller
and faster code than when ++ing or --ing a pointer through an
array; often using fewer registers to boot.
>
> This is "compilation pointer masking" and it greatly increases the
> effort required to identify live heap objects: the GC has to be able
> to recognize references to any location inside any allocated block.
>
Question: in a 64-bit virtual address space, is there ever a reason that
the "heap" cannot live in a contiguous subsection of that space so
base and bounds could tell if the pointer should be considered for
GC (or not)?
>
> Just guaranteeing that compilers never "lose" original pointers would
> make C (and similar "uncooperative" languages) a lot more friendly to
> GC.
<
Banning ++ing and --ing would go a long way.........
>
>
> YMMV,
> George

On 2021-10-09, George Neuner <gneuner2@comcast.net> wrote:
> On Sat, 09 Oct 2021 14:18:14 GMT, Branimir Maksimovic
><branimir.maksimovic@icloud.com> wrote:
>
>>On 2021-10-09, George Neuner <gneuner2@comcast.net> wrote:
>>
>>> C is a hostile environment for most forms of GC.
>>
>>Only if you play with pointers. If you use tham wihtout masking. xoring
>>or shifting they can be scanned as such as Hans&Boehms GC does.
>>Only thing is that some number can be recognized as false positive :p
>
> Actually, the main problem with C - and similar "uncooperative"
> languages - is that the compiler often "misplaces" pointers to heap
> allocations.
>
> Consider a function that heap allocates an object, manipulates it, and
> deletes it: in this case any and all pointers to the object will exist
> only on the call stack. It doesn't matter whether the function calls
> other functions - it only matters whether collection may be triggered
> while the heap allocated object is alive.
>
> In the course of manipulating an object, compilers routinely "lose" or
> "misplace" the original pointer to it, e.g., by walking the pointer
> across an array, or by indexing from it and not keeping the original
> value.
> [When the compiler knows the size of the object or array element, it
> can easily undo any indexing math to recover the original pointer
> value. Thus no need to store the original value.]
>
> If you step through such code with your debugger, you will discover
> that, quite often, the /only/ pointer to some object is pointing into
> the middle of the object, or in the case of an array it could be
> pointing outside of the array bounds. Most importantly, there may be
> /no/ easily identifiable heap pointer for GC to find.

Boehm's collector scans heap/stack/bss, pointing anywhere within
allocated area, no problem with that.

>
> This is "compilation pointer masking" and it greatly increases the
> effort required to identify live heap objects: the GC has to be able
> to recognize references to any location inside any allocated block.
>
live is if pointer exists anywhere in accessible memory.

>
> Just guaranteeing that compilers never "lose" original pointers would
> make C (and similar "uncooperative" languages) a lot more friendly to
> GC.

Sure, but Boehm's collector works with C. With C++ there are problems
because of caching scheme in defualt allocator.

>
>
> YMMV,
> George
Greetings, Branimir.

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On 10/9/2021 2:35 PM, George Neuner wrote:
> On Sat, 09 Oct 2021 14:18:14 GMT, Branimir Maksimovic
> <branimir.maksimovic@icloud.com> wrote:
>
>> On 2021-10-09, George Neuner <gneuner2@comcast.net> wrote:
>>
>>> C is a hostile environment for most forms of GC.
>>
>> Only if you play with pointers. If you use tham wihtout masking. xoring
>> or shifting they can be scanned as such as Hans&Boehms GC does.
>> Only thing is that some number can be recognized as false positive :p
>
> Actually, the main problem with C - and similar "uncooperative"
> languages - is that the compiler often "misplaces" pointers to heap
> allocations.
>
> Consider a function that heap allocates an object, manipulates it, and
> deletes it: in this case any and all pointers to the object will exist
> only on the call stack. It doesn't matter whether the function calls
> other functions - it only matters whether collection may be triggered
> while the heap allocated object is alive.
>
> In the course of manipulating an object, compilers routinely "lose" or
> "misplace" the original pointer to it, e.g., by walking the pointer
> across an array, or by indexing from it and not keeping the original
> value.
> [When the compiler knows the size of the object or array element, it
> can easily undo any indexing math to recover the original pointer
> value. Thus no need to store the original value.]
>
> If you step through such code with your debugger, you will discover
> that, quite often, the /only/ pointer to some object is pointing into
> the middle of the object, or in the case of an array it could be
> pointing outside of the array bounds. Most importantly, there may be
> /no/ easily identifiable heap pointer for GC to find.
>
> This is "compilation pointer masking" and it greatly increases the
> effort required to identify live heap objects: the GC has to be able
> to recognize references to any location inside any allocated block.
>
>
> Just guaranteeing that compilers never "lose" original pointers would
> make C (and similar "uncooperative" languages) a lot more friendly to
> GC.
>

Some of this can be helped by requiring the compiler to keep a lot of
metadata around for anything which may be relevant to the garbage
collector (where to find root pointers, structure layout metadata, ...).

With some compiler assistance and minor restrictions on coding
practices, one could even go as far as to use a precise garbage collector.

This could either be done via explicit language extensions, or by
semantic trickery and silently "pinning" allocations when they go
outside the scope of what the GC can keep track of.

Say, for example, if someone has:
typedef struct foo_s foo_t;
struct foo_s { ... };
...
foo_t *pfoo;
pfoo=malloc(sizeof(foo_t));

And, the compiler keeps track of:
The layout of foo_s;
The relative location of pfoo;
...
And, then infers that 'pfoo' points to an instance of the same struct
(it could infer this at the scope of the 'malloc' call, ...).

Then, a GC could likely be made pretty workable.

Whether or not using a garbage collector is a worthwhile tradeoff is
another matter.

On 9 Oct 2021, MitchAlsup wrote
(in article<fbb80b3a-bf7a-44aa-863c-17f44bdf2eb0n@googlegroups.com>):

> On Saturday, October 9, 2021 at 2:16:10 PM UTC-5, John Levine wrote:
> > According to Ivan Godard<iv...@millcomputing.com>:
> > > > > Granted, this does have the (fairly obvious) property that most
> > > > > traditional schemes for memory protection, ..., kinda go out the
> > > > > window when one has multiple logical processes within the same address
> > > > > space (as do the traditional distinctions between threads and processes).
> > > >
> > > > Not necessarily. Just because multiple logical processes exist within
> > > > the same address space, doesn't mean that each process has legal access
> > > > to all the addresses within that space.
> > >
> > > An address space tells you what you can name; a protection domain tells
> > > you whether naming it does you any good.
> <
> > Quite right. Over fifty years ago S/360 put everything in one address space
> <
> 1963 (58+ YA) we got to see it.
> <
> > and had a memory protection scheme so that programs couldn't stomp on (or in
> > some cases even look at) pages that weren't theirs.
> <
> Many others already had base and bounds.
> <
> Does anyone know if the Boroughs and ICL machines prevented applications
> from creating their own descriptors ?

The ICL 2900 used descriptor solely for describing structured data.
They played no role in the protection system, which used nested rings
in a manner very similar to Multics. So processes could and did
(and had to, in some cases) manufacture their own descriptors.

--
Bill Findlay

On Thursday, October 7, 2021 at 2:35:29 PM UTC-5, David Brown wrote:

> As I got further in the document, it seems to be just another "the
> compiler should do what I want it to do, not necessarily what I /told/
> it to do" rant. "C today should work the way /I/ want it to do - the
> way /I/ interpret the precise wording of what someone decades ago".
> "Thompson and Ritchie were saints and prophets, and their words were
> holy and eternal - regardless of how computers, languages, and
> programming needs have changed since the inception of C". "We were all
> happy and no bugs existed in code until gcc sinned by optimising code,
> and we were thrown out of Eden into a hell of undefined behaviour".
> "Yes, we know that compilers often give us ways to get the semantics we
> want by specific flags, but that's not good enough - everyone else
> should get slower code so that we don't have to think as much or follow
> the rules of the language".

Of course the paper doesn't make an argument anything like that nor does it make the assembler claims
you start with. It is hard to believe anyone could read the
paper and get such a weird take from it.

Thomas Koenig <tkoenig@netcologne.de> writes:

> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> It is much like handling fiearms::
>><
>> 1) all pointers are loaded at all times unless verified they are not.
>> 2) never point a pointer at something you do not want destroyed.
>> 3) never enable a pointer until your sights are on the target
>><
>> 4) There is NO SUCH THING as a casual pointer.
>
> I _love_ that.

Number 2 is particularly awesome.
Mind if I put it on Facebook (with attribution, of course)?

On 10/9/2021 9:56 AM, Stephen Fuld wrote:
> On 10/9/2021 12:50 AM, BGB wrote:
>> On 10/9/2021 1:25 AM, Stephen Fuld wrote:
>>> On 10/8/2021 3:12 PM, BGB wrote:
>>>> On 10/8/2021 12:45 PM, MitchAlsup wrote:
>>>>> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>>>>>> Ivan Godard wrote:
>>>>>
>>>>>>>
>>>>>>> Because, for most current systems, a kernel thread switch is
>>>>>>> thousands
>>>>>>> of cycles.
>>>>> <
>>>>>> According to the HTML paper dated 2002 titled
>>>>>> "An Implementation of Scheduler Activations on the NetBSD
>>>>>> Operating System"
>>>>>> in the section "Performance Analysis"
>>>>>> a Linux 2.4.19 kernel thread context switch is 82 us,
>>>>>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>>>>>> and Scheduler Activations on NetBSD is 225 us.
>>>>> <
>>>>> 2002 was about the time of the 1GHz processor.
>>>>> 82µs = 82,000 cycles.
>>>>> <
>>>>> Almost anyone would consider this "slow". I was at AMD at the time,
>>>>> and it
>>>>> was about 1,000 cycles from the arrival of the interrupt to
>>>>> delivery of control
>>>>> at the interrupt handler.
>>>>> <
>>>>> Apparently "dealing" with said interrupt causes several more
>>>>> context switches
>>>>> and wandered around large memory footprint before delivering
>>>>> control to the
>>>>> desired thread.
>>>>
>>>> This sort of thing is part of why my "TestKern" effort is aiming to
>>>> cram everything into a single big address space.
>>>
>>> OK.  This is generally called "Single Address Space".  This is used
>>> by such systems as the IBM System i, and the Mill.
>>>
>>
>> Yeah.
>>
>>
>>>> Granted, this does have the (fairly obvious) property that most
>>>> traditional schemes for memory protection, ..., kinda go out the
>>>> window when one has multiple logical processes within the same
>>>> address space (as do the traditional distinctions between threads
>>>> and processes).
>>>
>>> Not necessarily.  Just because multiple logical processes exist
>>> within the same address space, doesn't mean that each process has
>>> legal access to all the addresses within that space.
>>>
>>
>> I was thinking of traditional schemes like "protection rings", ...
>>
>> So, say, a protection ring scheme will be pretty ineffective at
>> protecting one program from another within a single address space.
>
> Not necessarily.  Most modern systems conflate two totally different
> ideas into mechanism, so most people seem to think they are really the
> same.  As I van pointed out in his response, don't confuse knowing where
> something is with what rights to access it you have.
>
> You can watch Ivan's description of how the Mill separates the two
> concepts on the Mill web site.
>

IIRC, Mill was using a capability architecture or something?...

In my stuff, I am (for now) using a linear 48 bit address space.

I had considered some ideas for how to expand it to 96 bits, but have
not actually implemented anything in this direction yet.

There are two current sub-possibilities here:
Direct 96 bit linear space, 96 bit virtual address in TLBE (expanded to
256 bits).

Two-part remapping, which matches the high portion and low portion
separately, and then using a check value to verify that the high and low
parts of the lookup agree with each other.

The two part scheme would support both 48b and 96b addressing with the
existing TLBE format, but could be a little cheaper to implement
relative to a 1:1 (as it avoids needing to expand the TLBEs), but could
have other potential costs.

Apart from when using explicit 128-bit pointers, the addressing would
also behave more like an x86-style segmented addressing scheme (there
could be PC_HI and GBR_HI regs which would behave sort of like CS and
DS); with modular addressing at the 256TB / 0.25PB boundary.

One issue with such an address space is that it is sufficiently large as
to run out of SI prefixes to express its size directly; though one
possible workaround would be switching to using a petabyte as a
base-unit (eg: "quad", *1), at which point the address space size could
be expressed as (64 petaquad). Other options would be either to make the
table longer, or glue prefixes together (kilopetabyte), at which I guess
it becomes a question of "what is less awful".

*1: Yes, I am ripping this off of Star Trek.

For now though, there are no immediate plans to implement this.

>
>> I have my own scheme I am calling VUGID which can basically attach
>> UID/GID checks and/or ACLs to memory on a per-page basis (some of the
>> logic for dealing with this is basically integrated into the MMU/TLB).
>
> See, you are conflating protection (UID/GID or ACL) with memory
> placement (MMU/TLB).  They don't have to be conflated.
>

OK. Conflating them makes the most sense for the MMU though.

Other than the funky protection scheme, the MMU is fairly similar to a
more traditional design. Well, apart from using a software-managed TLB.

However, the only real alternative to software TLB, is having a
page-walker in hardware. However, this part seems relatively expensive,
and it seems easier to throw an exception here and let the ISR handle it
(with special instructions for things like adding TLE entries into the
TLB, etc).

....

> Boehm's collector scans heap/stack/bss, pointing anywhere within
> allocated area, no problem with that.

"No problem" is debatable. I could agree to "solved problem", but "no
problem" is really pushing it. Even "solved problem" is only true if
you don't care about the costs of solving that problem (can be extra
runtime costs, additional false positives, ...).

Stefan

On 10/9/2021 6:48 PM, BGB wrote:
> On 10/9/2021 9:56 AM, Stephen Fuld wrote:
>> On 10/9/2021 12:50 AM, BGB wrote:
>>> On 10/9/2021 1:25 AM, Stephen Fuld wrote:
>>>> On 10/8/2021 3:12 PM, BGB wrote:
>>>>> On 10/8/2021 12:45 PM, MitchAlsup wrote:
>>>>>> On Friday, October 8, 2021 at 12:15:18 PM UTC-5, EricP wrote:
>>>>>>> Ivan Godard wrote:
>>>>>>
>>>>>>>>
>>>>>>>> Because, for most current systems, a kernel thread switch is
>>>>>>>> thousands
>>>>>>>> of cycles.
>>>>>> <
>>>>>>> According to the HTML paper dated 2002 titled
>>>>>>> "An Implementation of Scheduler Activations on the NetBSD
>>>>>>> Operating System"
>>>>>>> in the section "Performance Analysis"
>>>>>>> a Linux 2.4.19 kernel thread context switch is 82 us,
>>>>>>> GNU PTH Portable Threads user mode library on NetBSD is 166 us,
>>>>>>> and Scheduler Activations on NetBSD is 225 us.
>>>>>> <
>>>>>> 2002 was about the time of the 1GHz processor.
>>>>>> 82µs = 82,000 cycles.
>>>>>> <
>>>>>> Almost anyone would consider this "slow". I was at AMD at the
>>>>>> time, and it
>>>>>> was about 1,000 cycles from the arrival of the interrupt to
>>>>>> delivery of control
>>>>>> at the interrupt handler.
>>>>>> <
>>>>>> Apparently "dealing" with said interrupt causes several more
>>>>>> context switches
>>>>>> and wandered around large memory footprint before delivering
>>>>>> control to the
>>>>>> desired thread.
>>>>>
>>>>> This sort of thing is part of why my "TestKern" effort is aiming to
>>>>> cram everything into a single big address space.
>>>>
>>>> OK.  This is generally called "Single Address Space".  This is used
>>>> by such systems as the IBM System i, and the Mill.
>>>>
>>>
>>> Yeah.
>>>
>>>
>>>>> Granted, this does have the (fairly obvious) property that most
>>>>> traditional schemes for memory protection, ..., kinda go out the
>>>>> window when one has multiple logical processes within the same
>>>>> address space (as do the traditional distinctions between threads
>>>>> and processes).
>>>>
>>>> Not necessarily.  Just because multiple logical processes exist
>>>> within the same address space, doesn't mean that each process has
>>>> legal access to all the addresses within that space.
>>>>
>>>
>>> I was thinking of traditional schemes like "protection rings", ...
>>>
>>> So, say, a protection ring scheme will be pretty ineffective at
>>> protecting one program from another within a single address space.
>>
>> Not necessarily.  Most modern systems conflate two totally different
>> ideas into mechanism, so most people seem to think they are really the
>> same.  As I van pointed out in his response, don't confuse knowing
>> where something is with what rights to access it you have.
>>
>> You can watch Ivan's description of how the Mill separates the two
>> concepts on the Mill web site.
>>
>
> IIRC, Mill was using a capability architecture or something?...

I wish! But no, it's grant based, because fat pointers are not viable in
the market IMO.