5 ms·

But why? Can someone explain the reason behind it? I'm confused.

fiddlerwoaroof 6y ago
One advantage of C -> Common Lisp vs. FFI is that issues in the C code are less likely to be exploitable since the C is compiled to a more memory-safe language.
- fiddlerwoaroof 6y ago
  Vacietis is interesting and similar to the way C worked in the Symbolics Lisp Machines (Zeta-C), but I think llvm IR -> CL is more practical these days. Iota (made to port Doom to a pure-CL OS, Mezzano, I believe) is an example of this strategy: https://github.com/froggey/Iota https://github.com/froggey/Iota
- dgb23 6y ago
  I misunderstand what you're saying or miss an obvious joke. I would have thought a garbage collected language is typically safer.
  - lispm 6y ago
    Given that one has plain C code, then it is possibly safer to run it when compiled to a memory safe runtime (with bounds checks, no pointers, etc.) than to use a C to machine code compiler and call the compiled code from Lisp via a Foreign Function Interface (FFI).
    - dgb23 6y ago
      Thanks for clarifying!
sedachv 6y ago
I wanted a way for a Lisp operating system to be able to use OpenBSD or NetBSD hardware device drivers without modifying the driver source code. NetBSD hackers started writing their device drivers with well-specified interfaces between the driver and kernel (eventually that turned into the rump kernel idea https://wiki.netbsd.org/rumpkernel/ https://wiki.netbsd.org/rumpkernel/), OpenBSD hackers borrowed a lot of the ideas (like bus_dma) into OpenBSD drivers. The Lisp operating system runtime would need to implement the applicable kernel functions used by the drivers, and designate certain pointers (hardware registers and buffers) as real memory writes/addresses, and the drivers should "just work." Obviously this is also useful for userland stuff. There are other approaches to this, but Vacietis maps C data and pointers to Common Lisp data structures, so they are inspectable but still memory safe (and you can run a bunch of things in a single address space if you want), and C functions are just Common Lisp functions so all of the development and debugging tools "just work."
- andi999 6y ago
  I see some potential for rapid application development. Shouldnt give you this a C repl?
  - sedachv 6y ago
    It does.
jrumbut 6y ago
I could see this being easier than FFI to use some algorithm implemented in C in a one-off lisp script.
amelius 6y ago
To implement proper tail recursion?
- aidenn0 6y ago
  Common lisp has exactly the same requirements on tail calls as C, and in fact has certain features that make tail call elimination not possible when used (e.g unwind protect and dynamic bindings)

One advantage of C -> Common Lisp vs. FFI is that issues in the C code are less likely to be exploitable since the C is compiled to a more memory-safe language.

fiddlerwoaroof 6y ago
Vacietis is interesting and similar to the way C worked in the Symbolics Lisp Machines (Zeta-C), but I think llvm IR -> CL is more practical these days. Iota (made to port Doom to a pure-CL OS, Mezzano, I believe) is an example of this strategy: https://github.com/froggey/Iota https://github.com/froggey/Iota
dgb23 6y ago
I misunderstand what you're saying or miss an obvious joke. I would have thought a garbage collected language is typically safer.
- lispm 6y ago
  Given that one has plain C code, then it is possibly safer to run it when compiled to a memory safe runtime (with bounds checks, no pointers, etc.) than to use a C to machine code compiler and call the compiled code from Lisp via a Foreign Function Interface (FFI).
  - dgb23 6y ago
    Thanks for clarifying!

sedachv 6y ago

I wanted a way for a Lisp operating system to be able to use OpenBSD or NetBSD hardware device drivers without modifying the driver source code. NetBSD hackers started writing their device drivers with well-specified interfaces between the driver and kernel (eventually that turned into the rump kernel idea https://wiki.netbsd.org/rumpkernel/ https://wiki.netbsd.org/rumpkernel/), OpenBSD hackers borrowed a lot of the ideas (like bus_dma) into OpenBSD drivers. The Lisp operating system runtime would need to implement the applicable kernel functions used by the drivers, and designate certain pointers (hardware registers and buffers) as real memory writes/addresses, and the drivers should "just work." Obviously this is also useful for userland stuff. There are other approaches to this, but Vacietis maps C data and pointers to Common Lisp data structures, so they are inspectable but still memory safe (and you can run a bunch of things in a single address space if you want), and C functions are just Common Lisp functions so all of the development and debugging tools "just work."

andi999 6y ago
I see some potential for rapid application development. Shouldnt give you this a C repl?
- sedachv 6y ago
  It does.

jrumbut 6y ago

I could see this being easier than FFI to use some algorithm implemented in C in a one-off lisp script.

amelius 6y ago

To implement proper tail recursion?

aidenn0 6y ago
Common lisp has exactly the same requirements on tail calls as C, and in fact has certain features that make tail call elimination not possible when used (e.g unwind protect and dynamic bindings)