Subject: Re: BCDs and "Other files"
In-reply-to: "Your message of 29-Jun-83 17:30:01 PDT"
To: Stolfi
cc: 

Send To Beach, Taft
cc to CedarDiscussion↑

I vote for alternative (3): programs should not have auxiliary files. Auxiliary tables and data structures (Styles, TIP ables, icons, etc) should be either bound with the implementation BCD that uses them, or imported by it through the same mechanism used for importing unbound procedures. 

Of course, this is not a suggestion for next week's release. Is it too far-fetched? At the risk of revealing my profound ignorance of Cedar inner workings, I will attempt to make this suggestion more specific.

The idea is to generalize the concept of implementation BCDs so that they may contain not just compiled code but arbitrary data structures. Such a BCD would consist of three parts:

    1. An IMPORTS list,

    2. An EXPORTS list, and

    3. A local storage space.

The local storage space (LSS) would be just a consecutive chunk of words on the disk in containing the procedures and data structures implemented by the BCD. This information would be written there in exactly the same format it would be represented in the Cedar virtual memory, as if it were a Cedar Zone dumped out to disk.

However, the LSS would be an entirely independent addressing space: all pointers in its data structures would refer to either records within the LSS (with adresses relative to its beginning), or to items in imported interfaces.

The IMPORTS list consists of zero or more interface records (and their IDs, i.e., names, timestamps, etc). The EXPORTS consists of one or more interface records, a list items in those interfaces, and the values that are assigned to them by the present BCD.  The adressing conventions above apply also tho pointer values in the EXPORTS list.

One way to create such BCDs would be through the Compiler. BCSs created this way would contain mostly code, but they might contain other data structures corresponding to literals in the source. Implementing this featuure for structures other than ropes would require extensions to the syntax and/or semantics (something like a compile-time NEW).     

The function of the Binder, as now, would be to merge two or more such BCDs into a single one. This operation entails merging their IMPORTS and EXPORTS lists (optionally under control of a .config file), joining their LSS into a single addressing space, and translating all their internal pointers accordingly. The loader would be a special case of binding, in which one of the LSSs is the addressing space of an active process.          

This provides another important mechanism for creating BCDs containing more sophisticated data structures, namely the "prestarting" of normal BCDs. Consider for example the case of a package Foo that uses a TIP table described (in legible form) by the file Foo.tip. As things are now, Foo.DF would export Foo.TIP and FooImpl.BCD. The first thing FooImpl does when started by the user is to read Foo.TIP and parse it into a TIP table in internal format.

With the new version of things, the implementor would start FooImpl.BCD , allow it to read Foo.TIP, and build the internal data structures, and then dump it out to disk as FooImplStarted.BCD. Then Foo.DF would have to export only this file. Loading FooImplStarted would automatically load the TIP table in internal format. The files  FooImpl.BCD and Foo.TIP would be just "working" files of  little concern to the user, like source files and private interfaces.

For this idea to work, it must be possible to "unload" from the main adressing space one or more of the loaded BCDs, so that FooImplStarted.BCD doesn't have to include the whole Cedar boot file. 

For this unloading to be possible, the selected component must contain only local pointers, or pointers to its interfaces. This could be done perhaps by a slight extension to the Cedar syntax: for example, FooImpl.BCD can be unloaded only if it has been declared like

     FooImpl: INDEPENDENT CEDAR PROGRAM
            IMPORTS ..
            EXPORTS... 
         = BEGIN... END

This declaration has the following effects: (1) When FooImpl is bound (or loaded) with other BCDs, the adressing spaces are combined into one (i.e., pointers are relocated as usual), but the LSS of FooImpl remains as a separate allocation Zone, private to FooImpl. (2) all pointer variables declared at the top level of FooImpl, and all pointers fields of records allocated in that Zone, are restricted to contain to addresses within that Zone, or to items in imported interfaces. (This restriction does not apply the local variables and parameters of procedures declared in FooImpl.)

With these restrictions, 

In fact, we could further extend the concept by allowing BCDs to contain processes as well, complete with their execution stacks. In each machine there would be one "active" BCD, whose LSS is the main addressing space of the machine and whose processes are currently active.

Any other BCD's in the disk would be "dormant": it could be resurrected either by binding (a copy of) it with the active BCD, or by putting this to sleep and making the dormant one active. (Would it be possible and/or useful to have more than one BCD, i.e., more than one addressing space, active at the same time on the same machine?) 

 So, BCDs would combine some features of Desktops and partitions