Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #742327 > unrolled thread

software situation

Back to article view | Back to sci.electronics.design

Contents

  software situation john larkin <jl@glen--canyon.com> - 2026-03-26 10:58 -0700
    Re: software situation Sergey Kubushyn <ksi@koi8.net> - 2026-03-26 20:29 +0000
      Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-26 17:51 -0700
        Re: software situation Sergey Kubushyn <ksi@koi8.net> - 2026-03-27 02:03 +0000
          Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-26 21:41 -0700
            Re: software situation Sergey Kubushyn <ksi@koi8.net> - 2026-03-27 06:09 +0000
              Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 04:15 -0700
            Re: software situation Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-27 10:07 +0000
              Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 05:37 -0700
                Re: software situation Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-27 18:24 +0000
                  Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 12:04 -0700
                    Re: software situation Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-27 22:35 +0000
                      Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 15:58 -0700
                      Re: software situation Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-29 09:24 +0000
          Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-27 10:00 -0700
            Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-27 10:17 -0700
              Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-27 10:32 -0700
                Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-27 11:22 -0700
                Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 11:34 -0700
                  Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-28 06:41 -0700
                    Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-28 13:56 -0700
                      Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-29 05:53 -0700
                        Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-29 12:39 -0700
                          Re: software situation john larkin <jl@glen--canyon.com> - 2026-03-29 13:13 -0700
                          Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-29 14:29 -0700
                            Re: software situation john larkin <jl@glen--canyon.com> - 2026-03-29 15:24 -0700
                              Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-29 20:54 -0700
                                Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-29 21:07 -0700
                                  Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-29 21:16 -0700
                                Re: software situation john larkin <jl@glen--canyon.com> - 2026-03-30 07:44 -0700
                                  Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-30 09:02 -0700
                                    Re: software situation john larkin <jl@glen--canyon.com> - 2026-03-30 16:00 -0700
                            Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-29 17:09 -0700
                              Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-29 20:48 -0700
                Re: software situation Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-27 21:38 +0000
        Re: software situation someone <cffbf4deb9142bce48974efc0e64dede@example.com> - 2026-03-27 04:30 +0000
        Re: software situation Joerg <news@analogconsultants.com> - 2026-03-27 10:35 -0700
          Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 11:27 -0700
            Re: software situation Joerg <news@analogconsultants.com> - 2026-03-27 11:46 -0700
              Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 14:54 -0700
    Re: software situation someone <cffbf4deb9142bce48974efc0e64dede@example.com> - 2026-03-27 04:30 +0000
      Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-03-27 07:41 -0700
        Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-03-27 16:04 -0700
        Re: software situation someone <cffbf4deb9142bce48974efc0e64dede@example.com> - 2026-03-30 23:30 +0000
          Re: software situation john larkin <jl@glen--canyon.com> - 2026-03-31 11:01 -0700
            Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-03-31 13:54 -0700
              Re: software situation john larkin <jl@glen--canyon.com> - 2026-03-31 15:06 -0700
                Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-03-31 16:14 -0700
                  Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-03-31 16:43 -0700
                  Re: software situation Jan Panteltje <alien@comet.invalid> - 2026-04-01 06:41 +0000
                    Re: software situation john larkin <jl@glen--canyon.com> - 2026-04-01 00:49 -0700
                      Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-04-01 17:39 -0700
          Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-03-31 14:15 -0700
            Re: software situation Jan Panteltje <alien@comet.invalid> - 2026-04-01 06:45 +0000
              Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-04-01 09:11 -0700
                Re: software situation Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-04-01 09:43 -0700
                Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-04-01 10:35 -0700
      Re: software situation john larkin <jl@glen--canyon.com> - 2026-03-27 08:16 -0700
        Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-03-27 09:01 -0700
          Re: software situation Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-27 17:57 +0000
            Re: software situation Jeff Liebermann <jeffl@cruzio.com> - 2026-03-27 15:06 -0700
              Re: software situation Don Y <blockedofcourse@foo.invalid> - 2026-03-27 15:48 -0700
              Re: software situation Nioclás Pól Caileán de Ghloucester <thanks-to@Taf.com> - 2026-03-28 00:44 +0000
        Re: software situation someone <cffbf4deb9142bce48974efc0e64dede@example.com> - 2026-03-30 23:30 +0000
    Re: software situation Jan Panteltje <alien@comet.invalid> - 2026-03-27 08:03 +0000
    Re: software situation someone <cffbf4deb9142bce48974efc0e64dede@example.com> - 2026-03-30 23:30 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#742430

On 3/28/2026 6:41 AM, Ross Finlayson wrote:
> Ah, here the idea of "co-operative scheduler" (vis-a-vis
> "pre-emptive scheduler") has that there's a notion of the
> model of an o.s. (scheduler, allocator) of co-operation
> vis-a-vis "the re-routine", which is a sort of idea like
> "co-routine", where basically everything is non-blocking
> by design and convention, and instead of a co-routine stack
> is a sort of memo-ized monad, then about matters of the
> scheduling like "I cut you pick", "straw-pulling", and
> "hot potato", with anti-gaming built in to the algorithm,
> device drivers are provided as "generic universal drivers",
> then that user-space gets a usual "quotas/limits" and
> while a contrived user-space program may actually run
> a hot inner loop, otherwise the deadlock/starvation and
> other issues in concurrency are to be figured out,
> for the allocator/scheduler.

I assume tasks (processes) run without interruption until they
need an unavailable resource, at which point, they block.

But, *other* tasks are also doing so, concurrently.

As such, EVERY time a resource is released, the scheduler
(theoretically) runs.  So, a task that causes a resource to
be made available for another blocking task can be immediately
preempted by that blocked task now being "ready" to run.

The distinction is important because tasks can reside in
different cores as well as on different nodes.  So, even if a
task spins in a tight loop, not altering the availability of
any resources, it can still be preempted by the actions of some
other executing task.

[Of course, the round-robin scheduler ensures an equal priority
task is not indefinitely blocked, even if the deadline scheduler
sees no need to reschedule()]

Treating the design of the OS in a similar fashion, I can transfer
"ownership" of specific objects to whichever tasks (servers) I
consider appropriate.  Dynamically.

E.g., when physical memory is free'd, I give it to a task that
scrubs it (so the next user of said memory never sees any "data"
that may have occupied those memory locations by a previous
"user") and verifies its functionality.  When some task NEEDS
additional memory, it blocks waiting on the availability of
such memory -- which causes this "scrubber" to make available
pages that it deems as "clean and functional".

Chopping responsibilities up like this makes it easier to "get it
right" -- at the expense of some performance (each of these interactions
have to cross protection domains so the interactions aren't as
lightweight as a simple function call in a monolithic kernel).

Processors are cheap.  Memory is cheap.  Developer time and latent
bugs are costly (figure you have to spend a man-week looking into
a suspected bug.  If you're making 10,000 units, EACH such distraction
can justify an additional $1 in hardware costs, without factoring in
the externalities of cost to users, reputation, etc.)

> I.e., the usual idea of the "co-operative" lives inside
> the kernel, user-space is nominally adversarial and
> the network is nominally un-trusted.  System calls it's
> figured are implemented as of a "co-operative" implementation.

The network is not a named resource.  It is used by the OS to
exchange messages with other kernel instances running on other
nodes.  So, when a task does:

        object=>method(arguments)

it doesn't need to know if the referenced object is local or remote.
The kernels handle location independence.

Traffic is encrypted with different keys for each node.  So, discovering a
key (e.g., by attacking a specific node) only gives you access to the
traffic for that node.

This also allows for:

	object=>move(new_server)

to force the object to be managed by another server (for that particular
class of object) which will likely cause the object instance to "physically"
move to whichever node on which that server is executing.

So, I can move every object off of a particular node -- or, onto a specific
node!

[Of course, a task is also an object -- and servers are tasks -- so I can move
entire tasks (processes) similarly.]

In this way, I can bring hardware and software on/off-line on demand to adapt
to changes in needs and available resources.  E.g, if I'm running on battery
(backup) power, I can shut down individual nodes to reduce power consumption
after migrating their current responsibilities to other nodes or outright
killing them off -- after checkpointing their progress.  If I have some new
*need*, I can bring a node on-line and push tasks (objects) onto it.  So,
if a particular object server becomes overloaded, I can span a new instance
of it and migrate some of the objects that it is currently backing onto that
new instance -- the tasks referencing those objects never know that the objects
have "moved"!

Objects are capability-based.  So, you can only access objects for which you
currently *have* a capability and only to the extent permitted by said
capability.

Capabilities are un-named and managed in the kernel(s) so can't be
counterfeited.  You can *know* that a particular object exists (e.g.,
TheFrontDoor, TheGunSafe, TheBankAccount) but can't do anything
to/with it because you likely haven't been given access to it and can't
GET access to it as there isn't a central name registry that you could hack!

It seems fairly obvious that devices can no longer act as islands in the
21st century.  There's too little value to add for a single device to
be meaningful -- unless it interacts with other devices in meaningful
ways.

And, rather than the heavyweight client-server interface where things
interact in a generic, high-level manner (CORBA-ish), it seems much
more practical to let them interact in a manner that is more natural
to their designs.  Do you want to have to standardize on every such
interaction with an industry-wide "committee" arguing about how many
humps the horse should have on its back?  Or, do you want to make product
that solves problems while your competitors are trying to define a
level playing field??

> It's mostly as of a "design" while though I put it through
> the wringer as it were of some "large, competent, conscientious,
> co-operative reasoners" or a "bot panel", I can post a link
> or reference or all the text of them.

[toc] | [prev] | [next] | [standalone]

#742443

On 03/28/2026 01:56 PM, Don Y wrote:
> On 3/28/2026 6:41 AM, Ross Finlayson wrote:
>> Ah, here the idea of "co-operative scheduler" (vis-a-vis
>> "pre-emptive scheduler") has that there's a notion of the
>> model of an o.s. (scheduler, allocator) of co-operation
>> vis-a-vis "the re-routine", which is a sort of idea like
>> "co-routine", where basically everything is non-blocking
>> by design and convention, and instead of a co-routine stack
>> is a sort of memo-ized monad, then about matters of the
>> scheduling like "I cut you pick", "straw-pulling", and
>> "hot potato", with anti-gaming built in to the algorithm,
>> device drivers are provided as "generic universal drivers",
>> then that user-space gets a usual "quotas/limits" and
>> while a contrived user-space program may actually run
>> a hot inner loop, otherwise the deadlock/starvation and
>> other issues in concurrency are to be figured out,
>> for the allocator/scheduler.
>
> I assume tasks (processes) run without interruption until they
> need an unavailable resource, at which point, they block.
>
> But, *other* tasks are also doing so, concurrently.
>
> As such, EVERY time a resource is released, the scheduler
> (theoretically) runs.  So, a task that causes a resource to
> be made available for another blocking task can be immediately
> preempted by that blocked task now being "ready" to run.
>
> The distinction is important because tasks can reside in
> different cores as well as on different nodes.  So, even if a
> task spins in a tight loop, not altering the availability of
> any resources, it can still be preempted by the actions of some
> other executing task.
>
> [Of course, the round-robin scheduler ensures an equal priority
> task is not indefinitely blocked, even if the deadline scheduler
> sees no need to reschedule()]
>
> Treating the design of the OS in a similar fashion, I can transfer
> "ownership" of specific objects to whichever tasks (servers) I
> consider appropriate.  Dynamically.
>
> E.g., when physical memory is free'd, I give it to a task that
> scrubs it (so the next user of said memory never sees any "data"
> that may have occupied those memory locations by a previous
> "user") and verifies its functionality.  When some task NEEDS
> additional memory, it blocks waiting on the availability of
> such memory -- which causes this "scrubber" to make available
> pages that it deems as "clean and functional".
>
> Chopping responsibilities up like this makes it easier to "get it
> right" -- at the expense of some performance (each of these interactions
> have to cross protection domains so the interactions aren't as
> lightweight as a simple function call in a monolithic kernel).
>
> Processors are cheap.  Memory is cheap.  Developer time and latent
> bugs are costly (figure you have to spend a man-week looking into
> a suspected bug.  If you're making 10,000 units, EACH such distraction
> can justify an additional $1 in hardware costs, without factoring in
> the externalities of cost to users, reputation, etc.)
>
>> I.e., the usual idea of the "co-operative" lives inside
>> the kernel, user-space is nominally adversarial and
>> the network is nominally un-trusted.  System calls it's
>> figured are implemented as of a "co-operative" implementation.
>
> The network is not a named resource.  It is used by the OS to
> exchange messages with other kernel instances running on other
> nodes.  So, when a task does:
>
>         object=>method(arguments)
>
> it doesn't need to know if the referenced object is local or remote.
> The kernels handle location independence.
>
> Traffic is encrypted with different keys for each node.  So, discovering a
> key (e.g., by attacking a specific node) only gives you access to the
> traffic for that node.
>
> This also allows for:
>
>      object=>move(new_server)
>
> to force the object to be managed by another server (for that particular
> class of object) which will likely cause the object instance to
> "physically"
> move to whichever node on which that server is executing.
>
> So, I can move every object off of a particular node -- or, onto a specific
> node!
>
> [Of course, a task is also an object -- and servers are tasks -- so I
> can move
> entire tasks (processes) similarly.]
>
> In this way, I can bring hardware and software on/off-line on demand to
> adapt
> to changes in needs and available resources.  E.g, if I'm running on
> battery
> (backup) power, I can shut down individual nodes to reduce power
> consumption
> after migrating their current responsibilities to other nodes or outright
> killing them off -- after checkpointing their progress.  If I have some new
> *need*, I can bring a node on-line and push tasks (objects) onto it.  So,
> if a particular object server becomes overloaded, I can span a new instance
> of it and migrate some of the objects that it is currently backing onto
> that
> new instance -- the tasks referencing those objects never know that the
> objects
> have "moved"!
>
> Objects are capability-based.  So, you can only access objects for which
> you
> currently *have* a capability and only to the extent permitted by said
> capability.
>
> Capabilities are un-named and managed in the kernel(s) so can't be
> counterfeited.  You can *know* that a particular object exists (e.g.,
> TheFrontDoor, TheGunSafe, TheBankAccount) but can't do anything
> to/with it because you likely haven't been given access to it and can't
> GET access to it as there isn't a central name registry that you could
> hack!
>
> It seems fairly obvious that devices can no longer act as islands in the
> 21st century.  There's too little value to add for a single device to
> be meaningful -- unless it interacts with other devices in meaningful
> ways.
>
> And, rather than the heavyweight client-server interface where things
> interact in a generic, high-level manner (CORBA-ish), it seems much
> more practical to let them interact in a manner that is more natural
> to their designs.  Do you want to have to standardize on every such
> interaction with an industry-wide "committee" arguing about how many
> humps the horse should have on its back?  Or, do you want to make product
> that solves problems while your competitors are trying to define a
> level playing field??
>
>> It's mostly as of a "design" while though I put it through
>> the wringer as it were of some "large, competent, conscientious,
>> co-operative reasoners" or a "bot panel", I can post a link
>> or reference or all the text of them.
>
>

That seems to speak to "proximity" and "affinity", with regards
to "coherency", and "mobility". To "move" state, about state & scope
or the contents of (some of) memory and registers, of a process or task,
here is described as "re-seating" which is also the usual enough
idea in programming like C and C++.

Perhaps the most usual example is pre-emptive multithreading itself,
about basically the state as a stack, and "process control block"
and "thread control block" usually enough, about context-switching.

In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
the idea of the "re-routine" as a model of asychronous concurrency,
is a little different than the usual idea of a co-routine, which
is usually enough a fork in the process model, then about signals
as IPC with PID and PPID, vis-a-vis, fibers and threads or events
and task queues, basically the re-routine never "blocks" and has
no "yield" nor "async" keywords in the source text, instead any
call to a re-routine implicitly yields, and then the re-routine
is run again later, the re-run, where as the re-routine is filled in,
then then the re-routine adds a penalty of basically n^2 in time
to be completely non-blocking and where asynchrony is modeled in
the language as the normal procedural flow-of-control.

Then, as that's only in the kernel itself, that n^2 might seem a
huge penalty, yet, it's actually quite under that, since as the
re-routine its data (in a stack) is filled in, then most of its
routine is cache hits, the "memoized" calls to the re-routine.


