Ivan Godard <ivan@millcomputing.com> schrieb:

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

Would the 128-bit pointers of System i qualify as fat pointers under
your definition?

On 10/10/2021 12:41 AM, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>>> 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.
>
> Would the 128-bit pointers of System i qualify as fat pointers under
> your definition?
>

Yes, but they are in a language system that is not trying to run legacy
decks that assumes 64-bit (or 32-bit) pointers. And they have IBM
marketing :-)

I don't know what System i does with a large C program fresh off gitHub.
Do you? The Unisys solution was to sandbox the whole thing, with no
internal protection at all.

CHERI is an interesting alternative to fat pointers. In the early days
of what became Mill we came up with a similar approach to theirs. The
(perhaps overhasty) conclusion was that we could get within a factor of
two of a legacy system performance, but not much better. The security
advantages would be a win; the reprogramming of data structures to fit
the changed sizes would be a lose.

The realization that protection could be divorced from mapping and hence
a grant system with skinny pointers could have legacy-like performance
or better but fat-pointer security made up our minds.

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 10/10/2021 12:41 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>>> 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.
>>
>> Would the 128-bit pointers of System i qualify as fat pointers under
>> your definition?
>>
>
> Yes, but they are in a language system that is not trying to run legacy
> decks that assumes 64-bit (or 32-bit) pointers. And they have IBM
> marketing :-)

And they have binary compatiblity with applications from the 1980s.

>
> I don't know what System i does with a large C program fresh off gitHub.
> Do you?

Unfortunately not. They have some open source support as claimed
in https://www.ibm.com/support/pages/open-source-support-ibm-i so
you could run Perl and PHP if you wanted to. There is also a
C compiler. It is likely that source off github would fall
down due to EBCDIC to start with :-)

On 10/10/2021 03:02, Victor Yodaiken wrote:
> 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.
>

The idea of C being a "high-level assembler" is right there in section
1, "Introduction".

Yes, I exaggerated somewhat, and clearly I was parodying and note
quoting. However, that /is/ the impression I got from the paper. I'm
sorry, but you appear to have some serious misunderstandings about the C
language, its tools, how it was originally intended to be used, how it
developed as a language, how its tools developed, and how its use
developed. The very title, "How ISO C became unusable for operating
systems development" shows that - C was /never/ intended or designed to
let you write operating systems purely in standard portable C. The
intention - which was achieved, and is still the case today - was that
you could write /most/ of the OS in at least reasonably portable C,
relying somewhat on implementation-dependent behaviour in parts.

And if you look at OS's today, that's what you see. Whether you look at
massive OS's like BSD or Linux, or small ones like FreeRTOS, you'll see
the great majority is written in plain standards-defined C. Some parts
are unavoidably written in assembly (either inline or stand-alone), some
parts are dependent on implementation details for the targets supported,
and sometimes the writers take advantage of compiler extensions or
features in order to write code that is more efficient, clearer, or
otherwise better than standard C alone.

Some details have changed since C's inception, but the principles have not.

On Saturday, October 9, 2021 at 8:36:41 PM UTC-5, Joe Pfeiffer wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
>
> > MitchAlsup <Mitch...@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)?
<
Be my guest, I wrote that extemporaneously.

Ivan Godard wrote:
> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
>>
>> 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.

What exactly is the distinction between a single address space
with page protection that allows multiple threads in that address space
access to some of those pages, and multiple address spaces with multiple
threads that allows access to some of those pages.

Because it sure sounds like the difference is just whether or not there is
a page-table-base pointer change on process switch, and if the TLB
supports ASID's Address Space ID's then there is no performance difference.

In other words, one page table with PTE's with fancy per-thread protection
keys that change when threads switch, is the same as multiple page tables
with PTE's with simple protection that map different memory sections.

Where is the functional distinction?
What can one do that the other can't?

> What exactly is the distinction between a single address space
> with page protection that allows multiple threads in that address space
> access to some of those pages, and multiple address spaces with multiple
> threads that allows access to some of those pages.

