Statement of Policy Regarding the Phasing Out of the Fleabit System. It has been requested that I put in writing our company policy on this issue. This written statement is not intended to represent any change in the policy which has been in effect for many months. It is our company plan that we will eventually phase out the FLEABIT system as it now exists. Other things being equal, the sooner we do this, or make progress in this direction, the better. However, where the FLEABIT code can serve acceptably well, it is our policy to make use of it as an interim measure. In particular, our current MASTER PLAN OUTLINE (posted on the wall) calls for us to use the existing FLEABIT system to establish a bootstrapping environment for the purpose of bootstrapping the LAMBDA system. When weighing design decisions, we should consider it as a plus factor if an alternative facilitates the eventual phaseout of FLEABIT. [Btw, nothing in this should be taken to contradict the generally acknowledged fact that the FLEABIT compiler itself contains some unique compiler technology which which we might well choose to recycle at some future time.] R. Greenblatt, President and Director of Technology ------------------------------------------------------------------------------ -- draft -- -- draft -- -- draft -- -- draft -- A Formalized Proposal Review System for GigaMOS Systems Inc. Purposes: (1) To assure GigaMOS Systems makes the best possible major design decisions, given its resources and goals. (2) To assure technical staff members of GigaMOS systems fair consideration of any proposals they might make, including written response from Senior Project and Company Management. (3) To provide a written record of the company consideration on these issues. It is believed that this record will be valuable to the company in several ways. If the same or related issues come up in the future the value of a written record of previous deliberations is obvious. In addition, the written record provides considerable safeguards against "misspeakings", and, in the event of a misunderstanding, may enable the point to be clarified without taking the time of the entire set of persons involved in the decision making process. Furthermore, a written record may lead to more considered comments (i.e. inhibit FLAMING), may be more governed by technical realities as opposed to debating (shouting?) ability (or tolerance, etc) and may enable us to consider more complex aspects of matters than we could in a face to face discussion. Mechanism: -- this is a baseline for starters. Feel free to make suggestions. etc. Any technical staff member (or members) who have an idea for a major change, alteration, elaboration, or addition to the then existing official plans of GigaMOS Systems Inc. is encouraged to write them up and submit them in the form of an official proposal. These proposals as machine readable text in the directory JB:PROPOSALS;PROP-nn. Henry will be responsible for maintaining a table-of-contents file JB:PROPOSALS;TABLE-OF-CONTENTS which will give relavent information about each proposal [Title, proposal number, current status, date last modified, date company response last modified, etc]. The proposal, once submitted, will be considered an active document which reflects the current state of consideration of its issue; this avoids the need to read through a lengthy sequence of files or messages to "come up to speed" on the issue. The proposal should have sections considering its impact on schedules and resource requirements, but these could be dummies early in the proposal's lifetime. Thus, the proposal may be updated or elaborated by those making it and technical staff members are encouraged to make comments on the proposal, which should be appended to the end of proposal in a distinctive section, labelled with the name or initials of the person or persons making them. Normally, one should not edit another's section, although, if an idea from a suggestion is adopted into the main proposal it would be appropriate for the proposal makers to note that fact in the comment section where the idea was suggested by some such note as [--this has been incorporated], etc. Of course, new versions of the proposal are written out as the > version, and earlier versions are not normally deleted until they are backed up. If file forking occurs, it should be straightforward to do a "fair" SOURCE-COMPARE-MERGE. The last section of each proposal will be the STATUS section. This section will be supplied by the "project responsible" person or persons, who shall label their comments with their names and the current date. The section will summarize the offical project and/or company response to the proposal and the reasoning behind this response. Of course, the response itself may change also. In the event of significant change, the company officials making the response should attempt to preserve a summary record of the previous responses and their dates. For example: 9/03/88 RG This is a good idea, but we dont have the resources to do it anytime soon ... 1/1/89 RG Now we should do this, in conjuction with ... XXX should begin work on it after he finishs YYY... Putting the Question and Closing If the originators of the proposal believe that the record contains sufficient information to serve as the basis of a decision, they may Put the Question. Actively Put Questions will will notated in the TABLE-OF-CONTENTS file, and project management is then responsible for updating its response, normally within two working days. If project or company managment believes that excessive company resources are being consumed by a particular issue, or believes that the company is irretrivably committed to a certain course beyond the point of useful discussion, it may CLOSE the issue. This really just serves as an advisory to company personel to minimize company resources spent on the issue. Obviously, persons wishing to reopen the issue should take it up with management. Scope: The Official Company Plans which we plan to develop under this procedure are: Initial-Software-Plan: The company will port the LAMBDA software to the Falcon processor. Chip-Hardware-Plan: The company will supervise and approve development of the Phoenix Chip processor. ---- logically separate blurb --- --- Plan for dealing with PACKAGE-SYSTEM related problems on the LAMBDA and the FALCON. The problem: The previous administration has introduced numerous extraneous packages into our current software system (such as CONS:, etc etc). It is generally agreed that all of them except the HW (hardware) package should be eliminated, other things being equal, the sooner the better. However, simply eliminating them would cause a number of problems since various clashes (both within the Falcon system and between the Falcon system and the lambda) would occur. In quite a few cases, actual differences in functionality (as opposed to merely portability) issues are involved. Consistant with our long standing general strategy to freeze the FLEABIT system as much as possible, it would be desirable to avoid getting bogged down in revamping the internals of FLEABIT if possible. A primary consideration when moving list structure between computer software environments is the existance of a simple and reliable tranformation (hopefully the identity transformation) between corresponding packages and symbols of those environments. If this is not true, the lists which read in EQUAL on one system might not be EQUAL on the other, etc. On the Falcon, it is desireable to introduce as little as possible of the extraneous multiple-package lossage. On the other hand, it is probably not feasible to eliminate it completely unless the corresponding thing were done on the Lambda, which, as discussed above, is at least a lot of work. By initializing things correctly on the FALCON, however, it should be possible to have current FLEABIT-compiled runtime code continue to work and also to load in the LAMBDA software in a suitable package environment. The current package structure of the FLEABIT system on the lambda is proven to "work" (at least enuf to do mega-boot, etc). It is proposed that the LAMBDA component of the FLEABIT software remain substantually "as is". However, the current package environment on the FALCON will need some work in any case. One complicating factor is that fact that certain files are expected to be compiled for both machines. Having common files could be a good idea if it really reduced the total diversity of code necessary to implement the system. Unfortunately, as it is currently implemented, it turns out to be a really bad idea because these files are actually processed in quite different ways by the two systems. (ie, a hardware instruction on one system versus a funny subroutine on the LAMBDA). However, we are stuck with this. A drastic step would be the elmination of the "package-munger" currently in the FLEABIT FASDUMP. (Implemented as the function GET-SYMBOL-PACKAGE-NAME in "K-SYS: K;NEW-FASDUMP"). This function in its current form directly violates the "simple transformation" requirement, so it definitely has to go if there is to be any hope of achieving that goal. Unfortunately, since it happens at compile time, any change will mean recompiling the entire environment if it is to "take". ** revision 9/3/88 ** William has proposed not flushing the package-munger. If it were the case that it only "munged" between packages which were destined to resolve to the same package anyway if the full package system were available, then it would not really be messing things up. The problem with this argument is that (1) that doesnt seem to be the case as stands and (2) if it was, why would it be necessary since the symbols in question should have resolved uniquely when read into the LAMBDA system. Another point though, is that the package-munger used only by the FLEABIT fasdumper, and not by the cross-compiler fast dumper. So, if it serves to make bootstrap environment come up in an acceptable state, why disturb it since it is not really involved in anything from that point on. This is a dangerous type of argument in a sense, on the other hand, if we understand clearly what we are doing it may be acceptable ** How the FLEABIT-compiled system comes up. The FLEABIT-COMPILED system bootstraps itself in a fairly unusual way, which has some implications on how the package structure gets established. The FLEABIT cold-load generator has no knowledge of list structure whatsoever! Therefore the cold load actually starts and runs with no symbols or symbol-structure at all. Soon after it starts, however, it does a download of linkage information followed by a download of the "warm" files, which operations create symbols and symbol structure, despite the fact the the full package mechanism is not yet available. Symbols created during the process are placed on a single list, the *WARM-SYMBOLS* list, and are "uniquified" only by pure identnity of [print-string,package-string] (there is as yet no package structure in existance yet). This is inheritly quite risky, since potentially incorrectly distinct symbols could be created during this phase. The Lambda system bootstrapping process avoids most of these risks because the cold load generator DOES have a substantual SYMBOL and LIST structure component and because INTERN and associated functions are part of the cold load itself. Thus, the package structure is created immediately after the cold load comes up and before any files are loaded. This also means that no new symbols can be created until the package structure exists and is fully functioning, avoiding possible lossage. Even though the FLEABIT-compiled system is inheritly inferior in structure in this respect, as are so many aspects of the FLEABIT system, I think it can serve our current purpose, which is to bootstrap the LAMBDA system, if we are careful. However, there is no doubt that until we eliminate it entirely we will continue to be exposed to real risks of lost time due to various screwups. Identity of symbols on the LAMBDA versus on the FALCON The simple transformation goal implies that if two [symbol-pname, package-name] combinations resolve to the same symbol on the LAMBDA (for example) they must also do so on the FALCON. Since there is an existance proof (on the LAMBDA) that the LAMBDA package structure can co-exist with the FLEABIT one, it must be possible to adhere to the identity strictly and create a working environment. Maybe this is even the best course, although it is tempting to engage in a certain "cheating" on the Falcon. For example, on the LAMBDA we have CONS:CAR and GLOBAL:CAR as two distinct symbols. It would not be fatal to have two on the FALCON also, but it seems unnecessary since the whole idea of having two was a bad idea in the first place. In the case of CAR on the Falcon the problem could be bypassed by simply interning a single CAR in ALL of the relavent packages (GLOBAL: and CONS:) for example. Then, everything gets read in correctly, whether it is old or "FLEABIT compiled" code with CONS: or LAMBDA code with GLOBAL:, etc. The problem comes where there is actually clashing functionality, expecially within the FLEABIT system. These represent cases where work has to be done to figure out which functionality we really want and either delete the other or rename all calls to it to be something else, etc. What we actually do: (1) incorporate info which is currently in the pkg-definition into the FALCON package This should pretty much deal with all FLEABIT-LAMBDA symbol "problems" (-- accomplished 9/3/88) (2) incorporate info re lambda-related symbols in sys:cold;global, sys:cold;lisp and sys:cold;system into the falcon package structure.