My impression from Brooks was that his Common Lisp doesn't separate code from data, either.  He specifically said that self-modifying code was the issue for him.

Just in case it's helpful, I'm recording the message below in this issue.  I ran into Prof. Rodney Brooks recently, and we talked about his Common Lisp implementation, which ran into the same issue on the M1 as MIT Scheme has hit.  He sent me this message, which gives a detailed explanation of how he solved this problem in his implementation:

> My lisp image is pretty much independent of the operating system so
> there is a C program, the coldloader, that handles all of that side.
> There is a coldload file that has multiple code segments and data
> segments and the coldloader load that all into memory at the start
> and then code there gets jumped into, and now it is running lisp.
> When lisp needs to communicate in any way with the operating system
> (e.g., to read or write a file, or print to the TTY, or talk to
> Xwindows, it does call backs into C code in the coldloader to handle
> it.
>
> Here is all the C code for the special cases for M1 silicon, that
> comes directly from my coldloader.
>
> Note that the type "addrint" is really uint64_t for the Mac M1 in 64
> bit mode (the code for the coldloader runs on many different
> architectures, endianness, and size of memory pointers, so it is
> conditionalized and configured with typedefs).
>
> Header files
>
> #ifdef NEEDS_MAC_JIT
> #include <libkern/OSCacheControl.h>
> #include <pthread.h>
> #endif
>
>
> And this is the code that loads code and data segments into memory
> before being jumped into--segments 0 and 1 are both code segments,
> though they can also get read as data if the inspector wants to
> display the code bits in memory.
>
>
> #ifndef NEEDS_MAC_JIT
>     if (staticid==i)
>       segaddress[i] = vregbytes+Lalloc(segdesired[i]+vregbytes);
>     else segaddress[i] = Lalloc(segdesired[i]);
>     fread((char *)segaddress[i], seglength[i], 1, loadfile);
> #endif
> #ifdef NEEDS_MAC_JIT
>     if (i<2) { /* this is a code segment */
>       if (i==0) pthread_jit_write_protect_np(0);
>       segaddress[i] = (addrint)mmap(0, segdesired[i],
>     PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_JIT,
>     -1, 0);
>       if (0<seglength[i]) {
> /* fread interacts badly with mmap for some reason, so we roll our own fread here */
> place = (char *)segaddress[i];
> for(jj=0;jj<seglength[i];jj++,place++) *place=255&fgetc(loadfile);}}
>     else {
>       segaddress[i] = Lalloc(segdesired[i]);
>       fread((char *)segaddress[i], seglength[i], 1, loadfile);}
> #endif
>   }
>   fclose(loadfile);
> #ifndef NEEDS_MAC_JIT
>   /* make the code segments exectuable, in case they are not by default.
>      this makes the assumption that 0=pure code and 1=usercode. */
>   mprotect((void *)segaddress[0], segdesired[0], PROT_READ|PROT_WRITE|PROT_EXEC);
>   mprotect((void *)segaddress[1], segdesired[1], PROT_READ|PROT_WRITE|PROT_EXEC);
> #endif
> #ifdef NEEDS_MAC_JIT
>   pthread_jit_write_protect_np(1);
>   sys_icache_invalidate((void *)segaddress[0], seglength[0]);
>   if (0<seglength[1]) sys_icache_invalidate((void *)segaddress[1], seglength[1]);
> #endif
>
> Now here is the code that the compiler or the lisp code loader need
> to use to copy code bytes into memory and then let them be
> executable (note that I don't know if you can run an M1 mac in 32
> bit mode, but I just put that here in case...):
>
>
> // with JIT we can only run this original C proram when we are writing any instructions to memory
> // so faslin and compile in place need to access write_jit_code_vector to do their dirty work.
> // so far this is only for a Macintosh JIT.
>
> #ifdef _L_64BIT
> #define byteshifter (3)
> #endif
> #ifdef _L_32BiT
> #define byteshifter (2)
> #endif
>
> addrint write_jit_code_vector (addrint *cvect, addrint pointercount, addrint *fromplace, addrint header) {
> #ifdef NEEDS_MAC_JIT
>   int ii;
>   pthread_jit_write_protect_np(0);
>   *(cvect-1) = header; // the header wasn't put there in %make-code for this machine
>   for(ii=0;ii<pointercount;ii++) cvect[ii]=fromplace[ii];
>   pthread_jit_write_protect_np(1);
>   sys_icache_invalidate((void *)cvect, pointercount<<byteshifter);
> #endif
>   return 0;}
>
> --Rod

Another possible approach is to use a memory region that has two mappings at different addresses: one with W and one with X. GNU libffcall uses this, see https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=trampoline/trampoline.c;h=fdcbcd456aeb20b87b846a8d9f930ce2781a1195;hb=HEAD (search for EXECUTABLE_VIA_MMAP_FILE_SHARED), and it works even on HardenedBSD and macOS.

The drawbacks are:
- This memory is not anonymous; it must be taken from a file.
- Some address management is needed, because in some places you want to address the memory through the W mapping and in other places through the X mapping.

Apple has posted a method for supporting JITs on Apple M-1 machines.  Basically one must allocate a segment with mmap using the MAP_JIT option.  Then the function pthread_jit_write_protect_np must be called with a boolean argument:  false turns off write-protection and enables execution, and true turns turns on write-protection and disables execution.

I hope this is helpful.