The L1 cache can be indexed and tagged by logical addresses and only needs
to check access rights (which can be spread over many cycles as long as
the answer comes before the corresponding instruction is committed)
rather than having to check address mappings as well (which can only be
spread until the moment that the cache line's tag is checked).

Stefan

On 10/10/2021 7:31 AM, EricP wrote:
> Ivan Godard wrote:
>> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
>>>
>>> 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.
>
> What exactly is the distinction between a single address space
> with page protection that allows multiple threads in that address space
> access to some of those pages, and multiple address spaces with multiple
> threads that allows access to some of those pages.
>
> Because it sure sounds like the difference is just whether or not there is
> a page-table-base pointer change on process switch, and if the TLB
> supports ASID's Address Space ID's then there is no performance difference.
>
> In other words, one page table with PTE's with fancy per-thread protection
> keys that change when threads switch, is the same as multiple page tables
> with PTE's with simple protection that map different memory sections.
>
> Where is the functional distinction?
> What can one do that the other can't?

A single address space permits VMAX (typically 2^64) of virtual total,
system wide, for all processes. A multiple address space permits TMAX
(typically 2^16 or so)*VMAX total of virtual, system wide.

That's the historical reason that mapping is used: so a 16-bit system
could have more that 16 bits worth of combined system and appp code
running. 64-bit spaces are not (yet) constraining enough to need
multiple spaces..

Stefan Monnier wrote:
>> What exactly is the distinction between a single address space
>> with page protection that allows multiple threads in that address space
>> access to some of those pages, and multiple address spaces with multiple
>> threads that allows access to some of those pages.
>
> The L1 cache can be indexed and tagged by logical addresses and only needs
> to check access rights (which can be spread over many cycles as long as
> the answer comes before the corresponding instruction is committed)
> rather than having to check address mappings as well (which can only be
> spread until the moment that the cache line's tag is checked).
>
>
> Stefan

As Meltdown shows, once information that should not be accessible
escapes a security domain it can be extremely difficult to track
down and retract all information that begets from it,
and things like power fluctuations are impossible to retract.

On 10/10/2021 10:10 AM, Ivan Godard wrote:
> On 10/10/2021 7:31 AM, EricP wrote:
>> Ivan Godard wrote:
>>> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
>>>>
>>>> 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.
>>
>> What exactly is the distinction between a single address space
>> with page protection that allows multiple threads in that address space
>> access to some of those pages, and multiple address spaces with multiple
>> threads that allows access to some of those pages.
>>
>> Because it sure sounds like the difference is just whether or not
>> there is
>> a page-table-base pointer change on process switch, and if the TLB
>> supports ASID's Address Space ID's then there is no performance
>> difference.
>>
>> In other words, one page table with PTE's with fancy per-thread
>> protection
>> keys that change when threads switch, is the same as multiple page tables
>> with PTE's with simple protection that map different memory sections.
>>
>> Where is the functional distinction?
>> What can one do that the other can't?
>
> A single address space permits VMAX (typically 2^64) of virtual total,
> system wide, for all processes. A multiple address space permits TMAX
> (typically 2^16 or so)*VMAX total of virtual, system wide.
>
> That's the historical reason that mapping is used: so a 16-bit system
> could have more that 16 bits worth of combined system and appp code
> running. 64-bit spaces are not (yet) constraining enough to need
> multiple spaces..

Yeah:
16-bits, pretty much everything will need multiple spaces
Even the first 8088/8086 PCs were already using 'far' pointers.
32-bits, could comfortably fit one program
Maybe several of them, if they are "fairly modest"
48 or 64 bits, could likely fit thousands of program instances.
96 or 128 bits, limit would be implausibly large...

This is excluding programs which reserve absurdly large address ranges
"because they can", but I consider this to be an aberration rather than
something which should be encouraged.

One does need to design the C ABI to be aware of the possibility of
multiple program instances in a single address space. For my ISA, I
ended up with a design I call PBO, which effectively accesses globals
via GBR (Global Base Register), and has a scheme by which one can get
from one GBR within a given process to any other GBR within the process
with a series of two memory loads.

Another scheme was ELF FDPIC, which can be used in a similar way. It
works by using multiple pointers for functions in the GOT, with the
target GOT being loaded from the current GOT on every function call.

The big drawback of FDPIC is that it has higher overheads:
All function calls need several additional pointer loads, ...
All global loads/stores need to be done indirectly via the GOT;
...

Though, looking at it, for an ISA design like RISC-V, something like
FDPIC would make more sense than PBO for the main reason that the ISA
lacks any real "sane" way to encode Load/Store displacements larger than
4kB. So, in effect, the cost of accessing globals via a GOT is likely to
be less than the cost of composing the large-displacement load/stores
needed for something like PBO.

Though, admittedly, I personally feel this is a design flaw in the
RISC-V ISA, rather than any particular merit to FDPIC.

....

On Sunday, October 10, 2021 at 10:10:31 AM UTC-5, Ivan Godard wrote:
> On 10/10/2021 7:31 AM, EricP wrote:
> > Ivan Godard wrote:
> >> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
> >>>
> >>> 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.
> >
> > What exactly is the distinction between a single address space
> > with page protection that allows multiple threads in that address space
> > access to some of those pages, and multiple address spaces with multiple
> > threads that allows access to some of those pages.
> >
> > Because it sure sounds like the difference is just whether or not there is
> > a page-table-base pointer change on process switch, and if the TLB
> > supports ASID's Address Space ID's then there is no performance difference.
> >
> > In other words, one page table with PTE's with fancy per-thread protection
> > keys that change when threads switch, is the same as multiple page tables
> > with PTE's with simple protection that map different memory sections.
> >
> > Where is the functional distinction?
> > What can one do that the other can't?
<
> A single address space permits VMAX (typically 2^64) of virtual total,
> system wide, for all processes. A multiple address space permits TMAX
> (typically 2^16 or so)*VMAX total of virtual, system wide.
<
Mc 88200 supported 2×VMAX {code and data could be in different VASs.}
Nobody used it that way.
Everybody used it as ½×VMAX {lower ½ was user upper ½ was supervisor}.
>
> That's the historical reason that mapping is used: so a 16-bit system
> could have more that 16 bits worth of combined system and appp code
> running. 64-bit spaces are not (yet) constraining enough to need
> multiple spaces..
<
PDP-11/70 had 16-bit user code+data and 16-bit supervisor code+data VASs.
And LD-From and ST-To instructions access.
<
I am coming around to this means of accessing another VAS; indeed, this seems
to be the cleanest way to implement ADA rendezvous where the caller and the
acceptor can be in different address spaces, running at different priorities, on
different cores, possibly different machines (i.e., over a network).
<
Acceptor has access to the callers VAS+arguments and can write acceptor
results back to callers VAS+results.
<
About the only thing this does not provide is access across different virtual
machines--at least directly.

On Sunday, October 10, 2021 at 11:38:32 AM UTC-5, BGB wrote:
> On 10/10/2021 10:10 AM, Ivan Godard wrote:
> > On 10/10/2021 7:31 AM, EricP wrote:
> >> Ivan Godard wrote:
> >>> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
> >>
> >> In other words, one page table with PTE's with fancy per-thread
> >> protection
> >> keys that change when threads switch, is the same as multiple page tables
> >> with PTE's with simple protection that map different memory sections.
> >>
> >> Where is the functional distinction?
> >> What can one do that the other can't?
> >
> > A single address space permits VMAX (typically 2^64) of virtual total,
> > system wide, for all processes. A multiple address space permits TMAX
> > (typically 2^16 or so)*VMAX total of virtual, system wide.
> >
> > That's the historical reason that mapping is used: so a 16-bit system
> > could have more that 16 bits worth of combined system and appp code
> > running. 64-bit spaces are not (yet) constraining enough to need
> > multiple spaces..
<
> Yeah:
> 16-bits, pretty much everything will need multiple spaces
> Even the first 8088/8086 PCs were already using 'far' pointers.
> 32-bits, could comfortably fit one program
> Maybe several of them, if they are "fairly modest"
> 48 or 64 bits, could likely fit thousands of program instances.
> 96 or 128 bits, limit would be implausibly large...
<
If we exclude designing NEW 16-bit address space machines (more because
the space is already filled and unlikely to make enough headway in cost/
perf to open up a new slot in that space) all we need to do is to not make
those kinds of mistakes in the machines we are designing now and into the
future.
>
> This is excluding programs which reserve absurdly large address ranges
> "because they can", but I consider this to be an aberration rather than
> something which should be encouraged.
>
One of the reasons My 66000 provides a complete 64-bit VAS is to allow
for what used to be absurdly large address ranges--for whatever SW wanted
to do with those.
>
> One does need to design the C ABI to be aware of the possibility of
> multiple program instances in a single address space. For my ISA, I
> ended up with a design I call PBO, which effectively accesses globals
> via GBR (Global Base Register), and has a scheme by which one can get
> from one GBR within a given process to any other GBR within the process
> with a series of two memory loads.
>
My 66000 is PIC and PID without using a register to keep track of "stuff".
{When R0 is used in the Base-register position of a memory reference IP is
substituted, and the rest of the tool chain understands the required mechanics}.
>
> Another scheme was ELF FDPIC, which can be used in a similar way. It
> works by using multiple pointers for functions in the GOT, with the
> target GOT being loaded from the current GOT on every function call.
>
My 66000 supports multiple GOTs also without consuming a register.
>
> The big drawback of FDPIC is that it has higher overheads:
> All function calls need several additional pointer loads, ...
> All global loads/stores need to be done indirectly via the GOT;
> ...
So, (as Ivan would say) don't do that !
<
My 66000 has tabularized function calls that neither waste a register nor
the delay through the LD-aligner and load a memory reference directly into
the IP. Suitable (higher end) HW can start the instruction fetch even BEFORE
the function call address gets to the IP !! Eliminating most of this overhead.
<
Global LDs and STs can use a 64-bit offset along with base (or IP) and
indexing in a single instruction.
>
>
> Though, looking at it, for an ISA design like RISC-V, something like
> FDPIC would make more sense than PBO for the main reason that the ISA
> lacks any real "sane" way to encode Load/Store displacements larger than
> 4kB. So, in effect, the cost of accessing globals via a GOT is likely to
> be less than the cost of composing the large-displacement load/stores
> needed for something like PBO.
>
> Though, admittedly, I personally feel this is a design flaw in the
> RISC-V ISA, rather than any particular merit to FDPIC.
>
I strongly agree with you that this is a big FLAW of RISC-V; maybe not major
but big, nonetheless.
> ...

On 10/10/2021 9:57 AM, MitchAlsup wrote:
> On Sunday, October 10, 2021 at 10:10:31 AM UTC-5, Ivan Godard wrote:
>> On 10/10/2021 7:31 AM, EricP wrote:
>>> Ivan Godard wrote:
>>>> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
>>>>>
>>>>> 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.
>>>
>>> What exactly is the distinction between a single address space
>>> with page protection that allows multiple threads in that address space
>>> access to some of those pages, and multiple address spaces with multiple
>>> threads that allows access to some of those pages.
>>>
>>> Because it sure sounds like the difference is just whether or not there is
>>> a page-table-base pointer change on process switch, and if the TLB
>>> supports ASID's Address Space ID's then there is no performance difference.
>>>
>>> In other words, one page table with PTE's with fancy per-thread protection
>>> keys that change when threads switch, is the same as multiple page tables
>>> with PTE's with simple protection that map different memory sections.
>>>
>>> Where is the functional distinction?
>>> What can one do that the other can't?
> <
>> A single address space permits VMAX (typically 2^64) of virtual total,
>> system wide, for all processes. A multiple address space permits TMAX
>> (typically 2^16 or so)*VMAX total of virtual, system wide.
> <
> Mc 88200 supported 2×VMAX {code and data could be in different VASs.}
> Nobody used it that way.
> Everybody used it as ½×VMAX {lower ½ was user upper ½ was supervisor}.
>>
>> That's the historical reason that mapping is used: so a 16-bit system
>> could have more that 16 bits worth of combined system and appp code
>> running. 64-bit spaces are not (yet) constraining enough to need
>> multiple spaces..
> <
> PDP-11/70 had 16-bit user code+data and 16-bit supervisor code+data VASs.
> And LD-From and ST-To instructions access.
> <
> I am coming around to this means of accessing another VAS; indeed, this seems
> to be the cleanest way to implement ADA rendezvous where the caller and the
> acceptor can be in different address spaces, running at different priorities, on
> different cores, possibly different machines (i.e., over a network).
> <
> Acceptor has access to the callers VAS+arguments and can write acceptor
> results back to callers VAS+results.
> <
> About the only thing this does not provide is access across different virtual
> machines--at least directly.
>

How do you bound the access to only the argument (var. result) regions?

How do you pass an object by reference? (e.g. an out-of-regs shared buffer)

In article <sjv4u6$37u$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> 32-bits, could comfortably fit one program
> Maybe several of them, if they are "fairly modest"
> 48 or 64 bits, could likely fit thousands of program instances.

> This is excluding programs which reserve absurdly large address
> ranges "because they can", but I consider this to be an aberration
> rather than something which should be encouraged.

Some programs do need to be able to handle sets of data, in RAM, that are
too large to fit into 32-bit addressing. There aren't huge numbers of
them, but they definitely exist.

> Though, looking at it, for an ISA design like RISC-V, something
> like FDPIC would make more sense than PBO for the main reason that
> the ISA lacks any real "sane" way to encode Load/Store
> displacements larger than 4kB.

That is a definite limitation. Having large offsets be a little slower is
perfectly acceptable, but requiring compilers to set up pointers to, for
example, part-way up a large array is clumsy.

John

John Dallman <jgd@cix.co.uk> schrieb:
> In article <sjv4u6$37u$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:
>
>> 32-bits, could comfortably fit one program
>> Maybe several of them, if they are "fairly modest"
>> 48 or 64 bits, could likely fit thousands of program instances.
>
>> This is excluding programs which reserve absurdly large address
>> ranges "because they can", but I consider this to be an aberration
>> rather than something which should be encouraged.
>
> Some programs do need to be able to handle sets of data, in RAM, that are
> too large to fit into 32-bit addressing. There aren't huge numbers of
> them, but they definitely exist.

Compuational fluid dynamics.

With today's problems, with 32-bit addressing (well, usually less
than that) you can just go home.

On Sunday, October 10, 2021 at 12:56:25 PM UTC-5, Ivan Godard wrote:
> On 10/10/2021 9:57 AM, MitchAlsup wrote:
> > On Sunday, October 10, 2021 at 10:10:31 AM UTC-5, Ivan Godard wrote:
> >> On 10/10/2021 7:31 AM, EricP wrote:
> >>> Ivan Godard wrote:
> >>>> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
> >>>>>
> >>>>> 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.
> >>>
> >>> What exactly is the distinction between a single address space
> >>> with page protection that allows multiple threads in that address space
> >>> access to some of those pages, and multiple address spaces with multiple
> >>> threads that allows access to some of those pages.
> >>>
> >>> Because it sure sounds like the difference is just whether or not there is
> >>> a page-table-base pointer change on process switch, and if the TLB
> >>> supports ASID's Address Space ID's then there is no performance difference.
> >>>
> >>> In other words, one page table with PTE's with fancy per-thread protection
> >>> keys that change when threads switch, is the same as multiple page tables
> >>> with PTE's with simple protection that map different memory sections.
> >>>
> >>> Where is the functional distinction?
> >>> What can one do that the other can't?
> > <
> >> A single address space permits VMAX (typically 2^64) of virtual total,
> >> system wide, for all processes. A multiple address space permits TMAX
> >> (typically 2^16 or so)*VMAX total of virtual, system wide.
> > <
> > Mc 88200 supported 2×VMAX {code and data could be in different VASs.}
> > Nobody used it that way.
> > Everybody used it as ½×VMAX {lower ½ was user upper ½ was supervisor}.
> >>
> >> That's the historical reason that mapping is used: so a 16-bit system
> >> could have more that 16 bits worth of combined system and appp code
> >> running. 64-bit spaces are not (yet) constraining enough to need
> >> multiple spaces..
> > <
> > PDP-11/70 had 16-bit user code+data and 16-bit supervisor code+data VASs.
> > And LD-From and ST-To instructions access.
> > <
> > I am coming around to this means of accessing another VAS; indeed, this seems
> > to be the cleanest way to implement ADA rendezvous where the caller and the
> > acceptor can be in different address spaces, running at different priorities, on
> > different cores, possibly different machines (i.e., over a network).
> > <
> > Acceptor has access to the callers VAS+arguments and can write acceptor
> > results back to callers VAS+results.
> > <
> > About the only thing this does not provide is access across different virtual
> > machines--at least directly.
> >
> How do you bound the access to only the argument (var. result) regions?
<
I am expecting ADA to be reasonable (i.e., ADA), here. During argument evaluation
ADA will not create a dope vector that exceeds the actual passed data area (checked
on the way out). During use of argument the acceptor will not violate (checked on the
way in) the dope vector constraints.
>
> How do you pass an object by reference? (e.g. an out-of-regs shared buffer)
<
Argument passed as in normal ABI (other than the caller knowing the call is to an
accept), the caller evaluates arguments just like any other call. The process of
rendezvous passes a Root pointer and a pointer to the <now stored> caller register
file in places (control registers) only an acceptor is taught where to look (by the
compiler). I may make access to these control registers raise exceptions if not
in an Accept (it is not hard to tell). (I probably should........)

On Sunday, October 10, 2021 at 1:33:59 PM UTC-5, John Dallman wrote:
> In article <sjv4u6$37u$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:
>
> > 32-bits, could comfortably fit one program
> > Maybe several of them, if they are "fairly modest"
> > 48 or 64 bits, could likely fit thousands of program instances.
> > This is excluding programs which reserve absurdly large address
> > ranges "because they can", but I consider this to be an aberration
> > rather than something which should be encouraged.
<
> Some programs do need to be able to handle sets of data, in RAM, that are
> too large to fit into 32-bit addressing. There aren't huge numbers of
> them, but they definitely exist.
<
In a 64-bit virtual address space, the user should be able to create holes
in the virtual address space as large as 2^62 (I might be argued down to
2^60). Certainly no OS needs to grow bigger than 2^53......
<
> > Though, looking at it, for an ISA design like RISC-V, something
> > like FDPIC would make more sense than PBO for the main reason that
> > the ISA lacks any real "sane" way to encode Load/Store
> > displacements larger than 4kB.
> That is a definite limitation. Having large offsets be a little slower is
> perfectly acceptable, but requiring compilers to set up pointers to, for
> example, part-way up a large array is clumsy.
<
Which is why My 66000 provides 16-bit, 32-bit and 64-bit offsets in LD
and ST instructions. Higher end machines will suffer no penalty in using
large offsets, lowest end machines will still take FEWER cycles than if
they had to manufacture constants (LDHI or Constant Pool). This saves
size (code footprint is smaller, data footprint is smaller, fetch I$ access
count is smaller, and there is no data cache pollution of that which is a
code problem.)
<
No sane instruction set should cause the compiler to manufacture
(or fetch) compile time constants at run time.
>
> John

On Sunday, October 10, 2021 at 1:39:45 PM UTC-5, Thomas Koenig wrote:
> John Dallman <j...@cix.co.uk> schrieb:
> > In article <sjv4u6$37u$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:
> >
> >> 32-bits, could comfortably fit one program
> >> Maybe several of them, if they are "fairly modest"
> >> 48 or 64 bits, could likely fit thousands of program instances.
> >
> >> This is excluding programs which reserve absurdly large address
> >> ranges "because they can", but I consider this to be an aberration
> >> rather than something which should be encouraged.
> >
> > Some programs do need to be able to handle sets of data, in RAM, that are
> > too large to fit into 32-bit addressing. There aren't huge numbers of
> > them, but they definitely exist.
> Compuational fluid dynamics.
>
> With today's problems, with 32-bit addressing (well, usually less
> than that) you can just go home.
<
A decade ago (can it be that long) I was doing 1D CFD on intake and
exhaust systems for automotive engines. These applications would
sometimes run for several days (24/7) on my 6 core system, but
never used "that much memory". The operating mesh had hundreds of
thousands of boundary constraints (mostly pipe walls).
<
Perhaps 2D CFD and 3D CFD exponentiate my experience.......

