Re: 64-bit embedded computing is here and now

From	Don Y <blockedofcourse@foo.invalid>
Newsgroups	comp.arch.embedded
Subject	Re: 64-bit embedded computing is here and now
Date	2021-06-10 21:55 -0700
Organization	A noiseless patient Spider
Message-ID	<s9uqcf$8ih$1@dont-email.me> (permalink)
References	(9 earlier) <s9sqgv$1l6$1@dont-email.me> <s9t5ku$fd5$1@dont-email.me> <s9tba9$pmh$1@dont-email.me> <s9tv2l$1ub$1@dont-email.me> <s9u2q4$29e$1@dont-email.me>

Show all headers | View raw

On 6/10/2021 3:13 PM, Dimiter_Popoff wrote:
> On 6/11/2021 0:09, Don Y wrote:
>> On 6/10/2021 8:32 AM, Dimiter_Popoff wrote:
>>> On 6/10/2021 16:55, Don Y wrote:
>>>> On 6/10/2021 3:45 AM, Dimiter_Popoff wrote:
>>>>
>>>> [attrs elided]
>>>  >
>>> Don, this becomes way too lengthy and repeating itself.
>>>
>>> You keep on saying that a linear 64 bit address space means exposing
>>> everything to everybody after I explained this is not true at all.
>>
>> Task A has built a structure -- a page worth of data residing
>> at 0x123456.  It wants to pass this to TaskB so that TaskB can perform
>> some operations on it.
>>
>> Can TaskB acccess the data at 0x123456 *before* TaskA has told it
>> to do so >
>> Can TaskB access the data at 0x123456 WHILE TaskA is manipulating it?
>>
>> Can TaskA alter the data at 0x123456 *after* it has "passed it along"
>> to TaskB -- possibly while TaskB is still using it?
> 
> If task A does not want any of the above it just places them in a
> page to which it only has access. Or it can allow read access only.
> *Why* do you confuse this with linear address space? What does the
> one have to do with the other?

As I tease more of your design out of you, it becomes apparent why
you "need" a flat address space.  You push much of the responsibility
for managing the environment into the developer's hands.  *He* decides
which regions of memory to share.  He talks to the MMU (even if through
an API).  He directly retrieves values from other tasks.  Etc.

So, he must be able to get anywhere and do anything at any time
(by altering permissions, if need be).

By contrast, I remove all of that from the developer's shoulders.
I only expect a developer to be able to read the IDL for the
objects that he "needs" to access and understand the syntax required
for each such access (RMI/RPC).  The machine LOOKS like it is
a simple uniprocessor with no synchronization issues that the
developer has to contend with, no network addressing, no cache
or memory management, etc.

EVERYTHING is done *indirectly* in my world.  Much like a file system
interface (your developer doesn't directly write bytes onto the disk
but, rather, lets the file system resolve a filename and create
a file handle which is then used to route bytes to the media).

The interface to EVERYTHING in my system is through such an
extra layer of indirection.  Because things exist in different
address spaces, on different processors, etc. the OS mediates
all such accesses.  ALL of them!  Yes, it's inefficient.  But,
the processor runs at 500MHz and I have 244 of them in my
(small!) alpha site -- I figure I can *afford* to be a little
inefficient (especially as you want to *minimize* interactions
between objects just as a general design goal)

Because of this, I can enforce fine-grained protection mechanisms;
I can let you increment a counter -- but not decrement it
(assuming a counter is an object).  Or, let you read its contents
but never alter them.  Meanwhile, some other client (task)
can reset it but never read it.

And, the OS can act as a bridge/proxy to an object residing on
a different node -- what "address" do you access to reference
Counter 34 on node 56?  Who tells you that it resides on 56
and hasn't been moved to node 29??

Because the OS can provide that proxy interface, I can *move*
an object between successive accesses -- without its clients
knowing this has happened.  As if the file server you
are accessing had suddenly been replaced by another machine
at a different IP address WHILE you were accessing files!