About the allocator, then this design concept basically is for
making use of virtual memory, to be able to "re-seat" the memory
of a process without changing a process' view of the memory.
This can help avoid both syscalls and memory fragmentation,
since memory paging basically is performed by the user-space
process in its time instead of by the kernel. This has the
usual guarantees of process memory that it's to be visible only
to the process itself unless explicitly shared, that then being
treated as a usual sort of shared resource in the distributed sense.


The syscalls by a process essentially yield (the process yields
to the scheduler), about ideas like round-robin and fairness
and anti-starvation and incremental-progress in the scheduler,
while it's so that until a process gets any other signal and
only touches its own memory that's non-yielding, then about
the machinery of pre-emptive multithreading or context-switch
and as with regards to hyper-threading or the interleaved contexts
on the double-pipeline CPUs, the idea being that context-switching
is along the lines of basically a periodic signal interrupt.


Notions of "Orange Book" and "mandatory access control" then
are considered "more than good ideas" with regards to the allocator
and scheduler of resources in computation.

[toc] | [prev] | [next] | [standalone]

#742460

On 3/29/2026 5:53 AM, Ross Finlayson wrote:
> That seems to speak to "proximity" and "affinity", with regards
> to "coherency", and "mobility". To "move" state, about state & scope
> or the contents of (some of) memory and registers, of a process or task,
> here is described as "re-seating" which is also the usual enough
> idea in programming like C and C++.

My goal is NOT to disrupt the "programmer's model" for "average
developers".  They should truly be able to think that they are running
on a uniprocessor but without any guarantees as to throughput
(to accommodate sharing the physical processor, communication
overhead, etc.).

They shouldn't need to know where "they" are executing or that the
resources on which they rely may not be local.

"Advanced developers" attend to the dynamic reconfiguration of
the system (at runtime).  So, THOSE developers build applications
that are given the ability ("capability") to relocate resources,
kill off tasks, spawn new ones, etc.  Because they, presumably, have
a more detailed understanding of the "System" beyond the scope of
some particular application/task within it.

> Perhaps the most usual example is pre-emptive multithreading itself,
> about basically the state as a stack, and "process control block"
> and "thread control block" usually enough, about context-switching.

I support a heterogeneous environment; an object can be migrated
to a different processor *family* at any time (while executing).
You shouldn't care as long as the interface (methods) to the
object remain available (for the capabilities you have been
granted) along with the current state of the object.

Similarly, the algorithms used to implement those methods (as
well as internal data members) can change dynamically -- as long
as the interface functionality remains immutable.

For example, I create namespaces -- (name, capability) dictionaries -- for
each process.  If you only need a few registered names (stdin, stdout, stderr),
the code that implements that is entirely different than the implementation
that tries to manage hundreds of named entries.

As it should be.  (because "you" are "billed" for the resources that you
use, you'd not want to bear the cost of an implementation that did more
than you needed -- just like you wouldn't develop a standalone device
with more complexity/cost than necessary!)

If names are insignificant (e.g., akin to file descriptors), then an
implementation might use a single "char" to represent a name, giving
you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
(do you really *need* names like "Object 1", "Object 2", etc.?)

> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
> the idea of the "re-routine" as a model of asychronous concurrency,
> is a little different than the usual idea of a co-routine, which
> is usually enough a fork in the process model, then about signals
> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
> and task queues, basically the re-routine never "blocks" and has
> no "yield" nor "async" keywords in the source text, instead any
> call to a re-routine implicitly yields, and then the re-routine
> is run again later, the re-run, where as the re-routine is filled in,
> then then the re-routine adds a penalty of basically n^2 in time
> to be completely non-blocking and where asynchrony is modeled in
> the language as the normal procedural flow-of-control.

"Yield" is just a hint to the scheduler.  If you have a preemptive
implementation where "time" can be a preemption criteria, then a
task need never "suggest" a good place to relinquish the processor.

OTOH, if you can only preempt when the task invokes an OS primitive,
then you have to be wary of a developer spinning without ever giving
the system a chance to "interrupt".

> Then, as that's only in the kernel itself, that n^2 might seem a
> huge penalty, yet, it's actually quite under that, since as the
> re-routine its data (in a stack) is filled in, then most of its
> routine is cache hits, the "memoized" calls to the re-routine.
> 
> About the allocator, then this design concept basically is for
> making use of virtual memory, to be able to "re-seat" the memory
> of a process without changing a process' view of the memory.

Of course.  But, with VMM, you can do so much more:
- CoW semantics
- DSM
- remapping "defective" memory
- releasing memory that will NEVER be revisited
- universal call by value (for large arguments)
etc.   None of these things need impact the developer.

> This can help avoid both syscalls and memory fragmentation,
> since memory paging basically is performed by the user-space
> process in its time instead of by the kernel. This has the
> usual guarantees of process memory that it's to be visible only
> to the process itself unless explicitly shared, that then being
> treated as a usual sort of shared resource in the distributed sense.
> 
> The syscalls by a process essentially yield (the process yields
> to the scheduler), about ideas like round-robin and fairness
> and anti-starvation and incremental-progress in the scheduler,
> while it's so that until a process gets any other signal and
> only touches its own memory that's non-yielding, then about
> the machinery of pre-emptive multithreading or context-switch
> and as with regards to hyper-threading or the interleaved contexts
> on the double-pipeline CPUs, the idea being that context-switching
> is along the lines of basically a periodic signal interrupt.

But you have to guard against "non-cooperative" (and even HOSTILE!)
actors who may wish to compromise performance by monopolizing resources
(of which the CPU is but one).

Using resource ledgers lets you constrain an application (process)
to a subset of the available resources.  Putting runtime constraints
on memory, time, etc. lets you remove a "bad actor" from the set
of processes eligible to run.  A persistent store lets you remember
this decision so you don't "readmit" the process at some future date!

> Notions of "Orange Book" and "mandatory access control" then
> are considered "more than good ideas" with regards to the allocator
> and scheduler of resources in computation.

Capabilities implicitly limit the actions that can be performed (i.e.,
methods that can be invoked) on an object.  E.g., I can let you
LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
once, and never again!

How you refine your "permissions" is something that belongs in the
objects themselves -- not layered onto a "filesystem" as an afterthought.

[toc] | [prev] | [next] | [standalone]

#742461

On Sun, 29 Mar 2026 12:39:33 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>> That seems to speak to "proximity" and "affinity", with regards
>> to "coherency", and "mobility". To "move" state, about state & scope
>> or the contents of (some of) memory and registers, of a process or task,
>> here is described as "re-seating" which is also the usual enough
>> idea in programming like C and C++.
>
>My goal is NOT to disrupt the "programmer's model" for "average
>developers".  They should truly be able to think that they are running
>on a uniprocessor but without any guarantees as to throughput
>(to accommodate sharing the physical processor, communication
>overhead, etc.).
>
>They shouldn't need to know where "they" are executing or that the
>resources on which they rely may not be local.
>
>"Advanced developers" attend to the dynamic reconfiguration of
>the system (at runtime).  So, THOSE developers build applications
>that are given the ability ("capability") to relocate resources,
>kill off tasks, spawn new ones, etc.  Because they, presumably, have
>a more detailed understanding of the "System" beyond the scope of
>some particular application/task within it.
>
>> Perhaps the most usual example is pre-emptive multithreading itself,
>> about basically the state as a stack, and "process control block"
>> and "thread control block" usually enough, about context-switching.
>
>I support a heterogeneous environment; an object can be migrated
>to a different processor *family* at any time (while executing).
>You shouldn't care as long as the interface (methods) to the
>object remain available (for the capabilities you have been
>granted) along with the current state of the object.
>
>Similarly, the algorithms used to implement those methods (as
>well as internal data members) can change dynamically -- as long
>as the interface functionality remains immutable.
>
>For example, I create namespaces -- (name, capability) dictionaries -- for
>each process.  If you only need a few registered names (stdin, stdout, stderr),
>the code that implements that is entirely different than the implementation
>that tries to manage hundreds of named entries.
>
>As it should be.  (because "you" are "billed" for the resources that you
>use, you'd not want to bear the cost of an implementation that did more
>than you needed -- just like you wouldn't develop a standalone device
>with more complexity/cost than necessary!)
>
>If names are insignificant (e.g., akin to file descriptors), then an
>implementation might use a single "char" to represent a name, giving
>you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
>Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>(do you really *need* names like "Object 1", "Object 2", etc.?)
>
>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>> the idea of the "re-routine" as a model of asychronous concurrency,
>> is a little different than the usual idea of a co-routine, which
>> is usually enough a fork in the process model, then about signals
>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>> and task queues, basically the re-routine never "blocks" and has
>> no "yield" nor "async" keywords in the source text, instead any
>> call to a re-routine implicitly yields, and then the re-routine
>> is run again later, the re-run, where as the re-routine is filled in,
>> then then the re-routine adds a penalty of basically n^2 in time
>> to be completely non-blocking and where asynchrony is modeled in
>> the language as the normal procedural flow-of-control.
>
>"Yield" is just a hint to the scheduler.  If you have a preemptive
>implementation where "time" can be a preemption criteria, then a
>task need never "suggest" a good place to relinquish the processor.
>
>OTOH, if you can only preempt when the task invokes an OS primitive,
>then you have to be wary of a developer spinning without ever giving
>the system a chance to "interrupt".
>
>> Then, as that's only in the kernel itself, that n^2 might seem a
>> huge penalty, yet, it's actually quite under that, since as the
>> re-routine its data (in a stack) is filled in, then most of its
>> routine is cache hits, the "memoized" calls to the re-routine.
>> 
>> About the allocator, then this design concept basically is for
>> making use of virtual memory, to be able to "re-seat" the memory
>> of a process without changing a process' view of the memory.
>
>Of course.  But, with VMM, you can do so much more:
>- CoW semantics
>- DSM
>- remapping "defective" memory
>- releasing memory that will NEVER be revisited
>- universal call by value (for large arguments)
>etc.   None of these things need impact the developer.
>
>> This can help avoid both syscalls and memory fragmentation,
>> since memory paging basically is performed by the user-space
>> process in its time instead of by the kernel. This has the
>> usual guarantees of process memory that it's to be visible only
>> to the process itself unless explicitly shared, that then being
>> treated as a usual sort of shared resource in the distributed sense.
>> 
>> The syscalls by a process essentially yield (the process yields
>> to the scheduler), about ideas like round-robin and fairness
>> and anti-starvation and incremental-progress in the scheduler,
>> while it's so that until a process gets any other signal and
>> only touches its own memory that's non-yielding, then about
>> the machinery of pre-emptive multithreading or context-switch
>> and as with regards to hyper-threading or the interleaved contexts
>> on the double-pipeline CPUs, the idea being that context-switching
>> is along the lines of basically a periodic signal interrupt.
>
>But you have to guard against "non-cooperative" (and even HOSTILE!)
>actors who may wish to compromise performance by monopolizing resources
>(of which the CPU is but one).
>
>Using resource ledgers lets you constrain an application (process)
>to a subset of the available resources.  Putting runtime constraints
>on memory, time, etc. lets you remove a "bad actor" from the set
>of processes eligible to run.  A persistent store lets you remember
>this decision so you don't "readmit" the process at some future date!
>
>> Notions of "Orange Book" and "mandatory access control" then
>> are considered "more than good ideas" with regards to the allocator
>> and scheduler of resources in computation.
>
>Capabilities implicitly limit the actions that can be performed (i.e.,
>methods that can be invoked) on an object.  E.g., I can let you
>LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>once, and never again!
>
>How you refine your "permissions" is something that belongs in the
>objects themselves -- not layered onto a "filesystem" as an afterthought.

Yikes. All that makes me glad to be a simple circuit designer.


John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

[toc] | [prev] | [next] | [standalone]

#742464

On 03/29/2026 12:39 PM, Don Y wrote:
> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>> That seems to speak to "proximity" and "affinity", with regards
>> to "coherency", and "mobility". To "move" state, about state & scope
>> or the contents of (some of) memory and registers, of a process or task,
>> here is described as "re-seating" which is also the usual enough
>> idea in programming like C and C++.
>
> My goal is NOT to disrupt the "programmer's model" for "average
> developers".  They should truly be able to think that they are running
> on a uniprocessor but without any guarantees as to throughput
> (to accommodate sharing the physical processor, communication
> overhead, etc.).
>
> They shouldn't need to know where "they" are executing or that the
> resources on which they rely may not be local.
>
> "Advanced developers" attend to the dynamic reconfiguration of
> the system (at runtime).  So, THOSE developers build applications
> that are given the ability ("capability") to relocate resources,
> kill off tasks, spawn new ones, etc.  Because they, presumably, have
> a more detailed understanding of the "System" beyond the scope of
> some particular application/task within it.
>
>> Perhaps the most usual example is pre-emptive multithreading itself,
>> about basically the state as a stack, and "process control block"
>> and "thread control block" usually enough, about context-switching.
>
> I support a heterogeneous environment; an object can be migrated
> to a different processor *family* at any time (while executing).
> You shouldn't care as long as the interface (methods) to the
> object remain available (for the capabilities you have been
> granted) along with the current state of the object.
>
> Similarly, the algorithms used to implement those methods (as
> well as internal data members) can change dynamically -- as long
> as the interface functionality remains immutable.
>
> For example, I create namespaces -- (name, capability) dictionaries -- for
> each process.  If you only need a few registered names (stdin, stdout,
> stderr),
> the code that implements that is entirely different than the implementation
> that tries to manage hundreds of named entries.
>
> As it should be.  (because "you" are "billed" for the resources that you
> use, you'd not want to bear the cost of an implementation that did more
> than you needed -- just like you wouldn't develop a standalone device
> with more complexity/cost than necessary!)
>
> If names are insignificant (e.g., akin to file descriptors), then an
> implementation might use a single "char" to represent a name, giving
> you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
> (do you really *need* names like "Object 1", "Object 2", etc.?)
>
>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>> the idea of the "re-routine" as a model of asychronous concurrency,
>> is a little different than the usual idea of a co-routine, which
>> is usually enough a fork in the process model, then about signals
>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>> and task queues, basically the re-routine never "blocks" and has
>> no "yield" nor "async" keywords in the source text, instead any
>> call to a re-routine implicitly yields, and then the re-routine
>> is run again later, the re-run, where as the re-routine is filled in,
>> then then the re-routine adds a penalty of basically n^2 in time
>> to be completely non-blocking and where asynchrony is modeled in
>> the language as the normal procedural flow-of-control.
>
> "Yield" is just a hint to the scheduler.  If you have a preemptive
> implementation where "time" can be a preemption criteria, then a
> task need never "suggest" a good place to relinquish the processor.
>
> OTOH, if you can only preempt when the task invokes an OS primitive,
> then you have to be wary of a developer spinning without ever giving
> the system a chance to "interrupt".
>
>> Then, as that's only in the kernel itself, that n^2 might seem a
>> huge penalty, yet, it's actually quite under that, since as the
>> re-routine its data (in a stack) is filled in, then most of its
>> routine is cache hits, the "memoized" calls to the re-routine.
>>
>> About the allocator, then this design concept basically is for
>> making use of virtual memory, to be able to "re-seat" the memory
>> of a process without changing a process' view of the memory.
>
> Of course.  But, with VMM, you can do so much more:
> - CoW semantics
> - DSM
> - remapping "defective" memory
> - releasing memory that will NEVER be revisited
> - universal call by value (for large arguments)
> etc.   None of these things need impact the developer.
>
>> This can help avoid both syscalls and memory fragmentation,
>> since memory paging basically is performed by the user-space
>> process in its time instead of by the kernel. This has the
>> usual guarantees of process memory that it's to be visible only
>> to the process itself unless explicitly shared, that then being
>> treated as a usual sort of shared resource in the distributed sense.
>>
>> The syscalls by a process essentially yield (the process yields
>> to the scheduler), about ideas like round-robin and fairness
>> and anti-starvation and incremental-progress in the scheduler,
>> while it's so that until a process gets any other signal and
>> only touches its own memory that's non-yielding, then about
>> the machinery of pre-emptive multithreading or context-switch
>> and as with regards to hyper-threading or the interleaved contexts
>> on the double-pipeline CPUs, the idea being that context-switching
>> is along the lines of basically a periodic signal interrupt.
>
> But you have to guard against "non-cooperative" (and even HOSTILE!)
> actors who may wish to compromise performance by monopolizing resources
> (of which the CPU is but one).
>
> Using resource ledgers lets you constrain an application (process)
> to a subset of the available resources.  Putting runtime constraints
> on memory, time, etc. lets you remove a "bad actor" from the set
> of processes eligible to run.  A persistent store lets you remember
> this decision so you don't "readmit" the process at some future date!
>
>> Notions of "Orange Book" and "mandatory access control" then
>> are considered "more than good ideas" with regards to the allocator
>> and scheduler of resources in computation.
>
> Capabilities implicitly limit the actions that can be performed (i.e.,
> methods that can be invoked) on an object.  E.g., I can let you
> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
> once, and never again!
>
> How you refine your "permissions" is something that belongs in the
> objects themselves -- not layered onto a "filesystem" as an afterthought.
>