According to Ivan Godard <ivan@millcomputing.com>:
>> Where is the functional distinction?
>> What can one do that the other can't?
>
>A single address space permits VMAX (typically 2^64) of virtual total,
>system wide, for all processes. A multiple address space permits TMAX
>(typically 2^16 or so)*VMAX total of virtual, system wide.
>
>That's the historical reason that mapping is used: so a 16-bit system
>could have more that 16 bits worth of combined system and appp code
>running. 64-bit spaces are not (yet) constraining enough to need
>multiple spaces..

That's one reason, the other flips it around, so the application address space could be
bigger than physical memory, and you fake it with paging. You probably remember static
shared libraries, which loaded at the same place in every process, something that needs
an address space per process to work.

It is my impression that once you have enough hardware to handle paging in one application
address space, multiple address spaces aren't much harder.

--
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 Sun, 10 Oct 2021 01:18:07 -0700, Ivan Godard
<ivan@millcomputing.com> wrote:

>On 10/10/2021 12:41 AM, Thomas Koenig wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>>
>>>> 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.
>>
>> Would the 128-bit pointers of System i qualify as fat pointers under
>> your definition?
>>
>
>Yes, but they are in a language system that is not trying to run legacy
>decks that assumes 64-bit (or 32-bit) pointers. And they have IBM
>marketing :-)
>
>I don't know what System i does with a large C program fresh off gitHub.
>Do you? The Unisys solution was to sandbox the whole thing, with no
>internal protection at all.

