[Openmcl-devel] Bug report: CCL crash on M1 command line

[dbm at refined-audiometrics.com]

This problem is probably not CCL’s nor SBCL’s alone. Our computer hardware changes faster than our overly complicated and sclerotic IDE’s can adapt. It makes me ponder whether or not we have the correct approach.

I’ve spent a huge amount of time exploring variants of Hewitt’s Actors. Specifically, my latest forays utilize Leggo-block style Hewitt Actors which are coded as purely functional code with transactional behavior - all of the message SENDs and BECOMEs are staged for execution upon successful exit from an Actor body. Failing that successful exit, it becomes as though the errant message were never delivered.

This supports a fully parallel concurrent model of programming with no overt locks and threads. Instead, a thread pool of executives feed from a common mailbox FIFO queue, each one dispatching a message to an Actor for execution. MPU coherence is maintained using CAS, with retry, at the single point of mutation in the system - the Actor BEHAVIOR pointer. (In actual fact, the communal FIFO message queue also has implicit locks.)

So while each Actor code body is FPL, there is still global mutation in the Actor behavior pointers. But this sole mutation is strongly controlled and coherent.

My experience has shown that Transactional Hewitt Actors can support a very rapid, very high performance, style of programming. No single component produces mental overload. But it does require a discipline with Lisp to ensure that the code remains functionally pure to the outside world - i.e., you can use assignment and mutation, but only when it is not visible to anyone else. Otherwise, we must make copies of data to be changed, and perform a BECOME, which is a controlled mutation.

I launched on this new effort about two years ago, after finding this resource, from one of Hewitt’s old collaborators: http://www.dalnefre.com/wp/

- DM



> On Feb 26, 2023, at 11:30, Ron Garret <ron at flownet.com> wrote:
> 
> 
> 
>> On Feb 26, 2023, at 8:23 AM, Paul Krueger <plkrueger at comcast.net> wrote:
>> 
>> Just looking at the error message again, this part “(ThreadContextRegisterState.cpp:947 arm_fpr_state_from_x86_state)”, seems to make it clear that problem involves both X86 and arm states. Doesn’t that make it overwhelmingly likely that this is associated with Rosetta?
> 
> Yes.  The data point provided by Shannon supports this too.  That person reported the problem manifests on M1 only.
> 
>> Judging from other things I’ve read about Rosetta, my guess is that Apple will only support it for another year or two; three max. As near as I can tell from on-line searches, SBCL will run natively on ARM/M1 today. So I’m hoping for either CCL to be ported to M1 or for some better IDE to pop up for SBCL. I’ve even tinkered around a bit with trying to cobble together an IDE for SBCL, but haven’t had enough time to take it very far and it’s a LONG way from being even a workable IDE, much less one as capable as the CCL IDE. Porting the CCL IDE to SBCL also looks like a daunting task. Sigh ...
> 
> Yes, I agree on all counts, including the closing sentiment.
> 
> rg
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20230226/24920673/attachment.htm>