Hello!

[Blaine Garst]

>> But what about my suspicion?  Seems like “swap thread registers system
>> call” will alone be more expensive in both time (I avoid the need to
>> do so) and space (since there are no nano-kernel threads waiting for
>> activation).  Anybody have my same hunch?
> 
> Overall, I think that current kernels do what's architecturally possible
> regarding IPC.

Sorry, but I disagree, because the software architecture is wrong.

Change the architecture and more speed is possible.

> So I'd assume there's not much to squeeze out further.
> And yes, it's not only about the good case but also for all the other
> cases where more handling is needed and thus checks on the way.

Umm, I was suggesting that one has known-to-need-no-checks
entries and known-to-need-checks entries.

For Apple’s generational conservative GC we overloaded the assignment
operator to call a helper function.  At runtime we page mapped in
the appropriate helper function, and used a single instruction call.

For non-GC the implementation was “store; return”.

So bloody fast we couldn’t measure its cost.

> I'd
> suggest to look at the existing kernels to see how they're doing.
> 
>> "After disastrous results in the early 90's, the microkernel approach
>> now seems to be promising, although it still bears a lot of research
>> risks.”
>> 
>> I’m curious as to what “results” were being referenced.
> 
> 1st-gen kernels, i.e. Mach.

I was hired at NeXT on the premise that Mach’s IPC wasn’t fast enough!

>> 
>> Not that its multicore (yet), but has anyone in this community been
>> exploring putting L4 on a Raspberry Pi?
> 
> Fiasco/L4Re is also running on the Raspberry.

Thanks - I’ll peruse its licensing agreement!

Blaine