A nitpick - the Burroughs side of Unisys sandboxs the entire thing,
the Univac side doesn't. The Univac side also splits protection from
addressing, and uses an underlying single virtual adress space
(providing an existing counter-example to those who claim such a thing
is not possible). Based upon the number of reported cases of someone
getting around the protection on OS2200, it seems to work.
>
>CHERI is an interesting alternative to fat pointers. In the early days
>of what became Mill we came up with a similar approach to theirs. The
>(perhaps overhasty) conclusion was that we could get within a factor of
>two of a legacy system performance, but not much better. The security
>advantages would be a win; the reprogramming of data structures to fit
>the changed sizes would be a lose.
>
>The realization that protection could be divorced from mapping and hence
>a grant system with skinny pointers could have legacy-like performance
>or better but fat-pointer security made up our minds.

This strikes me as a sensible decision, I just hope to see
implementations.

On Sunday, October 10, 2021 at 2:00:37 PM UTC-5, John Levine wrote:
> According to Ivan Godard <iv...@millcomputing.com>:
> >> Where is the functional distinction?
> >> What can one do that the other can't?
> >
> >A single address space permits VMAX (typically 2^64) of virtual total,
> >system wide, for all processes. A multiple address space permits TMAX
> >(typically 2^16 or so)*VMAX total of virtual, system wide.
> >
> >That's the historical reason that mapping is used: so a 16-bit system
> >could have more that 16 bits worth of combined system and appp code
> >running. 64-bit spaces are not (yet) constraining enough to need
> >multiple spaces..
> That's one reason, the other flips it around, so the application address space could be
> bigger than physical memory, and you fake it with paging. You probably remember static
> shared libraries, which loaded at the same place in every process, something that needs
> an address space per process to work.
<
In a 64-bit VAS the same trick works--all libraries get mapped to different "places",
and everyone can share equally, you just have to get those "places" defined well.
>
> It is my impression that once you have enough hardware to handle paging in one application
> address space, multiple address spaces aren't much harder.
<
I can attest to that.
>
> --
> 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 10/10/2021 12:13 PM, MitchAlsup wrote:
> On Sunday, October 10, 2021 at 11:38:32 AM UTC-5, BGB wrote:
>> On 10/10/2021 10:10 AM, Ivan Godard wrote:
>>> On 10/10/2021 7:31 AM, EricP wrote:
>>>> Ivan Godard wrote:
>>>>> On 10/8/2021 11:25 PM, Stephen Fuld wrote:
>>>>
>>>> In other words, one page table with PTE's with fancy per-thread
>>>> protection
>>>> keys that change when threads switch, is the same as multiple page tables
>>>> with PTE's with simple protection that map different memory sections.
>>>>
>>>> Where is the functional distinction?
>>>> What can one do that the other can't?
>>>
>>> A single address space permits VMAX (typically 2^64) of virtual total,
>>> system wide, for all processes. A multiple address space permits TMAX
>>> (typically 2^16 or so)*VMAX total of virtual, system wide.
>>>
>>> That's the historical reason that mapping is used: so a 16-bit system
>>> could have more that 16 bits worth of combined system and appp code
>>> running. 64-bit spaces are not (yet) constraining enough to need
>>> multiple spaces..
> <
>> Yeah:
>> 16-bits, pretty much everything will need multiple spaces
>> Even the first 8088/8086 PCs were already using 'far' pointers.
>> 32-bits, could comfortably fit one program
>> Maybe several of them, if they are "fairly modest"
>> 48 or 64 bits, could likely fit thousands of program instances.
>> 96 or 128 bits, limit would be implausibly large...
> <
> If we exclude designing NEW 16-bit address space machines (more because
> the space is already filled and unlikely to make enough headway in cost/
> perf to open up a new slot in that space) all we need to do is to not make
> those kinds of mistakes in the machines we are designing now and into the
> future.

