Well, the naïve way is to allocate a big block of memory for your C program and manage it using malloc/free like normal (basically, use the LispOS equivalent of sbrk(2)). Alternatively, since pointers are pointers, nothing stops you from having malloc(3) call out to the Lisp runtime's GC. (free(3) is a no-op.) That's basically how the Boehm G. works. I'm not a systems programmer so I'll admit this is a bit hand-wavy. Also, note that malloc/free are not part of the core C language, per se, but the standard library (a/k/a the C runtime). Even if they were in the core language spec, you as the compiler author can implement them however you choose. They aren't magical.
How would a language's support for garbage collection make it any harder to compile a non-garbage-collected language into it? Why would you think that?
There's no code to hint at how garbage collection should be done, since its automatic. You have to essentially include a library that would emulate the source language gc that it came from so its not a direct translation from one language to another. At least that's what I was thinking
