Groups | Search | Server Info | Login | Register

Groups > sci.electronics.design > #742485

Re: software situation

Show all headers | View raw

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

Back to sci.electronics.design | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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

csiph-web