Yeah, apart from small microcontrollers, a 16-bit address space is
insufficient...

One could "maybe" do a 16-bit machine with register-pairing for 32-bit
addresses and data, but at this point one may as well just design it as
a 32-bit ISA and then using like it were a 16-bit ISA (this practice
seems to be semi-common in Cortex-M land).

>>
>> This is excluding programs which reserve absurdly large address ranges
>> "because they can", but I consider this to be an aberration rather than
>> something which should be encouraged.
>>
> One of the reasons My 66000 provides a complete 64-bit VAS is to allow
> for what used to be absurdly large address ranges--for whatever SW wanted
> to do with those.

It is possible, but programs doing this sort of thing effectively
precludes sticking multiple programs into a single address space.

Well, unless one has a 96 bit space and then allows each program to
address up to 256TB or so.

>>
>> One does need to design the C ABI to be aware of the possibility of
>> multiple program instances in a single address space. For my ISA, I
>> ended up with a design I call PBO, which effectively accesses globals
>> via GBR (Global Base Register), and has a scheme by which one can get
>> from one GBR within a given process to any other GBR within the process
>> with a series of two memory loads.
>>
> My 66000 is PIC and PID without using a register to keep track of "stuff".
> {When R0 is used in the Base-register position of a memory reference IP is
> substituted, and the rest of the tool chain understands the required mechanics}.

