Re: Self-referential functions
Frode Vatvedt Fjeld <[email protected]>
| Newsgroups | gmane.lisp.movitz.devel |
|---|---|
| Message-ID | <[email protected]> |
"Chris Capel" <[email protected]> writes: > Ugh. Let my try to sort this out. Movitz has facilities for > directly manipulating bits and bytes (binary-types package). It is mostly movitz/storage-types.lisp that uses binary-types. The major exception is movitz/image.lisp that defines the run-time context structure, here named movitz-constant-block. > Oh, wait it does. I was just looking in the wrong place. In > movitz/losp/muerte/basic-macros.lisp, eq is defined as a compiler > macro. It's just that its defun is in equalp.lisp. Ha! The compiler-macros and corresponding functions are typically not located together because really pretty much all the (compiler-) macros must be defined before you have a sane compilation environment for functions. So it's a bit of a mess, since I haven't really sorted this out in a really principled manner. > So everything is defined, in the first compiler's lisp, down to the > bit and byte level. In movitz/image.lisp, there resides code to > make a binary bootable image out of all this. Its job is basically > to expand the lisp code into assembly and then into binary machine > language. The bits and pieces of making code-vectors from lisp code is of course in movitz/compiler.lisp. The image stuff is really a two-stage process. First, a symbolic-image is constructed (by create-image). This is a big structure of the types defined in movitz/storage-types.lisp, and represents "symbolically" the movitz lisp-world. Then, you can "dump" the symbolic-image to a bootable file. This is what dump-image does, obviously. The same symbolic-image can be dumped many times. You work interactively with the symbolic-image: Re-compile and add functions, types, etc. as you do with interactive lisp programming. There are two other, more exotic variants of images. A stream-image is (typically) a previously dumped image on file that is read back in. A procfs-image, or really a bochs-image, is an image that accesses the state of a bochs running movitz. Neither of these supports interactive modification very much, but they support (static) introspection, and the bochs-image supports some introspection of dynamic state, e.g. backtrace. One goal is to have a new kind of image that talks over a tty or network connection to a running movitz (i.e. on actual hardware), so that there can be real interactive development. -- Frode Vatvedt Fjeld