--DRAFT DRAFT DRAFT-- Why we need a new cold loader, how we are going to get it, and what difference it will make. why we need a new one. The current FALCON cold loader makes no list structure at all! As a result, things have to go thru two very fragile stages before the package system can even be installed. In the first stage [COLD], no symbols, etc are available at all! This causes simple looking code to fail in strange ways (clobberring NIL), etc. In the next stage [HOT] there is a completely simpleminded INTERN which involves a single OBLIST, absolutely no package structure, etc. Interning things in this way can lead to all kinds of screws later (if package inheritance fails to happen, etc etc). Finally, when the package system comes up, things have to be hacked grossly to be consistant with the multiple extraneous packages, etc which have been introduced in the FLEABIT and FLEABIT-COMPILED systems on the lambda. This obviously needs to be flushed. What is the Lambda cold load generator? It is two files, one fairly large [sys:cold;coldut] and one medium size [sys:cold;coldld]. Mostly COLDUT implements a simple virtual memory on a disk partition. Using a disk partition instead of building the cold load in memory allows considerably more stuff to be incorporated in the cold load. This, in turn, is a simplification since then there is less need for the system to run in a "primitive" mode where stuff you normally expect to be there isnt. For example, the lambda cold load has EVAL, the package sytem, READ, PRINT and lots of other stuff all there to start. The Falcon has only FASLOAD to start, etc. In other words, it becomes feasible to put most of the stuff in the WARM and HOT file lists directly in the cold load. The lambda, of course, builds extensive list structure at cold load time which becomes part of the cold load, avoiding numerous problems, etc etc. The virtual memory system of the FLEABIT-compiled system is seriously wedged in various ways. Fixing this without breaking everything would be a royal pain. On the other hand, the virtual memory system of the lambda is perfectly adequate in principle. It "sort of" come for free along with the cold load generator. What do we need to change to make the lambda cold load generator suitable for the FALCON? The concern of the cold load generator is entirely with data structures. In other words it is greatly concern with how an array is stored, but cares not what the PDL looks like, let alone a stack-group, etc. So it needs to know about simple data types like arrays, lists and compiled functions. The current thought (not yet a plan) is to say that the low level conventions used by the FLEABIT are for the most part OK for these simple data types. [The main exception to this I am aware of is the need to maintain back pointers to entries in functions in case the function gets superceeded. Other suggestions for improvements that people are aware of should be voiced now, please.] An the next level of detail, converting the cold loader to the fleabit low level data storage conventions involves generating new QCOM and QDEFS files. These files serve as the authoritative, on line reference for much of the storage conventions. The hope is, the SAME FBIN format can also be loaded by the cold load generator. We have a couple of legs up on this, because it does currently know how to process QFASL files, which are basically in the same format (less several new FASL-OP codes). One significant piece of work would be required would be to put PRIMITIVE operations into the cross compiler. I guess I feel the user-level syntax used by the FLEABIT is OK, altho it would be interesting if anyone could suggest an improvement. Also required is a method to get DEFAFUNs into FBIN files. How might the next stage of planning work out?