BJX2 supports PC-relative addressing as well.

But, GBR is used for the PBO ABI because this allows effectively
decoupling the ".text" section (and related read-only sections), from
the ".data" and ".bss" sections (which are unique to each program instance).

Arguably, with an MMU, one multi-map the same PIC binary to multiple
places in the address space, but then one is wasting address space
multi-mapping the ".text" sections.

>>
>> Another scheme was ELF FDPIC, which can be used in a similar way. It
>> works by using multiple pointers for functions in the GOT, with the
>> target GOT being loaded from the current GOT on every function call.
>>
> My 66000 supports multiple GOTs also without consuming a register.

OK.

>>
>> The big drawback of FDPIC is that it has higher overheads:
>> All function calls need several additional pointer loads, ...
>> All global loads/stores need to be done indirectly via the GOT;
>> ...
> So, (as Ivan would say) don't do that !
> <
> My 66000 has tabularized function calls that neither waste a register nor
> the delay through the LD-aligner and load a memory reference directly into
> the IP. Suitable (higher end) HW can start the instruction fetch even BEFORE
> the function call address gets to the IP !! Eliminating most of this overhead.
> <
> Global LDs and STs can use a 64-bit offset along with base (or IP) and
> indexing in a single instruction.

In BJX2, I can also do simple direct jumps.

