SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

I wonder how maintainable this kind of an documentation can be: changes to the system (moving stuff from one place or stage to another, adding/removing files, etc) would all have to be kept up with. I also think that it may encourage the perception that SBCL internals are best approached as a whole, which I at least don't subscribe to: while certainly some idea of the big picture (including the build system, which is in ways rather central) is certainly beneficial, many projects don't require really much more then local, "subsystem" understanding.

Maybe effort would be better spent in describing the various subsystem both in source, and where the place to comment them in the source in non-obvious then writing internals documentation? --nikodemus

I think that you have a point. I mostly started this as something to do to avoid something else that I was working on, and it seemed at a good idea at the time. However, unless something like this could be effortlessly automated, I would agree with you that it isn't much of systainable idea. Good thing that I didn't link to it from anything, I guess. Let me explain my impetus, though. I've been sitting here for several days, trying to get a general idea of just what was going on in the sources, with an eye towards a couple of projects in the area of GC enhancement. Although I agree with you that, in general, subsystem knowledge is more important than general knowledge of the entire source, it helpe me, at least, to have a general idea where everything begins and ends, something that isn't always made clear by the source level comments or the directories which contain the files. I just wanted some information there that could make learning about where things are and what things do easier. I admit I chose the wrong thing, but hopefully I'll think of something better.
-Evan

I suspect that the best way to get feet wet in SBCL guts is by working on fairly localized issues and bugs. The BUGS file has 104 entries, there are almost a thousand FIXME notes in the source, and the GCL ansi test suite has a score of failures -- not all localized issues, though, of course. --nikodemus

Assembly Files

Code Files

Cold Files

Compiler Files

PLC Files

Runtime Files

This page is linked from: Assembler Arch Files   Assembler X86 Files   Assembly Files   Code Files   Cold Files   Compiler Files   PLC Files   Runtime Files  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively