On 3/8/2022 5:15 PM, MitchAlsup wrote:
> On Tuesday, March 8, 2022 at 3:54:41 PM UTC-6, BGB wrote:
>> On 3/7/2022 7:24 AM, Marcus wrote:
>>> On 2022-03-05, MitchAlsup wrote:
>>
>> For bonus points, could also be cool to see a few features from Verilog,
>> such as exact bit-width values the ability to compose and decompose bit
>> vectors, ...
> <
> Where bit widths are essentially unlimited.....

Granted.

I would assume this to be implemented on top of something like a
"_BitInt(n)" type, where the underlying storage picks one of the basic
machine-supported types, or uses a large variable-size number for large
types.

There might be an implementation limit, say, 64k bits or similar, but we
can assume for sake of argument that it is large enough to be mostly
ignored.

Unlike _BitInt, the compiler would be expected to remember the exact
number of bits the type was declared as, and (like in Verilator) enforce
width-checks and similar for exact-width integer types.

>>
>> Someone could maybe also get extra wacky and borrow concepts like
>> 'always' and 'initial' blocks.
>>
>> always(cc) {
>> //triggers whenever cc becomes true
>> //does not depend on sequential control flow
>> }
>>
>> initial {
>> //block runs at program start-up (1)
>> }
>>
>> *1: Program startup sequence being:
>> Load / Zero ".bss" / ...
>> Initialize language runtime stuff;
>> Initialize all the globals which require dynamic init;
>> Run any 'initial' blocks in the program;
>> Transfer control to "main()".
>>
> Good ideas.
>>
>> I guess one other question could be if one could add asynchronous and
>> event-driven abstractions to a language which play nicer with multiple
>> cores than do more traditional approaches to multithreading (eg:
>> explicit thread creation).
>>
>> Big issues are likely to be synchronization and efficiently moving data
>> between threads (mutex driven synchronization and shared memory having a
>> few obvious drawbacks).
>>
> <---------------------------------------------------------------------------------------------------------------
>> One possibility could be to have a class of variables which appear sort
>> of like globals (from a given piece of code), but are in effect local
>> state to that particular "event" (in some sense, sorta like parameters
>> in GLSL). Spawning a new event from within a prior event would in effect
>> copy any overlapping state into the new event (if no new event is
>> spawned, this state simply disappears; state which is not copied is
>> discarded, and any new event state is zeroed).
> <
> How is this different from ThreadLocalStore ?
> <----------------------------------------------------------------------------------------------------------------

TLS is attached to a specific thread of execution, rather than to an
event. Multiple events may trigger within the same logical thread, but
will each have their own state, which would follow along with the path
in which events are spawned.

These would be semantically distinct from either lexical or dynamic
scoping, in that they follow control flow (like dynamic bindings), but
also function according to capture (more like lexical bindings within
lambdas).

One could also have dynamic variables though, and observe that when one
has these, they may become (in effect) semantically equivalent to a
superset of TLS variables.

The event-scoped variables would become equivalent to TLS though, if one
assumes that event spawning is semantically equivalent for forking a
thread, and that the lifetime of such a thread is equivalent to that of
the event (or, in effect the event mechanism is itself implemented using
short-lived threads).

One other difference is that traditionally, each thread (or green
thread) is given its own stack, whereas an event would not necessarily
have its own stack (but could inherit a stack from the parent thread,
which is given back to the parent once the event finishes or when
control transfers to a new event).

So, depends a lot on how things are implemented (and whether it is
cheaper to spawn and destroy micro-threads or to move over to an ABI
based around continuation-passing-style or similar).

>>
>>
>> Any large shared structures remain as an issue though, since these would
>> require keeping the state consistent.
>>
>> One idea could be that we don't so much "call" into synchronized methods
>> directly, but rather that they queue up and put the caller on standby.
> <
> This is like the message facility I recently put into My 66000.
> <

This is also a feature one of my older languages had, but was dropped
when I moved its descendant over to a more simplified (and more Java
like) execution model.

This was along with moving the scoping model from being dynamically
mutable, over to a statically determined scope (runtime mutable scope is
either slow, or the complexity can become a little nightmarish).

>> When the method call is handled (possibly in a different thread from the
>> caller), it then wakes the caller, which may resume execution in its own
>> thread.
> <
> Different thread, different address space, under a different Guest OS.

This is possible.

I was imagining within a single address space, rather than necessarily a
generalized RPC mechanism. Granted, depending on how it is implemented,
it isn't too far of a stretch to generalize this to an RPC.

It would mostly involve a mechanism to add a request from the current
request to a queue associated with the target and (if needed) to direct
attention to this target.

It is likely in this case that the current thread would stop execution
and transfer control to another thread, being "woken up" again once the
target call completes.

How to best pull this off at the ABI level is "to be determined", one
likely option is that it fallows the normal ABI initially, but that the
function or method call is actually to a wrapper (which implements the
mechanism in question). This being (likely) cheaper than a more complex
option, such as compiling the program to be built in terms of
continuation-passing-style (CPS).

Granted, if I felt there was a strong use-case, I could probably define
a CPS based ABI. Main drawback is that a CPS ABI would almost invariably
perform worse than a call-stack ABI, since one effectively allocates and
frees call frames rather than adjusting the stack pointer.

One open question then, would be rather one would use a separate IDL (as
in DCOM or CORBA), or make use of the language-level types and
declarations instead.

Typically, separate address space does require an ability to serialize
and de-serialize data (and identify objects by handle rather than by
address), which in turn requires type metadata and reflection.

This is doable, though (indirectly) would mostly leave traditional C out
of the RPC party.

Another simplifying assumption would be to assume using a dynamic
type-system across the RPC interface (which may map to/from the static
typesystem on either end).

>>
>> Or, in effect, an RPC like abstraction is hidden inside what appears
>> like a normal method call. Potentially, getters and setters could use a
>> similar abstraction.
>>
>> In contrast, an asynchronous method call would in effect detach the
>> caller from the callee, which may continue on independent of the other.
>> Within a synchronized object, both cases would have the behavior of
>> forcing sequential execution.
> <
> This is the Send Message end of things.
>>
>> Maybe also have async blocks which could have a condition for when they
>> trigger:
>> async(cc) { ... }
>>
>> But, which differs slightly in that control needs to reach the block
>> before it is created, and that its execution is one-off (once 'cc' is
>> true, the block executes once, or at least once for each time control
>> passes over the declaration of the async block).
>>
>> Likely, state capture for an async block would be similar to that for a
>> lambda. It also seems likely also that the 'cc' mechanism would be
>> implemented similar to a constraint variable (modifying an input
>> triggers re-computation, rather than endlessly re-evaluating the
>> predicate to see if it has changed since the last time it was checked).
>>
>>
>> Granted, all of this would add a bit of complexity to a compiler.
>>
> One concept I have been thinking about recently is a virtual core::
> What would happen to applications and OSs if they could pretend
> that there was an essentially unlimited number of cores (say more
> than 1024 as a minimum but scalable at least to the 16M cores level.)
> And instead of cores looking for work, work turns around and looks
> for cores......

So, sorta like hardware level preemptive-multitasking?...

>> ...