You can disable the garbage collector with without-gcing or gc-off. To manually allocate and deallocate you need to go beyond SBCL, at least as far as I know; you can call malloc and free directly if you want (via the FFI) or you can write your own allocator using the low-level memory access facility.
Hiding in the low-level code in the FFI and in SBCL itself are "system area pointers:"
Finally, inline assembly. This is the least documented of the three features you mentioned, but here is an example of how to do it with the VOP facility:
Unfortunately, all of the above are extremely hard to use due to the lack of good tooling. Manual memory management is possible, but going from a pointer to a block of memory to a Lisp object is not at all straightforward (it is possible with a lot of low-level hacking using the sb-vm and sb-sys packages). You can define VOPs, but it involves a lot of steps; you are probably better off just using the FFI, but debugging across the FFI boundary is hard, and the FFI imposes a performance hit that might outweigh the benefit of your assembly language code.
Like I said, the problem here is tooling. I suspect that there is a lack of demand for these things among SBCL and CMUCL users, and in the Lisp community in general.
Ahh, yeah, hmm. That's not exactly what I meant. A language for writing an OS on a conventional CPU would need to allow straightforward control of the memory for its own data structures, not just foreign memory. In lieu of that, I suppose you could turn just off the GC when doing time-sensitive things (like responding to interrupts).
That's sort of besides the point, though, because the main problem with SBCL and other CL implementations is that they are written for use in userspace programs and depend on having access to kernel system calls and library functions like malloc(). So if you were to write a kernel in CL, you'd first have to write an implementation for CL that can run on bare metal. At that point, you might as well just implement a different Lisp dialect that only has the features you need in order to write the kernel.
Comments
Those features are mostly in SBCL's FFI, which is (somewhat) documented here:
http://www.sbcl.org/manual/#Foreign-Function-Interface
You can disable the garbage collector with without-gcing or gc-off. To manually allocate and deallocate you need to go beyond SBCL, at least as far as I know; you can call malloc and free directly if you want (via the FFI) or you can write your own allocator using the low-level memory access facility.
Hiding in the low-level code in the FFI and in SBCL itself are "system area pointers:"
http://www.sbcl.org/manual/#index-int_002dsap
Finally, inline assembly. This is the least documented of the three features you mentioned, but here is an example of how to do it with the VOP facility:
http://pvk.ca/Blog/Lisp/hacking_SSE_intrinsics-part_1.html
Unfortunately, all of the above are extremely hard to use due to the lack of good tooling. Manual memory management is possible, but going from a pointer to a block of memory to a Lisp object is not at all straightforward (it is possible with a lot of low-level hacking using the sb-vm and sb-sys packages). You can define VOPs, but it involves a lot of steps; you are probably better off just using the FFI, but debugging across the FFI boundary is hard, and the FFI imposes a performance hit that might outweigh the benefit of your assembly language code.
Like I said, the problem here is tooling. I suspect that there is a lack of demand for these things among SBCL and CMUCL users, and in the Lisp community in general.
Ahh, yeah, hmm. That's not exactly what I meant. A language for writing an OS on a conventional CPU would need to allow straightforward control of the memory for its own data structures, not just foreign memory. In lieu of that, I suppose you could turn just off the GC when doing time-sensitive things (like responding to interrupts).
That's sort of besides the point, though, because the main problem with SBCL and other CL implementations is that they are written for use in userspace programs and depend on having access to kernel system calls and library functions like malloc(). So if you were to write a kernel in CL, you'd first have to write an implementation for CL that can run on bare metal. At that point, you might as well just implement a different Lisp dialect that only has the features you need in order to write the kernel.