Hey, thanks for writing. Since all we know about each other
are these brief exchanges, filling in some detail helps a lot
to understand, or rather, get an idea, of an estimate of the
depth of the comprehension of the whole machine stack.

The idea of a kernel or operating system (executive, scheduler,
..., interactive "operating system") for "commodity" architectures
these days is that it's pretty ubiquitous the various chips'
architectures, then that PCIe is on everything PC, then about
usually enough USB, then about the NIC and USB root, those are
pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
and the SMI or as about DeviceTree, ..., it's ubiquitous,
after "economy of scale" a simple enough "economy of ubiquity".

So, the chips are almost all 64-bit their native word width, though
agreeably sometimes it's 128, and they have various vector or SIMD
instructions, then as with regards to fitting two operands in a word,
the SWAR approach, about vectorizing the scalars, and word and
double-word and word and half-word.

Then, here mostly the consideration is the "head-less" or "HID-less",
there's no human interface device involved in server runtime images
for things like running services or usually enough "boxes" or "nodes".


Then, for compiling existing sources, it seems the easiest way to
do that is to implement profiles of POSIX, or posix base and pthreads.
That then of course is much the traditional UNIX account of where
"everything is a file", though, the operating system itself doesn't
need to be implemented that way, just surface the usual objects as
they are as primitives, and mostly as having file handles.
(If the sources compile and run the same behavior some won't know/care.)

Then, objects, according to "naming and directory interface" usually
enough, Orange Book for example defines granular access controls,
so, including all things like files.


About quota and limits and the like, and about the perceived value
of pre-emptive scheduling to avoid "hogging", or thrashing, here
is an account of basically unmaskable uncatchable interrupts that
have as a signal handler the operating system code on the core
that results making the task yield, then necessarily enough using
the usually context-switch machinery to pause it and restart it.
Most code eventually touches system calls, and if there's a spare
core it might actually be the idea to let the compute-intensive
routine employ the entire core.

The many-core architectures of these days, even fifteen or twenty
years ago with "AMD Bulldozer and 8 cores" and the like, these
days usual PC or server chips have scores of cores, ..., often
for example with the idea of running a giant hypervisor then
as many virts, ..., like a Kubernetes cluster for example, ...,
or simply a ton of virts, ..., these days a single board is
as a model of a distributed system internal to itself.


The idea for allocation and sharing that "fairness is a matter
of mechanism, not policy", is for the usual ideas of "thoughput"
and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
about I/O and queues, and limits.


"Interrupts" are the events, "coherent cache lines" the units of
serialization of memory, DMA is the bulk transfer medium in protocol,
a byte is the smallest addressable memory unit, these are mostly
the ordering guarantees, all else "undefined".

Proximity, affinity, coherency, mobility, ....

[toc] | [prev] | [next] | [standalone]

#742466

On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:

>On 03/29/2026 12:39 PM, Don Y wrote:
>> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>>> That seems to speak to "proximity" and "affinity", with regards
>>> to "coherency", and "mobility". To "move" state, about state & scope
>>> or the contents of (some of) memory and registers, of a process or task,
>>> here is described as "re-seating" which is also the usual enough
>>> idea in programming like C and C++.
>>
>> My goal is NOT to disrupt the "programmer's model" for "average
>> developers".  They should truly be able to think that they are running
>> on a uniprocessor but without any guarantees as to throughput
>> (to accommodate sharing the physical processor, communication
>> overhead, etc.).
>>
>> They shouldn't need to know where "they" are executing or that the
>> resources on which they rely may not be local.
>>
>> "Advanced developers" attend to the dynamic reconfiguration of
>> the system (at runtime).  So, THOSE developers build applications
>> that are given the ability ("capability") to relocate resources,
>> kill off tasks, spawn new ones, etc.  Because they, presumably, have
>> a more detailed understanding of the "System" beyond the scope of
>> some particular application/task within it.
>>
>>> Perhaps the most usual example is pre-emptive multithreading itself,
>>> about basically the state as a stack, and "process control block"
>>> and "thread control block" usually enough, about context-switching.
>>
>> I support a heterogeneous environment; an object can be migrated
>> to a different processor *family* at any time (while executing).
>> You shouldn't care as long as the interface (methods) to the
>> object remain available (for the capabilities you have been
>> granted) along with the current state of the object.
>>
>> Similarly, the algorithms used to implement those methods (as
>> well as internal data members) can change dynamically -- as long
>> as the interface functionality remains immutable.
>>
>> For example, I create namespaces -- (name, capability) dictionaries -- for
>> each process.  If you only need a few registered names (stdin, stdout,
>> stderr),
>> the code that implements that is entirely different than the implementation
>> that tries to manage hundreds of named entries.
>>
>> As it should be.  (because "you" are "billed" for the resources that you
>> use, you'd not want to bear the cost of an implementation that did more
>> than you needed -- just like you wouldn't develop a standalone device
>> with more complexity/cost than necessary!)
>>
>> If names are insignificant (e.g., akin to file descriptors), then an
>> implementation might use a single "char" to represent a name, giving
>> you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
>> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>> (do you really *need* names like "Object 1", "Object 2", etc.?)
>>
>>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>>> the idea of the "re-routine" as a model of asychronous concurrency,
>>> is a little different than the usual idea of a co-routine, which
>>> is usually enough a fork in the process model, then about signals
>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>>> and task queues, basically the re-routine never "blocks" and has
>>> no "yield" nor "async" keywords in the source text, instead any
>>> call to a re-routine implicitly yields, and then the re-routine
>>> is run again later, the re-run, where as the re-routine is filled in,
>>> then then the re-routine adds a penalty of basically n^2 in time
>>> to be completely non-blocking and where asynchrony is modeled in
>>> the language as the normal procedural flow-of-control.
>>
>> "Yield" is just a hint to the scheduler.  If you have a preemptive
>> implementation where "time" can be a preemption criteria, then a
>> task need never "suggest" a good place to relinquish the processor.
>>
>> OTOH, if you can only preempt when the task invokes an OS primitive,
>> then you have to be wary of a developer spinning without ever giving
>> the system a chance to "interrupt".
>>
>>> Then, as that's only in the kernel itself, that n^2 might seem a
>>> huge penalty, yet, it's actually quite under that, since as the
>>> re-routine its data (in a stack) is filled in, then most of its
>>> routine is cache hits, the "memoized" calls to the re-routine.
>>>
>>> About the allocator, then this design concept basically is for
>>> making use of virtual memory, to be able to "re-seat" the memory
>>> of a process without changing a process' view of the memory.
>>
>> Of course.  But, with VMM, you can do so much more:
>> - CoW semantics
>> - DSM
>> - remapping "defective" memory
>> - releasing memory that will NEVER be revisited
>> - universal call by value (for large arguments)
>> etc.   None of these things need impact the developer.
>>
>>> This can help avoid both syscalls and memory fragmentation,
>>> since memory paging basically is performed by the user-space
>>> process in its time instead of by the kernel. This has the
>>> usual guarantees of process memory that it's to be visible only
>>> to the process itself unless explicitly shared, that then being
>>> treated as a usual sort of shared resource in the distributed sense.
>>>
>>> The syscalls by a process essentially yield (the process yields
>>> to the scheduler), about ideas like round-robin and fairness
>>> and anti-starvation and incremental-progress in the scheduler,
>>> while it's so that until a process gets any other signal and
>>> only touches its own memory that's non-yielding, then about
>>> the machinery of pre-emptive multithreading or context-switch
>>> and as with regards to hyper-threading or the interleaved contexts
>>> on the double-pipeline CPUs, the idea being that context-switching
>>> is along the lines of basically a periodic signal interrupt.
>>
>> But you have to guard against "non-cooperative" (and even HOSTILE!)
>> actors who may wish to compromise performance by monopolizing resources
>> (of which the CPU is but one).
>>
>> Using resource ledgers lets you constrain an application (process)
>> to a subset of the available resources.  Putting runtime constraints
>> on memory, time, etc. lets you remove a "bad actor" from the set
>> of processes eligible to run.  A persistent store lets you remember
>> this decision so you don't "readmit" the process at some future date!
>>
>>> Notions of "Orange Book" and "mandatory access control" then
>>> are considered "more than good ideas" with regards to the allocator
>>> and scheduler of resources in computation.
>>
>> Capabilities implicitly limit the actions that can be performed (i.e.,
>> methods that can be invoked) on an object.  E.g., I can let you
>> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>> once, and never again!
>>
>> How you refine your "permissions" is something that belongs in the
>> objects themselves -- not layered onto a "filesystem" as an afterthought.
>>
>
>
>Hey, thanks for writing. Since all we know about each other
>are these brief exchanges, filling in some detail helps a lot
>to understand, or rather, get an idea, of an estimate of the
>depth of the comprehension of the whole machine stack.
>
>The idea of a kernel or operating system (executive, scheduler,
>..., interactive "operating system") for "commodity" architectures
>these days is that it's pretty ubiquitous the various chips'
>architectures, then that PCIe is on everything PC, then about
>usually enough USB, then about the NIC and USB root, those are
>pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
>and the SMI or as about DeviceTree, ..., it's ubiquitous,
>after "economy of scale" a simple enough "economy of ubiquity".
>
>So, the chips are almost all 64-bit their native word width, though
>agreeably sometimes it's 128, and they have various vector or SIMD
>instructions, then as with regards to fitting two operands in a word,
>the SWAR approach, about vectorizing the scalars, and word and
>double-word and word and half-word.
>
>Then, here mostly the consideration is the "head-less" or "HID-less",
>there's no human interface device involved in server runtime images
>for things like running services or usually enough "boxes" or "nodes".
>
>
>Then, for compiling existing sources, it seems the easiest way to
>do that is to implement profiles of POSIX, or posix base and pthreads.
>That then of course is much the traditional UNIX account of where
>"everything is a file", though, the operating system itself doesn't
>need to be implemented that way, just surface the usual objects as
>they are as primitives, and mostly as having file handles.
>(If the sources compile and run the same behavior some won't know/care.)
>
>Then, objects, according to "naming and directory interface" usually
>enough, Orange Book for example defines granular access controls,
>so, including all things like files.
>
>
>About quota and limits and the like, and about the perceived value
>of pre-emptive scheduling to avoid "hogging", or thrashing, here
>is an account of basically unmaskable uncatchable interrupts that
>have as a signal handler the operating system code on the core
>that results making the task yield, then necessarily enough using
>the usually context-switch machinery to pause it and restart it.
>Most code eventually touches system calls, and if there's a spare
>core it might actually be the idea to let the compute-intensive
>routine employ the entire core.
>
>The many-core architectures of these days, even fifteen or twenty
>years ago with "AMD Bulldozer and 8 cores" and the like, these
>days usual PC or server chips have scores of cores, ..., often
>for example with the idea of running a giant hypervisor then
>as many virts, ..., like a Kubernetes cluster for example, ...,
>or simply a ton of virts, ..., these days a single board is
>as a model of a distributed system internal to itself.
>
>
>The idea for allocation and sharing that "fairness is a matter
>of mechanism, not policy", is for the usual ideas of "thoughput"
>and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
>about I/O and queues, and limits.
>
>
>"Interrupts" are the events, "coherent cache lines" the units of
>serialization of memory, DMA is the bulk transfer medium in protocol,
>a byte is the smallest addressable memory unit, these are mostly
>the ordering guarantees, all else "undefined".
>
>Proximity, affinity, coherency, mobility, ....
>

We build electronics. Our new PoE instrument line uses an RP2040
dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any
quantity.

We call the two CPUs (and the two ends of the box) Alice and Bob.

Alice does the ethernet and usb i/o, command parsing, calibrations,
all that slow floating-point management. Bob does the realtime i/o,
fixed-point, directly or through an FPGA.

All programmed in bare-metal c with no OS. Abstraction=0.

Seems to work.


John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

[toc] | [prev] | [next] | [standalone]

#742470

On 03/29/2026 03:24 PM, john larkin wrote:
> On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
> <ross.a.finlayson@gmail.com> wrote:
>
>> On 03/29/2026 12:39 PM, Don Y wrote:
>>> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>>>> That seems to speak to "proximity" and "affinity", with regards
>>>> to "coherency", and "mobility". To "move" state, about state & scope
>>>> or the contents of (some of) memory and registers, of a process or task,
>>>> here is described as "re-seating" which is also the usual enough
>>>> idea in programming like C and C++.
>>>
>>> My goal is NOT to disrupt the "programmer's model" for "average
>>> developers".  They should truly be able to think that they are running
>>> on a uniprocessor but without any guarantees as to throughput
>>> (to accommodate sharing the physical processor, communication
>>> overhead, etc.).
>>>
>>> They shouldn't need to know where "they" are executing or that the
>>> resources on which they rely may not be local.
>>>
>>> "Advanced developers" attend to the dynamic reconfiguration of
>>> the system (at runtime).  So, THOSE developers build applications
>>> that are given the ability ("capability") to relocate resources,
>>> kill off tasks, spawn new ones, etc.  Because they, presumably, have
>>> a more detailed understanding of the "System" beyond the scope of
>>> some particular application/task within it.
>>>
>>>> Perhaps the most usual example is pre-emptive multithreading itself,
>>>> about basically the state as a stack, and "process control block"
>>>> and "thread control block" usually enough, about context-switching.
>>>
>>> I support a heterogeneous environment; an object can be migrated
>>> to a different processor *family* at any time (while executing).
>>> You shouldn't care as long as the interface (methods) to the
>>> object remain available (for the capabilities you have been
>>> granted) along with the current state of the object.
>>>
>>> Similarly, the algorithms used to implement those methods (as
>>> well as internal data members) can change dynamically -- as long
>>> as the interface functionality remains immutable.
>>>
>>> For example, I create namespaces -- (name, capability) dictionaries -- for
>>> each process.  If you only need a few registered names (stdin, stdout,
>>> stderr),
>>> the code that implements that is entirely different than the implementation
>>> that tries to manage hundreds of named entries.
>>>
>>> As it should be.  (because "you" are "billed" for the resources that you
>>> use, you'd not want to bear the cost of an implementation that did more
>>> than you needed -- just like you wouldn't develop a standalone device
>>> with more complexity/cost than necessary!)
>>>
>>> If names are insignificant (e.g., akin to file descriptors), then an
>>> implementation might use a single "char" to represent a name, giving
>>> you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
>>> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>>> (do you really *need* names like "Object 1", "Object 2", etc.?)
>>>
>>>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>>>> the idea of the "re-routine" as a model of asychronous concurrency,
>>>> is a little different than the usual idea of a co-routine, which
>>>> is usually enough a fork in the process model, then about signals
>>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>>>> and task queues, basically the re-routine never "blocks" and has
>>>> no "yield" nor "async" keywords in the source text, instead any
>>>> call to a re-routine implicitly yields, and then the re-routine
>>>> is run again later, the re-run, where as the re-routine is filled in,
>>>> then then the re-routine adds a penalty of basically n^2 in time
>>>> to be completely non-blocking and where asynchrony is modeled in
>>>> the language as the normal procedural flow-of-control.
>>>
>>> "Yield" is just a hint to the scheduler.  If you have a preemptive
>>> implementation where "time" can be a preemption criteria, then a
>>> task need never "suggest" a good place to relinquish the processor.
>>>
>>> OTOH, if you can only preempt when the task invokes an OS primitive,
>>> then you have to be wary of a developer spinning without ever giving
>>> the system a chance to "interrupt".
>>>
>>>> Then, as that's only in the kernel itself, that n^2 might seem a
>>>> huge penalty, yet, it's actually quite under that, since as the
>>>> re-routine its data (in a stack) is filled in, then most of its
>>>> routine is cache hits, the "memoized" calls to the re-routine.
>>>>
>>>> About the allocator, then this design concept basically is for
>>>> making use of virtual memory, to be able to "re-seat" the memory
>>>> of a process without changing a process' view of the memory.
>>>
>>> Of course.  But, with VMM, you can do so much more:
>>> - CoW semantics
>>> - DSM
>>> - remapping "defective" memory
>>> - releasing memory that will NEVER be revisited
>>> - universal call by value (for large arguments)
>>> etc.   None of these things need impact the developer.
>>>
>>>> This can help avoid both syscalls and memory fragmentation,
>>>> since memory paging basically is performed by the user-space
>>>> process in its time instead of by the kernel. This has the
>>>> usual guarantees of process memory that it's to be visible only
>>>> to the process itself unless explicitly shared, that then being
>>>> treated as a usual sort of shared resource in the distributed sense.
>>>>
>>>> The syscalls by a process essentially yield (the process yields
>>>> to the scheduler), about ideas like round-robin and fairness
>>>> and anti-starvation and incremental-progress in the scheduler,
>>>> while it's so that until a process gets any other signal and
>>>> only touches its own memory that's non-yielding, then about
>>>> the machinery of pre-emptive multithreading or context-switch
>>>> and as with regards to hyper-threading or the interleaved contexts
>>>> on the double-pipeline CPUs, the idea being that context-switching
>>>> is along the lines of basically a periodic signal interrupt.
>>>
>>> But you have to guard against "non-cooperative" (and even HOSTILE!)
>>> actors who may wish to compromise performance by monopolizing resources
>>> (of which the CPU is but one).
>>>
>>> Using resource ledgers lets you constrain an application (process)
>>> to a subset of the available resources.  Putting runtime constraints
>>> on memory, time, etc. lets you remove a "bad actor" from the set
>>> of processes eligible to run.  A persistent store lets you remember
>>> this decision so you don't "readmit" the process at some future date!
>>>
>>>> Notions of "Orange Book" and "mandatory access control" then
>>>> are considered "more than good ideas" with regards to the allocator
>>>> and scheduler of resources in computation.
>>>
>>> Capabilities implicitly limit the actions that can be performed (i.e.,
>>> methods that can be invoked) on an object.  E.g., I can let you
>>> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>>> once, and never again!
>>>
>>> How you refine your "permissions" is something that belongs in the
>>> objects themselves -- not layered onto a "filesystem" as an afterthought.
>>>
>>
>>
>> Hey, thanks for writing. Since all we know about each other
>> are these brief exchanges, filling in some detail helps a lot
>> to understand, or rather, get an idea, of an estimate of the
>> depth of the comprehension of the whole machine stack.
>>
>> The idea of a kernel or operating system (executive, scheduler,
>> ..., interactive "operating system") for "commodity" architectures
>> these days is that it's pretty ubiquitous the various chips'
>> architectures, then that PCIe is on everything PC, then about
>> usually enough USB, then about the NIC and USB root, those are
>> pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
>> and the SMI or as about DeviceTree, ..., it's ubiquitous,
>> after "economy of scale" a simple enough "economy of ubiquity".
>>
>> So, the chips are almost all 64-bit their native word width, though
>> agreeably sometimes it's 128, and they have various vector or SIMD
>> instructions, then as with regards to fitting two operands in a word,
>> the SWAR approach, about vectorizing the scalars, and word and
>> double-word and word and half-word.
>>
>> Then, here mostly the consideration is the "head-less" or "HID-less",
>> there's no human interface device involved in server runtime images
>> for things like running services or usually enough "boxes" or "nodes".
>>
>>
>> Then, for compiling existing sources, it seems the easiest way to
>> do that is to implement profiles of POSIX, or posix base and pthreads.
>> That then of course is much the traditional UNIX account of where
>> "everything is a file", though, the operating system itself doesn't
>> need to be implemented that way, just surface the usual objects as
>> they are as primitives, and mostly as having file handles.
>> (If the sources compile and run the same behavior some won't know/care.)
>>
>> Then, objects, according to "naming and directory interface" usually
>> enough, Orange Book for example defines granular access controls,
>> so, including all things like files.
>>
>>
>> About quota and limits and the like, and about the perceived value
>> of pre-emptive scheduling to avoid "hogging", or thrashing, here
>> is an account of basically unmaskable uncatchable interrupts that
>> have as a signal handler the operating system code on the core
>> that results making the task yield, then necessarily enough using
>> the usually context-switch machinery to pause it and restart it.
>> Most code eventually touches system calls, and if there's a spare
>> core it might actually be the idea to let the compute-intensive
>> routine employ the entire core.
>>
>> The many-core architectures of these days, even fifteen or twenty
>> years ago with "AMD Bulldozer and 8 cores" and the like, these
>> days usual PC or server chips have scores of cores, ..., often
>> for example with the idea of running a giant hypervisor then
>> as many virts, ..., like a Kubernetes cluster for example, ...,
>> or simply a ton of virts, ..., these days a single board is
>> as a model of a distributed system internal to itself.
>>
>>
>> The idea for allocation and sharing that "fairness is a matter
>> of mechanism, not policy", is for the usual ideas of "thoughput"
>> and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
>> about I/O and queues, and limits.
>>
>>
>> "Interrupts" are the events, "coherent cache lines" the units of
>> serialization of memory, DMA is the bulk transfer medium in protocol,
>> a byte is the smallest addressable memory unit, these are mostly
>> the ordering guarantees, all else "undefined".
>>
>> Proximity, affinity, coherency, mobility, ....
>>
>
> We build electronics. Our new PoE instrument line uses an RP2040
> dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any
> quantity.
>
> We call the two CPUs (and the two ends of the box) Alice and Bob.
>
> Alice does the ethernet and usb i/o, command parsing, calibrations,
> all that slow floating-point management. Bob does the realtime i/o,
> fixed-point, directly or through an FPGA.
>
> All programmed in bare-metal c with no OS. Abstraction=0.
>
> Seems to work.
>
>
> John Larkin
> Highland Tech Glen Canyon Design Center
> Lunatic Fringe Electronics
>

That seems cool. So, you wrote your own USB and packet stack?
Or, it's a system-on-chip?

I drive my tractor with my hands on the wheels and the sticks
and the levers and the other levers and the feet on the pedals
and the other pedals and my rear in the seat, ..., abstraction = 0.

[toc] | [prev] | [next] | [standalone]

#742471

On 03/29/2026 08:54 PM, Ross Finlayson wrote:
> On 03/29/2026 03:24 PM, john larkin wrote:
>> On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
>> <ross.a.finlayson@gmail.com> wrote:
>>
>>> On 03/29/2026 12:39 PM, Don Y wrote:
>>>> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>>>>> That seems to speak to "proximity" and "affinity", with regards
>>>>> to "coherency", and "mobility". To "move" state, about state & scope
>>>>> or the contents of (some of) memory and registers, of a process or
>>>>> task,
>>>>> here is described as "re-seating" which is also the usual enough
>>>>> idea in programming like C and C++.
>>>>
>>>> My goal is NOT to disrupt the "programmer's model" for "average
>>>> developers".  They should truly be able to think that they are running
>>>> on a uniprocessor but without any guarantees as to throughput
>>>> (to accommodate sharing the physical processor, communication
>>>> overhead, etc.).
>>>>
>>>> They shouldn't need to know where "they" are executing or that the
>>>> resources on which they rely may not be local.
>>>>
>>>> "Advanced developers" attend to the dynamic reconfiguration of
>>>> the system (at runtime).  So, THOSE developers build applications
>>>> that are given the ability ("capability") to relocate resources,
>>>> kill off tasks, spawn new ones, etc.  Because they, presumably, have
>>>> a more detailed understanding of the "System" beyond the scope of
>>>> some particular application/task within it.
>>>>
>>>>> Perhaps the most usual example is pre-emptive multithreading itself,
>>>>> about basically the state as a stack, and "process control block"
>>>>> and "thread control block" usually enough, about context-switching.
>>>>
>>>> I support a heterogeneous environment; an object can be migrated
>>>> to a different processor *family* at any time (while executing).
>>>> You shouldn't care as long as the interface (methods) to the
>>>> object remain available (for the capabilities you have been
>>>> granted) along with the current state of the object.
>>>>
>>>> Similarly, the algorithms used to implement those methods (as
>>>> well as internal data members) can change dynamically -- as long
>>>> as the interface functionality remains immutable.
>>>>
>>>> For example, I create namespaces -- (name, capability) dictionaries
>>>> -- for
>>>> each process.  If you only need a few registered names (stdin, stdout,
>>>> stderr),
>>>> the code that implements that is entirely different than the
>>>> implementation
>>>> that tries to manage hundreds of named entries.
>>>>
>>>> As it should be.  (because "you" are "billed" for the resources that
>>>> you
>>>> use, you'd not want to bear the cost of an implementation that did more
>>>> than you needed -- just like you wouldn't develop a standalone device
>>>> with more complexity/cost than necessary!)
>>>>
>>>> If names are insignificant (e.g., akin to file descriptors), then an
>>>> implementation might use a single "char" to represent a name, giving
>>>> you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
>>>> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>>>> (do you really *need* names like "Object 1", "Object 2", etc.?)
>>>>
>>>>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>>>>> the idea of the "re-routine" as a model of asychronous concurrency,
>>>>> is a little different than the usual idea of a co-routine, which
>>>>> is usually enough a fork in the process model, then about signals
>>>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>>>>> and task queues, basically the re-routine never "blocks" and has
>>>>> no "yield" nor "async" keywords in the source text, instead any
>>>>> call to a re-routine implicitly yields, and then the re-routine
>>>>> is run again later, the re-run, where as the re-routine is filled in,
>>>>> then then the re-routine adds a penalty of basically n^2 in time
>>>>> to be completely non-blocking and where asynchrony is modeled in
>>>>> the language as the normal procedural flow-of-control.
>>>>
>>>> "Yield" is just a hint to the scheduler.  If you have a preemptive
>>>> implementation where "time" can be a preemption criteria, then a
>>>> task need never "suggest" a good place to relinquish the processor.
>>>>
>>>> OTOH, if you can only preempt when the task invokes an OS primitive,
>>>> then you have to be wary of a developer spinning without ever giving
>>>> the system a chance to "interrupt".
>>>>
>>>>> Then, as that's only in the kernel itself, that n^2 might seem a
>>>>> huge penalty, yet, it's actually quite under that, since as the
>>>>> re-routine its data (in a stack) is filled in, then most of its
>>>>> routine is cache hits, the "memoized" calls to the re-routine.
>>>>>
>>>>> About the allocator, then this design concept basically is for
>>>>> making use of virtual memory, to be able to "re-seat" the memory
>>>>> of a process without changing a process' view of the memory.
>>>>
>>>> Of course.  But, with VMM, you can do so much more:
>>>> - CoW semantics
>>>> - DSM
>>>> - remapping "defective" memory
>>>> - releasing memory that will NEVER be revisited
>>>> - universal call by value (for large arguments)
>>>> etc.   None of these things need impact the developer.
>>>>
>>>>> This can help avoid both syscalls and memory fragmentation,
>>>>> since memory paging basically is performed by the user-space
>>>>> process in its time instead of by the kernel. This has the
>>>>> usual guarantees of process memory that it's to be visible only
>>>>> to the process itself unless explicitly shared, that then being
>>>>> treated as a usual sort of shared resource in the distributed sense.
>>>>>
>>>>> The syscalls by a process essentially yield (the process yields
>>>>> to the scheduler), about ideas like round-robin and fairness
>>>>> and anti-starvation and incremental-progress in the scheduler,
>>>>> while it's so that until a process gets any other signal and
>>>>> only touches its own memory that's non-yielding, then about
>>>>> the machinery of pre-emptive multithreading or context-switch
>>>>> and as with regards to hyper-threading or the interleaved contexts
>>>>> on the double-pipeline CPUs, the idea being that context-switching
>>>>> is along the lines of basically a periodic signal interrupt.
>>>>
>>>> But you have to guard against "non-cooperative" (and even HOSTILE!)
>>>> actors who may wish to compromise performance by monopolizing resources
>>>> (of which the CPU is but one).
>>>>
>>>> Using resource ledgers lets you constrain an application (process)
>>>> to a subset of the available resources.  Putting runtime constraints
>>>> on memory, time, etc. lets you remove a "bad actor" from the set
>>>> of processes eligible to run.  A persistent store lets you remember
>>>> this decision so you don't "readmit" the process at some future date!
>>>>
>>>>> Notions of "Orange Book" and "mandatory access control" then
>>>>> are considered "more than good ideas" with regards to the allocator
>>>>> and scheduler of resources in computation.
>>>>
>>>> Capabilities implicitly limit the actions that can be performed (i.e.,
>>>> methods that can be invoked) on an object.  E.g., I can let you
>>>> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>>>> once, and never again!
>>>>
>>>> How you refine your "permissions" is something that belongs in the
>>>> objects themselves -- not layered onto a "filesystem" as an
>>>> afterthought.
>>>>
>>>
>>>
>>> Hey, thanks for writing. Since all we know about each other
>>> are these brief exchanges, filling in some detail helps a lot
>>> to understand, or rather, get an idea, of an estimate of the
>>> depth of the comprehension of the whole machine stack.
>>>
>>> The idea of a kernel or operating system (executive, scheduler,
>>> ..., interactive "operating system") for "commodity" architectures
>>> these days is that it's pretty ubiquitous the various chips'
>>> architectures, then that PCIe is on everything PC, then about
>>> usually enough USB, then about the NIC and USB root, those are
>>> pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
>>> and the SMI or as about DeviceTree, ..., it's ubiquitous,
>>> after "economy of scale" a simple enough "economy of ubiquity".
>>>
>>> So, the chips are almost all 64-bit their native word width, though
>>> agreeably sometimes it's 128, and they have various vector or SIMD
>>> instructions, then as with regards to fitting two operands in a word,
>>> the SWAR approach, about vectorizing the scalars, and word and
>>> double-word and word and half-word.
>>>
>>> Then, here mostly the consideration is the "head-less" or "HID-less",
>>> there's no human interface device involved in server runtime images
>>> for things like running services or usually enough "boxes" or "nodes".
>>>
>>>
>>> Then, for compiling existing sources, it seems the easiest way to
>>> do that is to implement profiles of POSIX, or posix base and pthreads.
>>> That then of course is much the traditional UNIX account of where
>>> "everything is a file", though, the operating system itself doesn't
>>> need to be implemented that way, just surface the usual objects as
>>> they are as primitives, and mostly as having file handles.
>>> (If the sources compile and run the same behavior some won't know/care.)
>>>
>>> Then, objects, according to "naming and directory interface" usually
>>> enough, Orange Book for example defines granular access controls,
>>> so, including all things like files.
>>>
>>>
>>> About quota and limits and the like, and about the perceived value
>>> of pre-emptive scheduling to avoid "hogging", or thrashing, here
>>> is an account of basically unmaskable uncatchable interrupts that
>>> have as a signal handler the operating system code on the core
>>> that results making the task yield, then necessarily enough using
>>> the usually context-switch machinery to pause it and restart it.
>>> Most code eventually touches system calls, and if there's a spare
>>> core it might actually be the idea to let the compute-intensive
>>> routine employ the entire core.
>>>
>>> The many-core architectures of these days, even fifteen or twenty
>>> years ago with "AMD Bulldozer and 8 cores" and the like, these
>>> days usual PC or server chips have scores of cores, ..., often
>>> for example with the idea of running a giant hypervisor then
>>> as many virts, ..., like a Kubernetes cluster for example, ...,
>>> or simply a ton of virts, ..., these days a single board is
>>> as a model of a distributed system internal to itself.
>>>
>>>
>>> The idea for allocation and sharing that "fairness is a matter
>>> of mechanism, not policy", is for the usual ideas of "thoughput"
>>> and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
>>> about I/O and queues, and limits.
>>>
>>>
>>> "Interrupts" are the events, "coherent cache lines" the units of
>>> serialization of memory, DMA is the bulk transfer medium in protocol,
>>> a byte is the smallest addressable memory unit, these are mostly
>>> the ordering guarantees, all else "undefined".
>>>
>>> Proximity, affinity, coherency, mobility, ....
>>>
>>
>> We build electronics. Our new PoE instrument line uses an RP2040
>> dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any
>> quantity.
>>
>> We call the two CPUs (and the two ends of the box) Alice and Bob.
>>
>> Alice does the ethernet and usb i/o, command parsing, calibrations,
>> all that slow floating-point management. Bob does the realtime i/o,
>> fixed-point, directly or through an FPGA.
>>
>> All programmed in bare-metal c with no OS. Abstraction=0.
>>
>> Seems to work.
>>
>>
>> John Larkin
>> Highland Tech Glen Canyon Design Center
>> Lunatic Fringe Electronics
>>
>
> That seems cool. So, you wrote your own USB and packet stack?
> Or, it's a system-on-chip?
>
> I drive my tractor with my hands on the wheels and the sticks
> and the levers and the other levers and the feet on the pedals
> and the other pedals and my rear in the seat, ..., abstraction = 0.
>
>
>

Attitudes are various about "abstraction" and "concreteness".
(Attitudes or "opinions".) Some prefer to write more or less
directly to the concrete adapter, others prefer to model the
interaction since usually only a tiny, tiny subset of the
"defined behavior" of the concrete adapter fulfills its
abstract function.

It takes all kinds, ....

"The Blind Men and the Elephant" is a usual sort of account,
and it's the same kind of idea since forever that any two
individuals are going to see things differently, and a question
whether they even see the same thing at all, "subjectivity",
then there's the great formal and practical account of
the formal or "interfaces" usually enough, interfaces to
the adapters, "inter-subjectivity", so when we clock out
we can say it's done.


When I see someone writing to directly to the concrete
adapter, sometimes it's hard to distinguish that or
easy to read that as from, "Hello, World".

Then, "layers" is usually enough the idea of making
models of modules, in layers, then that the boundaries
exist, then for example that the code its logic is
"separable and composable", then to point it at other
adapters their interfaces or harnesses, for example
for "systems under test" vis-a-vis "systems under load".

[toc] | [prev] | [next] | [standalone]

#742472

On 03/29/2026 09:07 PM, Ross Finlayson wrote:
> On 03/29/2026 08:54 PM, Ross Finlayson wrote:
>> On 03/29/2026 03:24 PM, john larkin wrote:
>>> On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
>>> <ross.a.finlayson@gmail.com> wrote:
>>>
>>>> On 03/29/2026 12:39 PM, Don Y wrote:
>>>>> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>>>>>> That seems to speak to "proximity" and "affinity", with regards
>>>>>> to "coherency", and "mobility". To "move" state, about state & scope
>>>>>> or the contents of (some of) memory and registers, of a process or
>>>>>> task,
>>>>>> here is described as "re-seating" which is also the usual enough
>>>>>> idea in programming like C and C++.
>>>>>
>>>>> My goal is NOT to disrupt the "programmer's model" for "average
>>>>> developers".  They should truly be able to think that they are running
>>>>> on a uniprocessor but without any guarantees as to throughput
>>>>> (to accommodate sharing the physical processor, communication
>>>>> overhead, etc.).
>>>>>
>>>>> They shouldn't need to know where "they" are executing or that the
>>>>> resources on which they rely may not be local.
>>>>>
>>>>> "Advanced developers" attend to the dynamic reconfiguration of
>>>>> the system (at runtime).  So, THOSE developers build applications
>>>>> that are given the ability ("capability") to relocate resources,
>>>>> kill off tasks, spawn new ones, etc.  Because they, presumably, have
>>>>> a more detailed understanding of the "System" beyond the scope of
>>>>> some particular application/task within it.
>>>>>
>>>>>> Perhaps the most usual example is pre-emptive multithreading itself,
>>>>>> about basically the state as a stack, and "process control block"
>>>>>> and "thread control block" usually enough, about context-switching.
>>>>>
>>>>> I support a heterogeneous environment; an object can be migrated
>>>>> to a different processor *family* at any time (while executing).
>>>>> You shouldn't care as long as the interface (methods) to the
>>>>> object remain available (for the capabilities you have been
>>>>> granted) along with the current state of the object.
>>>>>
>>>>> Similarly, the algorithms used to implement those methods (as
>>>>> well as internal data members) can change dynamically -- as long
>>>>> as the interface functionality remains immutable.
>>>>>
>>>>> For example, I create namespaces -- (name, capability) dictionaries
>>>>> -- for
>>>>> each process.  If you only need a few registered names (stdin, stdout,
>>>>> stderr),
>>>>> the code that implements that is entirely different than the
>>>>> implementation
>>>>> that tries to manage hundreds of named entries.
>>>>>
>>>>> As it should be.  (because "you" are "billed" for the resources that
>>>>> you
>>>>> use, you'd not want to bear the cost of an implementation that did
>>>>> more
>>>>> than you needed -- just like you wouldn't develop a standalone device
>>>>> with more complexity/cost than necessary!)
>>>>>
>>>>> If names are insignificant (e.g., akin to file descriptors), then an
>>>>> implementation might use a single "char" to represent a name, giving
>>>>> you access to ~200+ unique names of the form "a", "b", "^X", "\b",
>>>>> etc.
>>>>> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>>>>> (do you really *need* names like "Object 1", "Object 2", etc.?)
>>>>>
>>>>>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>>>>>> the idea of the "re-routine" as a model of asychronous concurrency,
>>>>>> is a little different than the usual idea of a co-routine, which
>>>>>> is usually enough a fork in the process model, then about signals
>>>>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>>>>>> and task queues, basically the re-routine never "blocks" and has
>>>>>> no "yield" nor "async" keywords in the source text, instead any
>>>>>> call to a re-routine implicitly yields, and then the re-routine
>>>>>> is run again later, the re-run, where as the re-routine is filled in,
>>>>>> then then the re-routine adds a penalty of basically n^2 in time
>>>>>> to be completely non-blocking and where asynchrony is modeled in
>>>>>> the language as the normal procedural flow-of-control.
>>>>>
>>>>> "Yield" is just a hint to the scheduler.  If you have a preemptive
>>>>> implementation where "time" can be a preemption criteria, then a
>>>>> task need never "suggest" a good place to relinquish the processor.
>>>>>
>>>>> OTOH, if you can only preempt when the task invokes an OS primitive,
>>>>> then you have to be wary of a developer spinning without ever giving
>>>>> the system a chance to "interrupt".
>>>>>
>>>>>> Then, as that's only in the kernel itself, that n^2 might seem a
>>>>>> huge penalty, yet, it's actually quite under that, since as the
>>>>>> re-routine its data (in a stack) is filled in, then most of its
>>>>>> routine is cache hits, the "memoized" calls to the re-routine.
>>>>>>
>>>>>> About the allocator, then this design concept basically is for
>>>>>> making use of virtual memory, to be able to "re-seat" the memory
>>>>>> of a process without changing a process' view of the memory.
>>>>>
>>>>> Of course.  But, with VMM, you can do so much more:
>>>>> - CoW semantics
>>>>> - DSM
>>>>> - remapping "defective" memory
>>>>> - releasing memory that will NEVER be revisited
>>>>> - universal call by value (for large arguments)
>>>>> etc.   None of these things need impact the developer.
>>>>>
>>>>>> This can help avoid both syscalls and memory fragmentation,
>>>>>> since memory paging basically is performed by the user-space
>>>>>> process in its time instead of by the kernel. This has the
>>>>>> usual guarantees of process memory that it's to be visible only
>>>>>> to the process itself unless explicitly shared, that then being
>>>>>> treated as a usual sort of shared resource in the distributed sense.
>>>>>>
>>>>>> The syscalls by a process essentially yield (the process yields
>>>>>> to the scheduler), about ideas like round-robin and fairness
>>>>>> and anti-starvation and incremental-progress in the scheduler,
>>>>>> while it's so that until a process gets any other signal and
>>>>>> only touches its own memory that's non-yielding, then about
>>>>>> the machinery of pre-emptive multithreading or context-switch
>>>>>> and as with regards to hyper-threading or the interleaved contexts
>>>>>> on the double-pipeline CPUs, the idea being that context-switching
>>>>>> is along the lines of basically a periodic signal interrupt.
>>>>>
>>>>> But you have to guard against "non-cooperative" (and even HOSTILE!)
>>>>> actors who may wish to compromise performance by monopolizing
>>>>> resources
>>>>> (of which the CPU is but one).
>>>>>
>>>>> Using resource ledgers lets you constrain an application (process)
>>>>> to a subset of the available resources.  Putting runtime constraints
>>>>> on memory, time, etc. lets you remove a "bad actor" from the set
>>>>> of processes eligible to run.  A persistent store lets you remember
>>>>> this decision so you don't "readmit" the process at some future date!
>>>>>
>>>>>> Notions of "Orange Book" and "mandatory access control" then
>>>>>> are considered "more than good ideas" with regards to the allocator
>>>>>> and scheduler of resources in computation.
>>>>>
>>>>> Capabilities implicitly limit the actions that can be performed (i.e.,
>>>>> methods that can be invoked) on an object.  E.g., I can let you
>>>>> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>>>>> once, and never again!
>>>>>
>>>>> How you refine your "permissions" is something that belongs in the
>>>>> objects themselves -- not layered onto a "filesystem" as an
>>>>> afterthought.
>>>>>
>>>>
>>>>
>>>> Hey, thanks for writing. Since all we know about each other
>>>> are these brief exchanges, filling in some detail helps a lot
>>>> to understand, or rather, get an idea, of an estimate of the
>>>> depth of the comprehension of the whole machine stack.
>>>>
>>>> The idea of a kernel or operating system (executive, scheduler,
>>>> ..., interactive "operating system") for "commodity" architectures
>>>> these days is that it's pretty ubiquitous the various chips'
>>>> architectures, then that PCIe is on everything PC, then about
>>>> usually enough USB, then about the NIC and USB root, those are
>>>> pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
>>>> and the SMI or as about DeviceTree, ..., it's ubiquitous,
>>>> after "economy of scale" a simple enough "economy of ubiquity".
>>>>
>>>> So, the chips are almost all 64-bit their native word width, though
>>>> agreeably sometimes it's 128, and they have various vector or SIMD
>>>> instructions, then as with regards to fitting two operands in a word,
>>>> the SWAR approach, about vectorizing the scalars, and word and
>>>> double-word and word and half-word.
>>>>
>>>> Then, here mostly the consideration is the "head-less" or "HID-less",
>>>> there's no human interface device involved in server runtime images
>>>> for things like running services or usually enough "boxes" or "nodes".
>>>>
>>>>
>>>> Then, for compiling existing sources, it seems the easiest way to
>>>> do that is to implement profiles of POSIX, or posix base and pthreads.
>>>> That then of course is much the traditional UNIX account of where
>>>> "everything is a file", though, the operating system itself doesn't
>>>> need to be implemented that way, just surface the usual objects as
>>>> they are as primitives, and mostly as having file handles.
>>>> (If the sources compile and run the same behavior some won't
>>>> know/care.)
>>>>
>>>> Then, objects, according to "naming and directory interface" usually
>>>> enough, Orange Book for example defines granular access controls,
>>>> so, including all things like files.
>>>>
>>>>
>>>> About quota and limits and the like, and about the perceived value
>>>> of pre-emptive scheduling to avoid "hogging", or thrashing, here
>>>> is an account of basically unmaskable uncatchable interrupts that
>>>> have as a signal handler the operating system code on the core
>>>> that results making the task yield, then necessarily enough using
>>>> the usually context-switch machinery to pause it and restart it.
>>>> Most code eventually touches system calls, and if there's a spare
>>>> core it might actually be the idea to let the compute-intensive
>>>> routine employ the entire core.
>>>>
>>>> The many-core architectures of these days, even fifteen or twenty
>>>> years ago with "AMD Bulldozer and 8 cores" and the like, these
>>>> days usual PC or server chips have scores of cores, ..., often
>>>> for example with the idea of running a giant hypervisor then
>>>> as many virts, ..., like a Kubernetes cluster for example, ...,
>>>> or simply a ton of virts, ..., these days a single board is
>>>> as a model of a distributed system internal to itself.
>>>>
>>>>
>>>> The idea for allocation and sharing that "fairness is a matter
>>>> of mechanism, not policy", is for the usual ideas of "thoughput"
>>>> and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
>>>> about I/O and queues, and limits.
>>>>
>>>>
>>>> "Interrupts" are the events, "coherent cache lines" the units of
>>>> serialization of memory, DMA is the bulk transfer medium in protocol,
>>>> a byte is the smallest addressable memory unit, these are mostly
>>>> the ordering guarantees, all else "undefined".
>>>>
>>>> Proximity, affinity, coherency, mobility, ....
>>>>
>>>
>>> We build electronics. Our new PoE instrument line uses an RP2040
>>> dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any
>>> quantity.
>>>
>>> We call the two CPUs (and the two ends of the box) Alice and Bob.
>>>
>>> Alice does the ethernet and usb i/o, command parsing, calibrations,
>>> all that slow floating-point management. Bob does the realtime i/o,
>>> fixed-point, directly or through an FPGA.
>>>
>>> All programmed in bare-metal c with no OS. Abstraction=0.
>>>
>>> Seems to work.
>>>
>>>
>>> John Larkin
>>> Highland Tech Glen Canyon Design Center
>>> Lunatic Fringe Electronics
>>>
>>
>> That seems cool. So, you wrote your own USB and packet stack?
>> Or, it's a system-on-chip?
>>
>> I drive my tractor with my hands on the wheels and the sticks
>> and the levers and the other levers and the feet on the pedals
>> and the other pedals and my rear in the seat, ..., abstraction = 0.
>>
>>
>>
>
> Attitudes are various about "abstraction" and "concreteness".
> (Attitudes or "opinions".) Some prefer to write more or less
> directly to the concrete adapter, others prefer to model the
> interaction since usually only a tiny, tiny subset of the
> "defined behavior" of the concrete adapter fulfills its
> abstract function.
>
> It takes all kinds, ....
>
> "The Blind Men and the Elephant" is a usual sort of account,
> and it's the same kind of idea since forever that any two
> individuals are going to see things differently, and a question
> whether they even see the same thing at all, "subjectivity",
> then there's the great formal and practical account of
> the formal or "interfaces" usually enough, interfaces to
> the adapters, "inter-subjectivity", so when we clock out
> we can say it's done.
>
>
> When I see someone writing to directly to the concrete
> adapter, sometimes it's hard to distinguish that or
> easy to read that as from, "Hello, World".
>
> Then, "layers" is usually enough the idea of making
> models of modules, in layers, then that the boundaries
> exist, then for example that the code its logic is
> "separable and composable", then to point it at other
> adapters their interfaces or harnesses, for example
> for "systems under test" vis-a-vis "systems under load".
>
>

I'm not a mechanic yet the metaphor about the tractor
for example is about compression test. If the engine's
misfiring or burning oil or something, then a usual enough
idea is to remove one of the spark plugs and attach a compression
tester and turn over the starter motor and and measure the
compression and perhaps vacuum and compare it to a table
from the manufacturer to diagnose what's going on. So,
that's an abstraction, all the activity that goes into
maintenance for operation is essentially abstraction.

Or, you know, according to instruction.

Exercises then in "abstraction and concreteness",
are totally usual, and figuring them out is for
example for the difference between writing logic
and writing libraries, one for concreteness the
other abstraction.

It goes both ways, ..., it takes all kinds.

(I am definitely a software engineer and
have written many, many KLOCs in prod and under
continuous test. Or, as my desk neighbor once
told me, she said, "your code is solid".  So,
I'm familiar with distributed systems on
the order of orders and events.)

[toc] | [prev] | [next] | [standalone]

#742485

On Sun, 29 Mar 2026 20:54:28 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:

>On 03/29/2026 03:24 PM, john larkin wrote:
>> On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
>> <ross.a.finlayson@gmail.com> wrote:
>>
>>> On 03/29/2026 12:39 PM, Don Y wrote:
>>>> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>>>>> That seems to speak to "proximity" and "affinity", with regards
>>>>> to "coherency", and "mobility". To "move" state, about state & scope
>>>>> or the contents of (some of) memory and registers, of a process or task,
>>>>> here is described as "re-seating" which is also the usual enough
>>>>> idea in programming like C and C++.
>>>>
>>>> My goal is NOT to disrupt the "programmer's model" for "average
>>>> developers".  They should truly be able to think that they are running
>>>> on a uniprocessor but without any guarantees as to throughput
>>>> (to accommodate sharing the physical processor, communication
>>>> overhead, etc.).
>>>>
>>>> They shouldn't need to know where "they" are executing or that the
>>>> resources on which they rely may not be local.
>>>>
>>>> "Advanced developers" attend to the dynamic reconfiguration of
>>>> the system (at runtime).  So, THOSE developers build applications
>>>> that are given the ability ("capability") to relocate resources,
>>>> kill off tasks, spawn new ones, etc.  Because they, presumably, have
>>>> a more detailed understanding of the "System" beyond the scope of
>>>> some particular application/task within it.
>>>>
>>>>> Perhaps the most usual example is pre-emptive multithreading itself,
>>>>> about basically the state as a stack, and "process control block"
>>>>> and "thread control block" usually enough, about context-switching.
>>>>
>>>> I support a heterogeneous environment; an object can be migrated
>>>> to a different processor *family* at any time (while executing).
>>>> You shouldn't care as long as the interface (methods) to the
>>>> object remain available (for the capabilities you have been
>>>> granted) along with the current state of the object.
>>>>
>>>> Similarly, the algorithms used to implement those methods (as
>>>> well as internal data members) can change dynamically -- as long
>>>> as the interface functionality remains immutable.
>>>>
>>>> For example, I create namespaces -- (name, capability) dictionaries -- for
>>>> each process.  If you only need a few registered names (stdin, stdout,
>>>> stderr),
>>>> the code that implements that is entirely different than the implementation
>>>> that tries to manage hundreds of named entries.
>>>>
>>>> As it should be.  (because "you" are "billed" for the resources that you
>>>> use, you'd not want to bear the cost of an implementation that did more
>>>> than you needed -- just like you wouldn't develop a standalone device
>>>> with more complexity/cost than necessary!)
>>>>
>>>> If names are insignificant (e.g., akin to file descriptors), then an
>>>> implementation might use a single "char" to represent a name, giving
>>>> you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
>>>> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>>>> (do you really *need* names like "Object 1", "Object 2", etc.?)
>>>>
>>>>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>>>>> the idea of the "re-routine" as a model of asychronous concurrency,
>>>>> is a little different than the usual idea of a co-routine, which
>>>>> is usually enough a fork in the process model, then about signals
>>>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>>>>> and task queues, basically the re-routine never "blocks" and has
>>>>> no "yield" nor "async" keywords in the source text, instead any
>>>>> call to a re-routine implicitly yields, and then the re-routine
>>>>> is run again later, the re-run, where as the re-routine is filled in,
>>>>> then then the re-routine adds a penalty of basically n^2 in time
>>>>> to be completely non-blocking and where asynchrony is modeled in
>>>>> the language as the normal procedural flow-of-control.
>>>>
>>>> "Yield" is just a hint to the scheduler.  If you have a preemptive
>>>> implementation where "time" can be a preemption criteria, then a
>>>> task need never "suggest" a good place to relinquish the processor.
>>>>
>>>> OTOH, if you can only preempt when the task invokes an OS primitive,
>>>> then you have to be wary of a developer spinning without ever giving
>>>> the system a chance to "interrupt".
>>>>
>>>>> Then, as that's only in the kernel itself, that n^2 might seem a
>>>>> huge penalty, yet, it's actually quite under that, since as the
>>>>> re-routine its data (in a stack) is filled in, then most of its
>>>>> routine is cache hits, the "memoized" calls to the re-routine.
>>>>>
>>>>> About the allocator, then this design concept basically is for
>>>>> making use of virtual memory, to be able to "re-seat" the memory
>>>>> of a process without changing a process' view of the memory.
>>>>
>>>> Of course.  But, with VMM, you can do so much more:
>>>> - CoW semantics
>>>> - DSM
>>>> - remapping "defective" memory
>>>> - releasing memory that will NEVER be revisited
>>>> - universal call by value (for large arguments)
>>>> etc.   None of these things need impact the developer.
>>>>
>>>>> This can help avoid both syscalls and memory fragmentation,
>>>>> since memory paging basically is performed by the user-space
>>>>> process in its time instead of by the kernel. This has the
>>>>> usual guarantees of process memory that it's to be visible only
>>>>> to the process itself unless explicitly shared, that then being
>>>>> treated as a usual sort of shared resource in the distributed sense.
>>>>>
>>>>> The syscalls by a process essentially yield (the process yields
>>>>> to the scheduler), about ideas like round-robin and fairness
>>>>> and anti-starvation and incremental-progress in the scheduler,
>>>>> while it's so that until a process gets any other signal and
>>>>> only touches its own memory that's non-yielding, then about
>>>>> the machinery of pre-emptive multithreading or context-switch
>>>>> and as with regards to hyper-threading or the interleaved contexts
>>>>> on the double-pipeline CPUs, the idea being that context-switching
>>>>> is along the lines of basically a periodic signal interrupt.
>>>>
>>>> But you have to guard against "non-cooperative" (and even HOSTILE!)
>>>> actors who may wish to compromise performance by monopolizing resources
>>>> (of which the CPU is but one).
>>>>
>>>> Using resource ledgers lets you constrain an application (process)
>>>> to a subset of the available resources.  Putting runtime constraints
>>>> on memory, time, etc. lets you remove a "bad actor" from the set
>>>> of processes eligible to run.  A persistent store lets you remember
>>>> this decision so you don't "readmit" the process at some future date!
>>>>
>>>>> Notions of "Orange Book" and "mandatory access control" then
>>>>> are considered "more than good ideas" with regards to the allocator
>>>>> and scheduler of resources in computation.
>>>>
>>>> Capabilities implicitly limit the actions that can be performed (i.e.,
>>>> methods that can be invoked) on an object.  E.g., I can let you
>>>> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>>>> once, and never again!
>>>>
>>>> How you refine your "permissions" is something that belongs in the
>>>> objects themselves -- not layered onto a "filesystem" as an afterthought.
>>>>
>>>
>>>
>>> Hey, thanks for writing. Since all we know about each other
>>> are these brief exchanges, filling in some detail helps a lot
>>> to understand, or rather, get an idea, of an estimate of the
>>> depth of the comprehension of the whole machine stack.
>>>
>>> The idea of a kernel or operating system (executive, scheduler,
>>> ..., interactive "operating system") for "commodity" architectures
>>> these days is that it's pretty ubiquitous the various chips'
>>> architectures, then that PCIe is on everything PC, then about
>>> usually enough USB, then about the NIC and USB root, those are
>>> pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
>>> and the SMI or as about DeviceTree, ..., it's ubiquitous,
>>> after "economy of scale" a simple enough "economy of ubiquity".
>>>
>>> So, the chips are almost all 64-bit their native word width, though
>>> agreeably sometimes it's 128, and they have various vector or SIMD
>>> instructions, then as with regards to fitting two operands in a word,
>>> the SWAR approach, about vectorizing the scalars, and word and
>>> double-word and word and half-word.
>>>
>>> Then, here mostly the consideration is the "head-less" or "HID-less",
>>> there's no human interface device involved in server runtime images
>>> for things like running services or usually enough "boxes" or "nodes".
>>>
>>>
>>> Then, for compiling existing sources, it seems the easiest way to
>>> do that is to implement profiles of POSIX, or posix base and pthreads.
>>> That then of course is much the traditional UNIX account of where
>>> "everything is a file", though, the operating system itself doesn't
>>> need to be implemented that way, just surface the usual objects as
>>> they are as primitives, and mostly as having file handles.
>>> (If the sources compile and run the same behavior some won't know/care.)
>>>
>>> Then, objects, according to "naming and directory interface" usually
>>> enough, Orange Book for example defines granular access controls,
>>> so, including all things like files.
>>>
>>>
>>> About quota and limits and the like, and about the perceived value
>>> of pre-emptive scheduling to avoid "hogging", or thrashing, here
>>> is an account of basically unmaskable uncatchable interrupts that
>>> have as a signal handler the operating system code on the core
>>> that results making the task yield, then necessarily enough using
>>> the usually context-switch machinery to pause it and restart it.
>>> Most code eventually touches system calls, and if there's a spare
>>> core it might actually be the idea to let the compute-intensive
>>> routine employ the entire core.
>>>
>>> The many-core architectures of these days, even fifteen or twenty
>>> years ago with "AMD Bulldozer and 8 cores" and the like, these
>>> days usual PC or server chips have scores of cores, ..., often
>>> for example with the idea of running a giant hypervisor then
>>> as many virts, ..., like a Kubernetes cluster for example, ...,
>>> or simply a ton of virts, ..., these days a single board is
>>> as a model of a distributed system internal to itself.
>>>
>>>
>>> The idea for allocation and sharing that "fairness is a matter
>>> of mechanism, not policy", is for the usual ideas of "thoughput"
>>> and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
>>> about I/O and queues, and limits.
>>>
>>>
>>> "Interrupts" are the events, "coherent cache lines" the units of
>>> serialization of memory, DMA is the bulk transfer medium in protocol,
>>> a byte is the smallest addressable memory unit, these are mostly
>>> the ordering guarantees, all else "undefined".
>>>
>>> Proximity, affinity, coherency, mobility, ....
>>>
>>
>> We build electronics. Our new PoE instrument line uses an RP2040
>> dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any
>> quantity.
>>
>> We call the two CPUs (and the two ends of the box) Alice and Bob.
>>
>> Alice does the ethernet and usb i/o, command parsing, calibrations,
>> all that slow floating-point management. Bob does the realtime i/o,
>> fixed-point, directly or through an FPGA.
>>
>> All programmed in bare-metal c with no OS. Abstraction=0.
>>
>> Seems to work.
>>
>>
>> John Larkin
>> Highland Tech Glen Canyon Design Center
>> Lunatic Fringe Electronics
>>
>
>That seems cool. So, you wrote your own USB and packet stack?
>Or, it's a system-on-chip?
>
>I drive my tractor with my hands on the wheels and the sticks
>and the levers and the other levers and the feet on the pedals
>and the other pedals and my rear in the seat, ..., abstraction = 0.
>
>

We use the WizNet ethernet chip and the code that they supply. It's
more than a mac/phy: it handles packets and protocols, including UDP. 

The RP2040 has a built-in USB interface. The electrical interface to
the USBc connector is two resistors. It looks like a COM port to the
users. What's really slick is that the USB can also run in a mode
where it looks like a memory stick. To reload the systrem code, we
boot into memory stick mode and the user then drag-drops a single file
to update the box: Alice code, Bob code, and the FPGA config.

Tractors are cool. Physical and basic.


John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

[toc] | [prev] | [next] | [standalone]

#742493

On 03/30/2026 07:44 AM, john larkin wrote:
> On Sun, 29 Mar 2026 20:54:28 -0700, Ross Finlayson
> <ross.a.finlayson@gmail.com> wrote:
>
>> On 03/29/2026 03:24 PM, john larkin wrote:
>>> On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
>>> <ross.a.finlayson@gmail.com> wrote:
>>>
>>>> On 03/29/2026 12:39 PM, Don Y wrote:
>>>>> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>>>>>> That seems to speak to "proximity" and "affinity", with regards
>>>>>> to "coherency", and "mobility". To "move" state, about state & scope
>>>>>> or the contents of (some of) memory and registers, of a process or task,
>>>>>> here is described as "re-seating" which is also the usual enough
>>>>>> idea in programming like C and C++.
>>>>>
>>>>> My goal is NOT to disrupt the "programmer's model" for "average
>>>>> developers".  They should truly be able to think that they are running
>>>>> on a uniprocessor but without any guarantees as to throughput
>>>>> (to accommodate sharing the physical processor, communication
>>>>> overhead, etc.).
>>>>>
>>>>> They shouldn't need to know where "they" are executing or that the
>>>>> resources on which they rely may not be local.
>>>>>
>>>>> "Advanced developers" attend to the dynamic reconfiguration of
>>>>> the system (at runtime).  So, THOSE developers build applications
>>>>> that are given the ability ("capability") to relocate resources,
>>>>> kill off tasks, spawn new ones, etc.  Because they, presumably, have
>>>>> a more detailed understanding of the "System" beyond the scope of
>>>>> some particular application/task within it.
>>>>>
>>>>>> Perhaps the most usual example is pre-emptive multithreading itself,
>>>>>> about basically the state as a stack, and "process control block"
>>>>>> and "thread control block" usually enough, about context-switching.
>>>>>
>>>>> I support a heterogeneous environment; an object can be migrated
>>>>> to a different processor *family* at any time (while executing).
>>>>> You shouldn't care as long as the interface (methods) to the
>>>>> object remain available (for the capabilities you have been
>>>>> granted) along with the current state of the object.
>>>>>
>>>>> Similarly, the algorithms used to implement those methods (as
>>>>> well as internal data members) can change dynamically -- as long
>>>>> as the interface functionality remains immutable.
>>>>>
>>>>> For example, I create namespaces -- (name, capability) dictionaries -- for
>>>>> each process.  If you only need a few registered names (stdin, stdout,
>>>>> stderr),
>>>>> the code that implements that is entirely different than the implementation
>>>>> that tries to manage hundreds of named entries.
>>>>>
>>>>> As it should be.  (because "you" are "billed" for the resources that you
>>>>> use, you'd not want to bear the cost of an implementation that did more
>>>>> than you needed -- just like you wouldn't develop a standalone device
>>>>> with more complexity/cost than necessary!)
>>>>>
>>>>> If names are insignificant (e.g., akin to file descriptors), then an
>>>>> implementation might use a single "char" to represent a name, giving
>>>>> you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
>>>>> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>>>>> (do you really *need* names like "Object 1", "Object 2", etc.?)
>>>>>
>>>>>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>>>>>> the idea of the "re-routine" as a model of asychronous concurrency,
>>>>>> is a little different than the usual idea of a co-routine, which
>>>>>> is usually enough a fork in the process model, then about signals
>>>>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>>>>>> and task queues, basically the re-routine never "blocks" and has
>>>>>> no "yield" nor "async" keywords in the source text, instead any
>>>>>> call to a re-routine implicitly yields, and then the re-routine
>>>>>> is run again later, the re-run, where as the re-routine is filled in,
>>>>>> then then the re-routine adds a penalty of basically n^2 in time
>>>>>> to be completely non-blocking and where asynchrony is modeled in
>>>>>> the language as the normal procedural flow-of-control.
>>>>>
>>>>> "Yield" is just a hint to the scheduler.  If you have a preemptive
>>>>> implementation where "time" can be a preemption criteria, then a
>>>>> task need never "suggest" a good place to relinquish the processor.
>>>>>
>>>>> OTOH, if you can only preempt when the task invokes an OS primitive,
>>>>> then you have to be wary of a developer spinning without ever giving
>>>>> the system a chance to "interrupt".
>>>>>
>>>>>> Then, as that's only in the kernel itself, that n^2 might seem a
>>>>>> huge penalty, yet, it's actually quite under that, since as the
>>>>>> re-routine its data (in a stack) is filled in, then most of its
>>>>>> routine is cache hits, the "memoized" calls to the re-routine.
>>>>>>
>>>>>> About the allocator, then this design concept basically is for
>>>>>> making use of virtual memory, to be able to "re-seat" the memory
>>>>>> of a process without changing a process' view of the memory.
>>>>>
>>>>> Of course.  But, with VMM, you can do so much more:
>>>>> - CoW semantics
>>>>> - DSM
>>>>> - remapping "defective" memory
>>>>> - releasing memory that will NEVER be revisited
>>>>> - universal call by value (for large arguments)
>>>>> etc.   None of these things need impact the developer.
>>>>>
>>>>>> This can help avoid both syscalls and memory fragmentation,
>>>>>> since memory paging basically is performed by the user-space
>>>>>> process in its time instead of by the kernel. This has the
>>>>>> usual guarantees of process memory that it's to be visible only
>>>>>> to the process itself unless explicitly shared, that then being
>>>>>> treated as a usual sort of shared resource in the distributed sense.
>>>>>>
>>>>>> The syscalls by a process essentially yield (the process yields
>>>>>> to the scheduler), about ideas like round-robin and fairness
>>>>>> and anti-starvation and incremental-progress in the scheduler,
>>>>>> while it's so that until a process gets any other signal and
>>>>>> only touches its own memory that's non-yielding, then about
>>>>>> the machinery of pre-emptive multithreading or context-switch
>>>>>> and as with regards to hyper-threading or the interleaved contexts
>>>>>> on the double-pipeline CPUs, the idea being that context-switching
>>>>>> is along the lines of basically a periodic signal interrupt.
>>>>>
>>>>> But you have to guard against "non-cooperative" (and even HOSTILE!)
>>>>> actors who may wish to compromise performance by monopolizing resources
>>>>> (of which the CPU is but one).
>>>>>
>>>>> Using resource ledgers lets you constrain an application (process)
>>>>> to a subset of the available resources.  Putting runtime constraints
>>>>> on memory, time, etc. lets you remove a "bad actor" from the set
>>>>> of processes eligible to run.  A persistent store lets you remember
>>>>> this decision so you don't "readmit" the process at some future date!
>>>>>
>>>>>> Notions of "Orange Book" and "mandatory access control" then
>>>>>> are considered "more than good ideas" with regards to the allocator
>>>>>> and scheduler of resources in computation.
>>>>>
>>>>> Capabilities implicitly limit the actions that can be performed (i.e.,
>>>>> methods that can be invoked) on an object.  E.g., I can let you
>>>>> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>>>>> once, and never again!
>>>>>
>>>>> How you refine your "permissions" is something that belongs in the
>>>>> objects themselves -- not layered onto a "filesystem" as an afterthought.
>>>>>
>>>>
>>>>
>>>> Hey, thanks for writing. Since all we know about each other
>>>> are these brief exchanges, filling in some detail helps a lot
>>>> to understand, or rather, get an idea, of an estimate of the
>>>> depth of the comprehension of the whole machine stack.
>>>>
>>>> The idea of a kernel or operating system (executive, scheduler,
>>>> ..., interactive "operating system") for "commodity" architectures
>>>> these days is that it's pretty ubiquitous the various chips'
>>>> architectures, then that PCIe is on everything PC, then about
>>>> usually enough USB, then about the NIC and USB root, those are
>>>> pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
>>>> and the SMI or as about DeviceTree, ..., it's ubiquitous,
>>>> after "economy of scale" a simple enough "economy of ubiquity".
>>>>
>>>> So, the chips are almost all 64-bit their native word width, though
>>>> agreeably sometimes it's 128, and they have various vector or SIMD
>>>> instructions, then as with regards to fitting two operands in a word,
>>>> the SWAR approach, about vectorizing the scalars, and word and
>>>> double-word and word and half-word.
>>>>
>>>> Then, here mostly the consideration is the "head-less" or "HID-less",
>>>> there's no human interface device involved in server runtime images
>>>> for things like running services or usually enough "boxes" or "nodes".
>>>>
>>>>
>>>> Then, for compiling existing sources, it seems the easiest way to
>>>> do that is to implement profiles of POSIX, or posix base and pthreads.
>>>> That then of course is much the traditional UNIX account of where
>>>> "everything is a file", though, the operating system itself doesn't
>>>> need to be implemented that way, just surface the usual objects as
>>>> they are as primitives, and mostly as having file handles.
>>>> (If the sources compile and run the same behavior some won't know/care.)
>>>>
>>>> Then, objects, according to "naming and directory interface" usually
>>>> enough, Orange Book for example defines granular access controls,
>>>> so, including all things like files.
>>>>
>>>>
>>>> About quota and limits and the like, and about the perceived value
>>>> of pre-emptive scheduling to avoid "hogging", or thrashing, here
>>>> is an account of basically unmaskable uncatchable interrupts that
>>>> have as a signal handler the operating system code on the core
>>>> that results making the task yield, then necessarily enough using
>>>> the usually context-switch machinery to pause it and restart it.
>>>> Most code eventually touches system calls, and if there's a spare
>>>> core it might actually be the idea to let the compute-intensive
>>>> routine employ the entire core.
>>>>
>>>> The many-core architectures of these days, even fifteen or twenty
>>>> years ago with "AMD Bulldozer and 8 cores" and the like, these
>>>> days usual PC or server chips have scores of cores, ..., often
>>>> for example with the idea of running a giant hypervisor then
>>>> as many virts, ..., like a Kubernetes cluster for example, ...,
>>>> or simply a ton of virts, ..., these days a single board is
>>>> as a model of a distributed system internal to itself.
>>>>
>>>>
>>>> The idea for allocation and sharing that "fairness is a matter
>>>> of mechanism, not policy", is for the usual ideas of "thoughput"
>>>> and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
>>>> about I/O and queues, and limits.
>>>>
>>>>
>>>> "Interrupts" are the events, "coherent cache lines" the units of
>>>> serialization of memory, DMA is the bulk transfer medium in protocol,
>>>> a byte is the smallest addressable memory unit, these are mostly
>>>> the ordering guarantees, all else "undefined".
>>>>
>>>> Proximity, affinity, coherency, mobility, ....
>>>>
>>>
>>> We build electronics. Our new PoE instrument line uses an RP2040
>>> dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any
>>> quantity.
>>>
>>> We call the two CPUs (and the two ends of the box) Alice and Bob.
>>>
>>> Alice does the ethernet and usb i/o, command parsing, calibrations,
>>> all that slow floating-point management. Bob does the realtime i/o,
>>> fixed-point, directly or through an FPGA.
>>>
>>> All programmed in bare-metal c with no OS. Abstraction=0.
>>>
>>> Seems to work.
>>>
>>>
>>> John Larkin
>>> Highland Tech Glen Canyon Design Center
>>> Lunatic Fringe Electronics
>>>
>>
>> That seems cool. So, you wrote your own USB and packet stack?
>> Or, it's a system-on-chip?
>>
>> I drive my tractor with my hands on the wheels and the sticks
>> and the levers and the other levers and the feet on the pedals
>> and the other pedals and my rear in the seat, ..., abstraction = 0.
>>
>>
>
> We use the WizNet ethernet chip and the code that they supply. It's
> more than a mac/phy: it handles packets and protocols, including UDP.
>
> The RP2040 has a built-in USB interface. The electrical interface to
> the USBc connector is two resistors. It looks like a COM port to the
> users. What's really slick is that the USB can also run in a mode
> where it looks like a memory stick. To reload the systrem code, we
> boot into memory stick mode and the user then drag-drops a single file
> to update the box: Alice code, Bob code, and the FPGA config.
>
> Tractors are cool. Physical and basic.
>
>
> John Larkin
> Highland Tech Glen Canyon Design Center
> Lunatic Fringe Electronics
>


Trying to figure out "commodity" computing above "embedded"
computing, and to be able to explain it and thusly give an
outline, an abstraction itself, of the connections and the
circuits, has that these days at least for "commodity" general
purpose computing, there's a great "economy of ubiquity" so
that whence there's a model of the bus as almost always PCIe,
then about clock signals and clock drivers and clock interrupts,
about power management and power states, about variously the
ideas, here they're mostly ideas first as I'm not that great
of a computer engineer, about differential pair lines and the
other serial protocols usually enough, then about SATA mostly,
is then mostly about PCIe and DMA and then a miniature fleet
of cores, these being themselves often single or "hyper" threaded,
it's not moving that fast the platform, to basically make for
it a model of computation as it embodies itself.


Here's a bit of a podcast, 44:35 - 49:55 sort of talks about
these things, there are others. "Reading Foundations: denser tensors".



This discussion drifted into operating systems, or schedulers
as they may be or executives plainly, in the context of the
software more generally there's much to be made of "logic
extraction", since, pretty much all sorts of source code
pretty much lives in a world of types and among models of
computation, and so, according to the shape in the logic,
there's much to be made of flexible or "polyglot" parsers,
basically into representations of state and scope, and for
example into making natural diagrams of the flow-graph,
this is just "modern tooling to make sense of complexity",
instead of "ignore the man behind the curtain in the
booming voice of Oz".

[toc] | [prev] | [next] | [standalone]

#742504

On Mon, 30 Mar 2026 09:02:28 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:

>On 03/30/2026 07:44 AM, john larkin wrote:
>> On Sun, 29 Mar 2026 20:54:28 -0700, Ross Finlayson
>> <ross.a.finlayson@gmail.com> wrote:
>>
>>> On 03/29/2026 03:24 PM, john larkin wrote:
>>>> On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
>>>> <ross.a.finlayson@gmail.com> wrote:
>>>>
>>>>> On 03/29/2026 12:39 PM, Don Y wrote:
>>>>>> On 3/29/2026 5:53 AM, Ross Finlayson wrote:
>>>>>>> That seems to speak to "proximity" and "affinity", with regards
>>>>>>> to "coherency", and "mobility". To "move" state, about state & scope
>>>>>>> or the contents of (some of) memory and registers, of a process or task,
>>>>>>> here is described as "re-seating" which is also the usual enough
>>>>>>> idea in programming like C and C++.
>>>>>>
>>>>>> My goal is NOT to disrupt the "programmer's model" for "average
>>>>>> developers".  They should truly be able to think that they are running
>>>>>> on a uniprocessor but without any guarantees as to throughput
>>>>>> (to accommodate sharing the physical processor, communication
>>>>>> overhead, etc.).
>>>>>>
>>>>>> They shouldn't need to know where "they" are executing or that the
>>>>>> resources on which they rely may not be local.
>>>>>>
>>>>>> "Advanced developers" attend to the dynamic reconfiguration of
>>>>>> the system (at runtime).  So, THOSE developers build applications
>>>>>> that are given the ability ("capability") to relocate resources,
>>>>>> kill off tasks, spawn new ones, etc.  Because they, presumably, have
>>>>>> a more detailed understanding of the "System" beyond the scope of
>>>>>> some particular application/task within it.
>>>>>>
>>>>>>> Perhaps the most usual example is pre-emptive multithreading itself,
>>>>>>> about basically the state as a stack, and "process control block"
>>>>>>> and "thread control block" usually enough, about context-switching.
>>>>>>
>>>>>> I support a heterogeneous environment; an object can be migrated
>>>>>> to a different processor *family* at any time (while executing).
>>>>>> You shouldn't care as long as the interface (methods) to the
>>>>>> object remain available (for the capabilities you have been
>>>>>> granted) along with the current state of the object.
>>>>>>
>>>>>> Similarly, the algorithms used to implement those methods (as
>>>>>> well as internal data members) can change dynamically -- as long
>>>>>> as the interface functionality remains immutable.
>>>>>>
>>>>>> For example, I create namespaces -- (name, capability) dictionaries -- for
>>>>>> each process.  If you only need a few registered names (stdin, stdout,
>>>>>> stderr),
>>>>>> the code that implements that is entirely different than the implementation
>>>>>> that tries to manage hundreds of named entries.
>>>>>>
>>>>>> As it should be.  (because "you" are "billed" for the resources that you
>>>>>> use, you'd not want to bear the cost of an implementation that did more
>>>>>> than you needed -- just like you wouldn't develop a standalone device
>>>>>> with more complexity/cost than necessary!)
>>>>>>
>>>>>> If names are insignificant (e.g., akin to file descriptors), then an
>>>>>> implementation might use a single "char" to represent a name, giving
>>>>>> you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc.
>>>>>> Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ...
>>>>>> (do you really *need* names like "Object 1", "Object 2", etc.?)
>>>>>>
>>>>>>> In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
>>>>>>> the idea of the "re-routine" as a model of asychronous concurrency,
>>>>>>> is a little different than the usual idea of a co-routine, which
>>>>>>> is usually enough a fork in the process model, then about signals
>>>>>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events
>>>>>>> and task queues, basically the re-routine never "blocks" and has
>>>>>>> no "yield" nor "async" keywords in the source text, instead any
>>>>>>> call to a re-routine implicitly yields, and then the re-routine
>>>>>>> is run again later, the re-run, where as the re-routine is filled in,
>>>>>>> then then the re-routine adds a penalty of basically n^2 in time
>>>>>>> to be completely non-blocking and where asynchrony is modeled in
>>>>>>> the language as the normal procedural flow-of-control.
>>>>>>
>>>>>> "Yield" is just a hint to the scheduler.  If you have a preemptive
>>>>>> implementation where "time" can be a preemption criteria, then a
>>>>>> task need never "suggest" a good place to relinquish the processor.
>>>>>>
>>>>>> OTOH, if you can only preempt when the task invokes an OS primitive,
>>>>>> then you have to be wary of a developer spinning without ever giving
>>>>>> the system a chance to "interrupt".
>>>>>>
>>>>>>> Then, as that's only in the kernel itself, that n^2 might seem a
>>>>>>> huge penalty, yet, it's actually quite under that, since as the
>>>>>>> re-routine its data (in a stack) is filled in, then most of its
>>>>>>> routine is cache hits, the "memoized" calls to the re-routine.
>>>>>>>
>>>>>>> About the allocator, then this design concept basically is for
>>>>>>> making use of virtual memory, to be able to "re-seat" the memory
>>>>>>> of a process without changing a process' view of the memory.
>>>>>>
>>>>>> Of course.  But, with VMM, you can do so much more:
>>>>>> - CoW semantics
>>>>>> - DSM
>>>>>> - remapping "defective" memory
>>>>>> - releasing memory that will NEVER be revisited
>>>>>> - universal call by value (for large arguments)
>>>>>> etc.   None of these things need impact the developer.
>>>>>>
>>>>>>> This can help avoid both syscalls and memory fragmentation,
>>>>>>> since memory paging basically is performed by the user-space
>>>>>>> process in its time instead of by the kernel. This has the
>>>>>>> usual guarantees of process memory that it's to be visible only
>>>>>>> to the process itself unless explicitly shared, that then being
>>>>>>> treated as a usual sort of shared resource in the distributed sense.
>>>>>>>
>>>>>>> The syscalls by a process essentially yield (the process yields
>>>>>>> to the scheduler), about ideas like round-robin and fairness
>>>>>>> and anti-starvation and incremental-progress in the scheduler,
>>>>>>> while it's so that until a process gets any other signal and
>>>>>>> only touches its own memory that's non-yielding, then about
>>>>>>> the machinery of pre-emptive multithreading or context-switch
>>>>>>> and as with regards to hyper-threading or the interleaved contexts
>>>>>>> on the double-pipeline CPUs, the idea being that context-switching
>>>>>>> is along the lines of basically a periodic signal interrupt.
>>>>>>
>>>>>> But you have to guard against "non-cooperative" (and even HOSTILE!)
>>>>>> actors who may wish to compromise performance by monopolizing resources
>>>>>> (of which the CPU is but one).
>>>>>>
>>>>>> Using resource ledgers lets you constrain an application (process)
>>>>>> to a subset of the available resources.  Putting runtime constraints
>>>>>> on memory, time, etc. lets you remove a "bad actor" from the set
>>>>>> of processes eligible to run.  A persistent store lets you remember
>>>>>> this decision so you don't "readmit" the process at some future date!
>>>>>>
>>>>>>> Notions of "Orange Book" and "mandatory access control" then
>>>>>>> are considered "more than good ideas" with regards to the allocator
>>>>>>> and scheduler of resources in computation.
>>>>>>
>>>>>> Capabilities implicitly limit the actions that can be performed (i.e.,
>>>>>> methods that can be invoked) on an object.  E.g., I can let you
>>>>>> LOCK a door but never UNLOCK it.  Or, let you open a door EXACTLY
>>>>>> once, and never again!
>>>>>>
>>>>>> How you refine your "permissions" is something that belongs in the
>>>>>> objects themselves -- not layered onto a "filesystem" as an afterthought.
>>>>>>
>>>>>
>>>>>
>>>>> Hey, thanks for writing. Since all we know about each other
>>>>> are these brief exchanges, filling in some detail helps a lot
>>>>> to understand, or rather, get an idea, of an estimate of the
>>>>> depth of the comprehension of the whole machine stack.
>>>>>
>>>>> The idea of a kernel or operating system (executive, scheduler,
>>>>> ..., interactive "operating system") for "commodity" architectures
>>>>> these days is that it's pretty ubiquitous the various chips'
>>>>> architectures, then that PCIe is on everything PC, then about
>>>>> usually enough USB, then about the NIC and USB root, those are
>>>>> pretty much ubiquitously PCIe devices, or as after UEFI and ACPI
>>>>> and the SMI or as about DeviceTree, ..., it's ubiquitous,
>>>>> after "economy of scale" a simple enough "economy of ubiquity".
>>>>>
>>>>> So, the chips are almost all 64-bit their native word width, though
>>>>> agreeably sometimes it's 128, and they have various vector or SIMD
>>>>> instructions, then as with regards to fitting two operands in a word,
>>>>> the SWAR approach, about vectorizing the scalars, and word and
>>>>> double-word and word and half-word.
>>>>>
>>>>> Then, here mostly the consideration is the "head-less" or "HID-less",
>>>>> there's no human interface device involved in server runtime images
>>>>> for things like running services or usually enough "boxes" or "nodes".
>>>>>
>>>>>
>>>>> Then, for compiling existing sources, it seems the easiest way to
>>>>> do that is to implement profiles of POSIX, or posix base and pthreads.
>>>>> That then of course is much the traditional UNIX account of where
>>>>> "everything is a file", though, the operating system itself doesn't
>>>>> need to be implemented that way, just surface the usual objects as
>>>>> they are as primitives, and mostly as having file handles.
>>>>> (If the sources compile and run the same behavior some won't know/care.)
>>>>>
>>>>> Then, objects, according to "naming and directory interface" usually
>>>>> enough, Orange Book for example defines granular access controls,
>>>>> so, including all things like files.
>>>>>
>>>>>
>>>>> About quota and limits and the like, and about the perceived value
>>>>> of pre-emptive scheduling to avoid "hogging", or thrashing, here
>>>>> is an account of basically unmaskable uncatchable interrupts that
>>>>> have as a signal handler the operating system code on the core
>>>>> that results making the task yield, then necessarily enough using
>>>>> the usually context-switch machinery to pause it and restart it.
>>>>> Most code eventually touches system calls, and if there's a spare
>>>>> core it might actually be the idea to let the compute-intensive
>>>>> routine employ the entire core.
>>>>>
>>>>> The many-core architectures of these days, even fifteen or twenty
>>>>> years ago with "AMD Bulldozer and 8 cores" and the like, these
>>>>> days usual PC or server chips have scores of cores, ..., often
>>>>> for example with the idea of running a giant hypervisor then
>>>>> as many virts, ..., like a Kubernetes cluster for example, ...,
>>>>> or simply a ton of virts, ..., these days a single board is
>>>>> as a model of a distributed system internal to itself.
>>>>>
>>>>>
>>>>> The idea for allocation and sharing that "fairness is a matter
>>>>> of mechanism, not policy", is for the usual ideas of "thoughput"
>>>>> and "transput" as Finkel put it in "An Operating Systems Vade Mecum",
>>>>> about I/O and queues, and limits.
>>>>>
>>>>>
>>>>> "Interrupts" are the events, "coherent cache lines" the units of
>>>>> serialization of memory, DMA is the bulk transfer medium in protocol,
>>>>> a byte is the smallest addressable memory unit, these are mostly
>>>>> the ordering guarantees, all else "undefined".
>>>>>
>>>>> Proximity, affinity, coherency, mobility, ....
>>>>>
>>>>
>>>> We build electronics. Our new PoE instrument line uses an RP2040
>>>> dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any
>>>> quantity.
>>>>
>>>> We call the two CPUs (and the two ends of the box) Alice and Bob.
>>>>
>>>> Alice does the ethernet and usb i/o, command parsing, calibrations,
>>>> all that slow floating-point management. Bob does the realtime i/o,
>>>> fixed-point, directly or through an FPGA.
>>>>
>>>> All programmed in bare-metal c with no OS. Abstraction=0.
>>>>
>>>> Seems to work.
>>>>
>>>>
>>>> John Larkin
>>>> Highland Tech Glen Canyon Design Center
>>>> Lunatic Fringe Electronics
>>>>
>>>
>>> That seems cool. So, you wrote your own USB and packet stack?
>>> Or, it's a system-on-chip?
>>>
>>> I drive my tractor with my hands on the wheels and the sticks
>>> and the levers and the other levers and the feet on the pedals
>>> and the other pedals and my rear in the seat, ..., abstraction = 0.
>>>
>>>
>>
>> We use the WizNet ethernet chip and the code that they supply. It's
>> more than a mac/phy: it handles packets and protocols, including UDP.
>>
>> The RP2040 has a built-in USB interface. The electrical interface to
>> the USBc connector is two resistors. It looks like a COM port to the
>> users. What's really slick is that the USB can also run in a mode
>> where it looks like a memory stick. To reload the systrem code, we
>> boot into memory stick mode and the user then drag-drops a single file
>> to update the box: Alice code, Bob code, and the FPGA config.
>>
>> Tractors are cool. Physical and basic.
>>
>>
>> John Larkin
>> Highland Tech Glen Canyon Design Center
>> Lunatic Fringe Electronics
>>
>
>
>Trying to figure out "commodity" computing above "embedded"
>computing, and to be able to explain it and thusly give an
>outline, an abstraction itself, of the connections and the
>circuits, has that these days at least for "commodity" general
>purpose computing, there's a great "economy of ubiquity" so
>that whence there's a model of the bus as almost always PCIe,
>then about clock signals and clock drivers and clock interrupts,
>about power management and power states, about variously the
>ideas, here they're mostly ideas first as I'm not that great
>of a computer engineer, about differential pair lines and the
>other serial protocols usually enough, then about SATA mostly,
>is then mostly about PCIe and DMA and then a miniature fleet
>of cores, these being themselves often single or "hyper" threaded,
>it's not moving that fast the platform, to basically make for
>it a model of computation as it embodies itself.
>
>
>Here's a bit of a podcast, 44:35 - 49:55 sort of talks about
>these things, there are others. "Reading Foundations: denser tensors".
>
>
>
>This discussion drifted into operating systems, or schedulers
>as they may be or executives plainly, in the context of the
>software more generally there's much to be made of "logic
>extraction", since, pretty much all sorts of source code
>pretty much lives in a world of types and among models of
>computation, and so, according to the shape in the logic,
>there's much to be made of flexible or "polyglot" parsers,
>basically into representations of state and scope, and for
>example into making natural diagrams of the flow-graph,
>this is just "modern tooling to make sense of complexity",
>instead of "ignore the man behind the curtain in the
>booming voice of Oz".
>
>

Absolutely.

John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics

[toc] | [prev] | [next] | [standalone]

#742467

On 3/29/2026 2:29 PM, Ross Finlayson wrote:
> Hey, thanks for writing. Since all we know about each other
> are these brief exchanges, filling in some detail helps a lot
> to understand, or rather, get an idea, of an estimate of the
> depth of the comprehension of the whole machine stack.

Perhaps you should relate the types of applications you've been
tasked with in the past -- or, those you hope to target in the
future.  Frankly, your comments read like word-salad -- failing
to appreciate or interact with my prior comments and, instead,
babbling bits and pieces you've read somewhere instead of reflecting
a genuine understanding of the issue(s).

E.g., there's no *why* behind your statements.  No "hope" in their
proposals.

Experience provides both of these and, without it, future
endeavours tend to fail -- miserably.  (if you don't learn...)

[toc] | [prev] | [next] | [standalone]

#742469

On 03/29/2026 05:09 PM, Don Y wrote:
> On 3/29/2026 2:29 PM, Ross Finlayson wrote:
>> Hey, thanks for writing. Since all we know about each other
>> are these brief exchanges, filling in some detail helps a lot
>> to understand, or rather, get an idea, of an estimate of the
>> depth of the comprehension of the whole machine stack.
>
> Perhaps you should relate the types of applications you've been
> tasked with in the past -- or, those you hope to target in the
> future.  Frankly, your comments read like word-salad -- failing
> to appreciate or interact with my prior comments and, instead,
> babbling bits and pieces you've read somewhere instead of reflecting
> a genuine understanding of the issue(s).
>
> E.g., there's no *why* behind your statements.  No "hope" in their
> proposals.
>
> Experience provides both of these and, without it, future
> endeavours tend to fail -- miserably.  (if you don't learn...)

Heh. Let's say I've worked in distributed systems for a few decades.

Here's how I'd begin to frame it. Let's say we all know "Turing tapes"
from the theory. Everybody knows a mental model of a tape, with
discrete differences in it or values with ordinal offsets,
a tape and read-head and a write-head, the the idea that
that's a "model of computation". That's pretty obvious to anybody,
and everybody knows that in "the formal" that all kinds of results
are said to follow from it, while at the same time, nobody thinks
that way because it's just cumbersome or not particularly apt.
Everybody has known that since they have one at the beach, a great
computer, it's a giant scratch-pad and any way one cares to mark it with
stick-marks and pebbles, and rules, is just as good a model of
computation. Now, say we've all heard of "Towers of Hanoi" and
otherwise, for example, how a stack machine is "equivalent" or
"equi-interpretable" to other "models of computation", point being
that results in one are the same results eventually as the other.

Then, say we've all heard of something like Knuth's "Mix",
an abstract of a virtual machine.

So, today we all know about, for example, the instruction pointer
and the stack pointer, so "von Neumann", then according to the
architecture the "instruction set architecture", that there's
mostly a model of synchronous routine, then though as with regards
to "interrupt service routine", a model of asynchrony in the
synchronous ("blocking").

Then, also we know about that basically since when DMA direct memory
access made for vector or scatter/gather I/O, that instead of a
model of asynchrony in the synchronous, now it's a model of synchrony
in the asynchronous ("non-blocking"), sort of like any other distributed
system.


So, what inspires my outline is that the model of computation,
here "actors on the bus", should more than less be the model
of computation, then that formal statements about it, directly apply,
to the implementation.

So, that's "why".


Mostly I thought of these things myself, because nobody already
bothered to point out that de facto the commodity hardware is
best treated as a model of a self-contained distributed system.


(In case you're wondering then also my approach to Mathematics
and Physics in Foundations has been called "Word Salad", though
I prefer to think of it as a nutritious enough "Word Soup",
after "Alphabet Soup", which is full of letters even if you'd
rather toss it than bother to make words in the spoon, i.e.,
I'll aver that it's coming from and going to a good place,
then those rambles or "the bot panel" from the "Critix/DeepOs"
help provide some context.)


I don't disagree with your previous comments, I understand
from "generous reading" that accounts of reliability and
robustness and flexibility and function and so on are usual,
and sensible.

"Equilibrium is always both at equilibrium and seeking equilibrium."

[toc] | [prev] | [next] | [standalone]

#742383

Ross Finlayson <Ross.A.Finlayson@GMail.com> wrote:
|----------------------------------------------------------------|
|"The "since" and "until" are often among the most suprising     |
|or unintuitive keywords represented in language, since          |
|they're as of temporal modality, vis-a-vis "until" and "while"."|
|----------------------------------------------------------------|

A then supervisor had drafted a proposal in English to be read by
persons who do not natively read English. He had written "Since" for
"Because". I have proposed replacing "Since" by "Because" but he
insists on using "Since" for "Because" while professing that they are
sufficiently skilled at English.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)

[toc] | [prev] | [next] | [standalone]

#742339

COBOL is being likened to the asbestos cleanup.

See the article:

https://www.wired.com/story/cobol-is-the-asbestos-of-programming-languages/

-- 
For full context, visit https://www.electrondepot.com/electrodesign/software-situation-4399817-.htm

[toc] | [prev] | [next] | [standalone]

#742367

On 3/26/26 5:51 PM, Ross Finlayson wrote:
> On 03/26/2026 01:29 PM, Sergey Kubushyn wrote:
>> john larkin <jl@glen--canyon.com> wrote:
>>
>> Although 99.9999% of all "We have the programmers" SPAM offers web
>> programming, there is still good old firmware and embedded 
>> development. It
>> is in just remaining 0.0001% but it is not a Java/dotnet/golang/etc junk
>> coding area and still requires skills/experience/knowledge.
>>
>> All, sorry for an expletive, Facebook and such "software" is a huge 
>> stinking
>> heap of manure that can (and should) be replaced with automatic junk
>> generation so that entire legion of so-called "programmers" will be out
>> looking for some kind of meaninful and productive job.
>>
>> However, it will still take some people with the brains to make that
>> automation happen.
>>
>> Isaac Asimov, "Profession" (1957) -- highly recommended reading.
>>

Serious hint to anyone thinking about a career in software: Make sure to 
develop a solid understanding of at least digital hardware. Build, 
experiment with micro controller eval boards (they are cheap), learn how 
to use a logic analyzer and an oscilloscope. That will hugely increase 
your job security or your self-employed income prospects.


>>
>>> https://www.eetimes.com/software-engineering-has-been-commoditized-and-automated-whats-next/ 
>>>
>>>
>>>
>>> John Larkin
>>> Highland Tech Glen Canyon Design Center
>>> Lunatic Fringe Electronics
>>
>> ---
>> ******************************************************************
>> *  KSI@home    KOI8 Net  < >  The impossible we do immediately.  *
>> *  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
>> ******************************************************************
>>
> 
> There's mostly nothing wrong with all the good old software.
> 

I am still doing all my book-keeping on 30+ year old software, MS-Works. 
It still ... just works. Even on a Linux system (using WINE).

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#742371

On 3/27/2026 10:35 AM, Joerg wrote:
> Serious hint to anyone thinking about a career in software: Make sure to 
> develop a solid understanding of at least digital hardware. Build, experiment 
> with micro controller eval boards (they are cheap), learn how to use a logic 
> analyzer and an oscilloscope. That will hugely increase your job security or 
> your self-employed income prospects.

The reverse is also true for folks looking for careers in hardware design.
If you don't know how the software will interface with "your" hardware,
the answer is likely:  "poorly".

And, to all, "coding" isn't software design in much the same way
assembling a prototype isn't hardware design.

[toc] | [prev] | [next] | [standalone]

#742375

On 3/27/26 11:27 AM, Don Y wrote:
> On 3/27/2026 10:35 AM, Joerg wrote:
>> Serious hint to anyone thinking about a career in software: Make sure 
>> to develop a solid understanding of at least digital hardware. Build, 
>> experiment with micro controller eval boards (they are cheap), learn 
>> how to use a logic analyzer and an oscilloscope. That will hugely 
>> increase your job security or your self-employed income prospects.
> 
> The reverse is also true for folks looking for careers in hardware design.
> If you don't know how the software will interface with "your" hardware,
> the answer is likely:  "poorly".
> 
> And, to all, "coding" isn't software design in much the same way
> assembling a prototype isn't hardware design.


... and comment lines in the source code do _not_ constitute 
"documentation".

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#742384

On 3/27/2026 11:46 AM, Joerg wrote:
> On 3/27/26 11:27 AM, Don Y wrote:
>> On 3/27/2026 10:35 AM, Joerg wrote:
>>> Serious hint to anyone thinking about a career in software: Make sure to 
>>> develop a solid understanding of at least digital hardware. Build, 
>>> experiment with micro controller eval boards (they are cheap), learn how to 
>>> use a logic analyzer and an oscilloscope. That will hugely increase your job 
>>> security or your self-employed income prospects.
>>
>> The reverse is also true for folks looking for careers in hardware design.
>> If you don't know how the software will interface with "your" hardware,
>> the answer is likely:  "poorly".
>>
>> And, to all, "coding" isn't software design in much the same way
>> assembling a prototype isn't hardware design.
> 
> ... and comment lines in the source code do _not_ constitute "documentation".

Eschew comments as they are yet another thing that can get out-of-sync
with the code.  People are lazy; given the choice of reading the
comments and the code, the comments are likely easier and exist at
a higher level of abstraction (with which one would have to infuse
the code).  But, the *code* is what the compiler reads!

Comments should describe the *design* and the skillset of the
developer should be able to suss-out the implementation and
its compliance with said design.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | sci.electronics.design

csiph-web