The design of the PBO ABI puts the responsibility of the GBR reload onto
the called function, which in turn is only needed in certain cases:
DLL exports;
Function pointers which are also non-leaf and/or access global variables.

Pretty much all other interior functions assume that GBR points to the
correct data section.

So, average case overhead can be reduced to the level of being
"negligible" for most programs.

>>
>>
>> Though, looking at it, for an ISA design like RISC-V, something like
>> FDPIC would make more sense than PBO for the main reason that the ISA
>> lacks any real "sane" way to encode Load/Store displacements larger than
>> 4kB. So, in effect, the cost of accessing globals via a GOT is likely to
>> be less than the cost of composing the large-displacement load/stores
>> needed for something like PBO.
>>
>> Though, admittedly, I personally feel this is a design flaw in the
>> RISC-V ISA, rather than any particular merit to FDPIC.
>>
> I strongly agree with you that this is a big FLAW of RISC-V; maybe not major
> but big, nonetheless.

Yeah. Making ELF FDPIC able to win in a "lesser of two evils" sense is
not exactly a merit, in any case...

Well, I have a 12 bit displacement, fair enough:
LW Rd, Rm, Disp12 //all is good up to 4K

But, beyond 4K?

LUI Rt, DispHi
ADD Rt, Rm, Rt
LW Rd, Rt, DispLo