Likewise, because the access is indirect, I can interpose
an agency on selective objects to implement redundancy for that
object without the client using THAT interface ever knowing.

Or, support different versions of an interface simultaneously
(which address do you access to see the value of the
counter as an unsigned binary long?  which address to see
it as a floating point number?  which address to see it
as an ASCII string?)

Note that I can do all of these things with a flat *or* overlapping
address space.  Because a task doesn't need to be able to DIRECTLY
access anything -- other than the system trap!

You, on the other hand, have to build a different mechanism (e.g.,
your distributed filesystem) to access certain TYPES of objects
(e.g., files) without concern for their location.  That ability
comes "free" for EVERY type of object in my world.

It is essential as I expect to be interacting with other nodes
continuously -- and those nodes can be powered up or down
independent of my wishes.  Can I pull a board out of your MCA
and expect it to keep running?  Unplug one of my nodes (or
cut the cable, light it on fire, etc.) and there will be
a hiccup while I respawn the services/objects that were
running on that node to another node.  But, clients of
those services/objects will just see a prolonged RMI/RPC
(if one was in progress when the node was killed)

Note that I've not claimed it is "better".  What I have claimed
is that it "does more" (than <whatever>).  And, because it does
more (because I EXPECT it to), any perceived advantages of a
flat address space are just down in the "noise floor".  They
don't factor into the implementation decisions.  By the time I
"bolted on" these features OUTSIDE your OS onto your implementation,
I'd have a BIGGER solution to the same problem!

["Access this memory address directly -- unless the object you want
has been moved to another node.  In which case, access this OTHER
address to figure out where it's gone to; then access yet another
address to actually do what you initially set out to do, had the
object remained 'local'"]

This sums up our differences:

> Why would you want to protect regions you don't want protected?

Why WOULDN"T you want to protect EVERYTHING??

Sharing should be an exception.  It should be more expensive to
share than NOT to share.  You don't want things comingling unless
they absolutely MUST.  And, the more such interaction, the more
you should look at the parties involved to see if refactoring
may be warranted.  "Opaque" is the operative word.  The more
you expose, the more interdependencies you create.

Thread

64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-07 07:47 -0700
  Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-07 14:13 -0700
  Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-07 22:31 -0700
    Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 07:59 +0200
      Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 00:39 -0700
        Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 13:04 +0200
          Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 17:30 -0700
            Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 09:17 +0200
              Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 03:12 -0700
                Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-12 12:58 -0400
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-12 12:40 -0700
              Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 09:41 -0700
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 10:12 -0700
                Re: 64-bit embedded computing is here and now DJ Delorie <dj@delorie.com> - 2021-06-09 13:16 -0400
                Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 13:44 -0400
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:03 +0300
                Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 15:22 -0400
                Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 12:58 -0700
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:26 -0700
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 23:12 +0300
        Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 12:38 -0700
          Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:11 +0200
            Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 14:25 -0700
            Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-09 00:16 -0400
              Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:40 +0200
                Re: 64-bit embedded computing is here and now Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-06-09 22:52 +0200
                Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-10 09:37 +0200
          Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 01:01 +0300
            Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:29 -0700
              Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 20:56 +0300
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 17:12 -0700
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 13:45 +0300
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 06:55 -0700
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 18:32 +0300
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 14:09 -0700
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 01:13 +0300
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 21:55 -0700
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 14:14 +0300
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 05:10 -0700
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 16:35 +0300
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 16:24 -0700
              Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-14 05:41 -0400
          Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:51 -0700
          Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-08 18:20 -0700
            Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 18:07 +0100
              Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 10:34 -0700
                Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:37 -0700
              Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:43 -0700
      Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-08 15:46 +0100
        Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:18 +0200
          Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-08 23:39 +0300
            Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:33 -0700
            Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:59 +0200
              Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 21:00 +0300
                Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 20:55 +0200
                Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:06 +0300
        Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:00 -0700
          Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 13:10 +0100
            Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 06:19 -0700

csiph-web