Yeah, errm, this kinda sucks...

Granted, something like:
LD Rt, Rgot, Disp12
LW Rd, Rt, 0

Also still kinda sucks (slightly smaller, would require intermediate
instructions between the loads to avoid interlock penalties though).

Earlier forms of BJX2 had:
LDIX Disp24, R0
MOV.L (Rm, R0), Rd
But, now I have:
MOV.L (Rm, Disp33s), Rd // 64-bit encoding, minimum 1-cycle

Where, Rm can also encode PC or GBR:
MOV.L (PC, Disp33s), Rd //same
MOV.L (GBR, Disp33s), Rd //same

Though, for PC-rel, BGBCC still uses the older construct, mostly because
PC-Rel-Jumbo-Disp33s would require me to go and add a new reloc type for
a situation which is relatively infrequent with the PBO ABI (usually
comes up in the context of 'const arrays' and similar).

So, say, accessing a const array:
LDIX Disp24, R0 //can be eliminated in-theory.
LEA.B (PC, R0), Ra //get address of array into 'Ra'
...
MOV.Q (Ra, Ri), Rd

Whereas, within a given basic block, each access to the array will use a
single memory load.

According to John Dallman <jgd@cix.co.uk>:
>> This is excluding programs which reserve absurdly large address
>> ranges "because they can", but I consider this to be an aberration
>> rather than something which should be encouraged.
>
>Some programs do need to be able to handle sets of data, in RAM, that are
>too large to fit into 32-bit addressing. There aren't huge numbers of
>them, but they definitely exist.

Databases will buffer as much as they can in RAM. If your machine can give
your database ten gig of RAM, it can do useful things with it, assuming
you have databases that big which these days you probably do.

--
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/10/2021 2:00 PM, John Levine wrote:
> According to Ivan Godard <ivan@millcomputing.com>:
>>> Where is the functional distinction?
>>> What can one do that the other can't?
>>
>> A single address space permits VMAX (typically 2^64) of virtual total,
>> system wide, for all processes. A multiple address space permits TMAX
>> (typically 2^16 or so)*VMAX total of virtual, system wide.
>>
>> That's the historical reason that mapping is used: so a 16-bit system
>> could have more that 16 bits worth of combined system and appp code
>> running. 64-bit spaces are not (yet) constraining enough to need
>> multiple spaces..
>
> That's one reason, the other flips it around, so the application address space could be
> bigger than physical memory, and you fake it with paging. You probably remember static
> shared libraries, which loaded at the same place in every process, something that needs
> an address space per process to work.
>
> It is my impression that once you have enough hardware to handle paging in one application
> address space, multiple address spaces aren't much harder.
>

Harder... No.
Slower... Yes.

As noted, in my case there is little stopping the MMU from being used
for multiple address spaces. It is a little more awkward for an OS
kernel, but doesn't really effect the HW all that much.

However, the more obvious issue is that, as soon as one switches address
spaces, none of the contents of the TLB are relevant anyone. So, every
task switch is very likely to be followed by potentially a few thousand
cycles worth of TLB reloads.

If it is a single address space, then it is likely that any shared
contents (such as OS provided libraries, ...) will still be in the TLB
following a task switch.

An ASID could help, if one assumes that some of the old contents remain
in the TLB by the time the scheduler cycles back around.

Another possible option though could be a hierarchical ASID, say:
ASID: 6b=AGID, 10b=APID
Where a TLBE:
ASID=0, Globally Valid
AGID!=0, APID=0: Valid so long as AGID matches.
AGID!=0, APID!=0: Valid if ASID's are equal.

With the ASID being in the same encoding space as VUGID.

The ASID bits are partly co-opted in the split TLBE scheme for 96-bit
addressing though, so it is likely that in 96-bit mode the MMU would not
have ASID's (well, along with some debate as to whether it would reduce
TLB associativity, or add a separate smaller TLB for matching address
bits 95:48...).

In article <sjvesb$a36$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> The design of the PBO ABI puts the responsibility of the GBR reload
> onto the called function, which in turn is only needed in certain
> cases: ...
> Function pointers which are also non-leaf and/or access global
> variables.

How does the compiler know, when compiling a function, if it will be
called via a pointer?

John