From mprince@crl.com Mon, 17 Oct 1994 16:16:55 -0700 (PDT) Date: Mon, 17 Oct 1994 16:16:55 -0700 (PDT) From: Mike Prince mprince@crl.com Subject: Processor Independent Operating System (PIOS) Information 10/17/94 By: Mike Prince mprince@crl.com FAX: (415) 948-2172 Processor Independent Operating System (PIOS) Preliminary Information Thank you for showing interest in the PIOS project. The following document will provide direction during this start-up period. I hope after reading this document that you are as excited as I am about the PIOS microkernel. It will provide a foundation for future research into operating systems, and allow for the development of new and exciting computer applications. Contents of this document ========================= 1. How to Participate 2. Battle Cry! 3. Mission Statement 4. Design Ideas 5. Preliminary Architecture 6. Agenda 7. FAQ's 8. Points for Discussion 1. How To Participate ====================== First read this document. None of the ideas set forth are cast in stone. I am versatile, and will do what I can to make sure this idea gets off the ground. If you are interested in the project, but at this time are not able to contribute, e-mail a message stating so, and I will keep you on the mailing list. We would be more than happy to hear your opinions, and exchange ideas with you. If you have decided to join, please read the points for discussion. Then e-mail me your positions on those points and comments. Please also include a brief description of yourself, which I will compile into a contributor profile to be distributed to all. This description should include education, relevant projects, papers, etc, and small section about you personally. Also include the level of participation you would desire and which aspect of the project you interested in (an estimation of the number of hours each week you would like to contribute would be helpful). Last of all, (I hate to have to do this), please list three references, with one being a professional or academic staff member. Please send these by October 23rd. My e-mail address is mprince@crl.com. I also have a fax line at (415) 948-2172, if that is more convenient, or if there is information that is on paper you would like to submit. 2. Battle Cry... How to Win ============================ How do you win the OS war? Do not be subserviant. Create a design that does things the others cannot do, or does what they do, but better, faster, and easier. Layer your operating system ON TOP OF theirs for the mean time. For that matter, layer it on top of everything that is out there. You can not win from the bottom, you must battle from the top! Exploit the fact that your OS can service the growing distributed networking scene better than theirs. Write a killer app. Exploit the fact that your OS can make the computer run faster for less. Plug that card with 8 of the newest processors available into that empty slot in your PC-XT. Watch all the software written for your OS immediately run 100 times faster, while their software doesn't even know whats going on. Tell that to all the Fortune-1000 companies, which every two years has to upgrade their systems. Exploit the fact that your OS is a technological masterpiece. Write a course guide and give the software to every university with a computer. Professors love teaching the newest stuff, just give them the resources. Within three years you will have a force of enthusiastic programmers. Exploit that size of your microkernel, most computers out there are hidden in microwaves and cellular telephones. Compete for the position to connect all of them together. NT and beepers do not mix. Despite pagers abundance, they are ignored. And here come the set-top boxes and ISDN interfaces... Exploit the fact that the market is still fragmented. Your OS, running on top everything, is great glue, but do not get sucked in to supporting backwards technologies. When the time comes, your OS will slide towards the hardware, supplanting everything in its path. Battle from on top of their OS, not from below! You can win with technological merit and marketing genius, you do not need marketing bucks or huge R&D budgets. 3. Mission Statement ===================== We are here to design a microkernel based operating system to serve as the basis for the next generation of higher-level operating systems and consumer electronics. The OS is to be able to optimize the use of computing resources by re-distributing the computional burder of applications, during execution, over a dynamic, heterogenous, wide area network. It should execute on the largest range of platforms possible, from household appliances to supercomputers. The OS will be the common denominator of all systems. No backward compatibility will be designed in, so as to allow the highest degree of design freedom. 4. Design Goals ===================== What follows are some ideas I would like to implement in PIOS. Process Migration in a Dynamic Heterogenous Environment ======================================================= A little secret for now, but it can be done. Application-Centric Paradigm ============================ All commercial OS's are based on the machine-centric paradigm. In this, an application is based on one computer and does communications with other applications on the same machine or others. An application is grounded to the machine it was initially executed on. Due to this prespective software engineers have had a great deal of latitude in typecasting their applications and OS's to one platform, thus reducing their portability. An application-centric OS allows applications, during execution, to be migrated to different machines. Applications engineers can no longer assume certain static attributes of their platforms. The environment becomes a dynamic one. The job of the OS is to allow freedom of the application. Logical Configuration ===================== The largest object is the tool box. A tool box is composed of an array of arbitrarily sized data and code segments and a number of agents. Code segments are viewed as tools. Data segments are viewed as stacks, however data within the stacks can also be accessed directly. Agents are the execution primitives. Agents execute tools, and have access to the global tool box stacks, plus their own private array of local stacks. Agents can move from tool box to tool box carrying their local stacks. Physical Configuration ====================== Physically, a tool box resides within one working space, and is usually serviced by one CPU. Normally a working space contains several tool boxes. Tool Box Migration =============== At the discretion of the OS a tool box may be migrated to another working space. At such time all constituent parts of the tool box (tools and global stacks, resident agents) and bundled up and moved to the new working space. At the new working space the tool box is unbundled and all tools are either re-compiled, or are deemed better interpreted for overall system performance. The intermediate code is retained in case another move is warranted. Resource Management =================== Tool boxes can be viewed as resources. Each tool box is named and all inter-tool box communications are vectored according to that name. Names may be shared by tool boxes, in the case of libraries for which there may be instances in several working spaces. All services provided by tool boxes must, by default, be stateless. Inter and Intra Tool Box Communications ==================================== Agents carry all data in their local stacks. Typically, parameters will be pushed onto a stack before a call, and popped off during the call. The actual parameter passing format is up to the application. Security ======== All communications (agents) are vectored through a gate upon entry to a tool box. The entry code can choose to do minimal checking to optimize for speed, or extensive checking to maximize security. This checking is not a function of the operating system, but instead of individual tool boxes. Intermediate Language ===================== All code is distributed in an intermediate language, below human programming, but high enough to be applied to a wide range of microprocessors. It will be simple to interpret, and quick to compile down to binary for speed intensive applications. It is expected that human-oriented programming languages will be layed on top of this intermediate language. I would like to do an implemention of c(++) for the intermediate language. Though c would not effectively utilize the attributes of the OS, it would satisfy the short term complaints of those still bound to c. Automatic Stack Contraction/Expansion ======================================= I'm not sure about this one yet. Each stack (tool box or agent) grows from the bottom, and is used like a stack. It has a profile ( max size, grow/shrink increment, and stack pointer). Data can be pushed/ popped from the stack, or accessed arbitrarily inside the range below the SP. When the stack overflows, the segment is automatically expanded. When memory resources in the workspace run low, garbage collection can commence by contracting stacks that are under utilized (stack top - SP > shrink increment). I believe this might save space by applications using only what they need, and by bundling the memory allocation code in the kernel which might otherwise have many instances in the application code. What do you think? Specialized Platforms ===================== For truly speed intensive applications, the actual application code (tool box) would be bundled with the PIOS microkernel and coded in the native machine language. The tool box would be tied to the machine to prevent migration, or an additional copy of the tool box (the intermediate language version) could be migrated. Optimization of Resources ========================= Tool boxes should include a benchmark tool, which could be compiled on a number of different machines to determine which has the best fit of architecture to problem. This benchmarking can take place just before initial execution, or during a re-optimzation of resources during execution. Taking this measure, plus that of available network bandwidth, estimated communications demands, etc, the tool box could be placed in the most optimal workspace. Notice that we are entering into the territory of a priori knowledge of application demands. No File System?! ================ I don't believe in file systems (maybe I'll change my mind). In any case, I'd like for tool boxes to behave like organic systems, going to sleep on persistent computers when not in use, being brought back to the fast non-persistent computers when being utilized. What is a persistent computer? A hard drive with a very dinky CPU could be viewed as a slow slow computer that is persistent, with a very large memory. Using the same algorithm for optimizing the distribution of tool boxes, the less used ones would naturally migrate towards the hard drive based work spaces when not in use. I look forward to the day when all computers have soft power switches; ask the computer to turn off, it moves the tool boxes to persistent storage, and then turns the power supply off. Design Goals Overview ===================== The migration of processes (tool boxes and agents) during run-time in a dynamic heterogenous environment Small minimalistic microkernel (10-20K) Fast Application centric Allow for any level of security, based on applications need Parallel processing intermediate language not for human consumption Organic System "HDD as slow persistant computer" storage (instead of file based) No file system?! development as an interactive process (FORTH like) Implement initial design on top of existing OS's. (distributed file system as improvised network? Or jump straight in and do a TCP/IP implementation?) All original coding!! No copies of others work (for legal reasons) 5. Preliminary Architecture ============================ Microkernel (10-20K) Processor (application, when run on top of an OS) initialization MMU functions Creation, Bundling and Unbundling for transport, Destruction of Agents Tool boxes Interpreter (in kernel for speed) Compiler (in kernel for security?) Automatic segment expansion/contraction? Workspace tool box mapping/redirection Tool Boxes Inter-microkernel packet communications manager Tool box re-allocation algorithms Device drivers (HDD,TCP/IP) General applications High level to intermediate code compiler (gcc?) Development tools GUI Global tool box mapping/redirection Nearby workspace utilization, access speed, etc statistics Intermediate code to binary compiler (as resource for versatility?) 6. Agenda ========== Determine preliminary goals of project Determine structure of organization Determine participants and roles Determine development schedule Finalize PIOS goals Agree on methods to attain PIOS goals PIOS specifications Coding Beta testing End of phase I Creation and distribution of academic materials (specifications, development tools, sample code, etc...) Second recruiting of strategic partners Development of commercial products 7. FAQ's ========= Q: What will be the functionality of the microkernel? A: The microkernel will be a minimalist one, see part 5. Q: How do you migrate processes in a heterogenous environment? A: Thats a little secret for now. Q: What type of implementation are you looking at? You mention an intermediate language but what? Have you considered using object oriented technology? A: See part 4 for implementation. The intermediate language would be a proprietary one. Object oriented technology in programming languages, for the most part, is for programmers, not for computers (I know I'll get hell for saying that). This OS is for computers. (More inflammatory remarks expected...). Object oriented technology, as far as viewing system components as objects which can talk to each other, is what we are trying to accomplish, without relying on OO programming principles. Q: How about the big guys? You can create an absolutely great OS but if you can't get their software to run on it then you won't sell it. A: See our battle cry at the beginning... Q: Have you looked at TAOS? A: TAOS uses VPcode as an intermediate code. VPcode is tied to a virtual RISC processor, that for now is easy to compile down to the target machines. In the future machines will not match VPcode as well (larger register sets, larger word sizes, etc). Once VPcode is compiled down to a target machine, that code cannot migrate during execution. That is one of the goals of our project. 8. Points for Discussion ========================= What are our exact goals? (See goals section.) What shall be the organization of our group? I opt for a for-profit business even though we do not have funding as of yet. If all our work just benefits the research community then great. But if there could be buck to be made for all of us in the end, then even better. I'll be pushing for equity distributions during two phases of the project. These distributions will be based on the number of hours put into the project, capital invested, or equipment donated. A $/hour rate for programming (which likely will be inflated to compensate for the risk) will be arrived at. Equipment will be valued at the street price. Everything else we will vote for and agree upon before accepting. The distributions would be 30% first round distributions/30% second round distributions/ 40% myself. The first round distributions would primarily be for those who donated programming time and any equipment donations we might get. The second round distributions would be to generate capital to fund further development. What will be the structure of our organization? Benevolent dictatorship, republic, or just where in between? Who will provide direction? Who will represent us? How should we resolve differences? Etc. What kind of participants do we need? Where do you fit in? What would you like to do? What is a reasonable development schedule? Do we even need one? (See agenda section.) Should we widely disseminate our developing technologies (a la Linux), or should we all sign non-disclosure agreements and keep this a BIG SECRET? Is there a middle ground? Start thinking about terminology. We are going to be breaking some new ground here, and there is an opportunity to coin some new terms. Most importantly though, we need to agree on the usage of current and new terminology so we can communicate. From Wed, 19 Oct 94 10:55:53 MET Date: Wed, 19 Oct 94 10:55:53 MET From: Subject: Processor Independent Operating System (PIOS) Information Hi, Mike ! Let me compare your PIOS with my former MOOSE project. > Processor Independent Operating System (PIOS) Why not PIOS ? But Unix also is a PIOS, then. Well, the name is not that important. ############################################################################## > 1. How To Participate > ====================== > None of the ideas set forth are cast in stone. I > am versatile, and will do what I can to make sure this idea gets off the > ground. That's good. But remember any project deeply *needs* a referee, and won't go faster than the referee. So after all the discussion has been done, a fast decision must come (even to be modified later should *new* elements come). The MOOSE project once died because it had neither referee nor voting assembly, just raw discussion. Please read my former MOOSE organization file to see how proposed it should have worked (I tried to wake the project, but everyone left). > If you have decided to join, please read the points for discussion. > Then e-mail me your positions on those points and comments. Please also > include a brief description of yourself, which I will compile into > a contributor profile to be distributed to all. This description should > include education, relevant projects, papers, etc, and small section about > you personally. > Also include the level of participation you would desire and which aspect > of the project you interested in (an estimation of the number of hours > each week you would like to contribute would be helpful). I'm interested in all the parts of the project, except the low-level specific device-driver stuff (say, write a SCSI interface for such board -- yuck). I also hate *unix* programming, so if there's low-level thing to code, I prefer writing a direct OS (through the PC BIOS to begin with) rather than coding it over *unix*. Not that I deny interest in writing the stuff over *unix*. Let's say a regular 4 hours a week + more when needed. We'll see if it matches reality. > Last of all, (I hate to have to do this), please list three references, > with one being a professional or academic staff member. What do you mean by that ? Studies I have accomplished ? Jobs I have done so far ? Friends or teachers I may have ? Someone who can say "yes, Mr. Rideau is officially enabled to join your project" ? I've finished my masters in C.S. (even though I'm still struggling to obtain the diploma). The thesis was about translating logical expressions from a language (B, kind of Z cousin -- based on explicit substitutions and jokers) to another (Coq -- based on lambda calculus). No job so far (well, giving elementary cs courses to students, or math examinating them). I'm also paid for my studies as a student of the Ecole Normale Superieure, which is considered as a job. Net Friends of any CS proficiency ? Say members of the projet FORMEL, FORMEL@inria.fr. Teacher or Executive ? Mr. Cousot (cousot@ens.fr) is the boss as for my studies. Mr Beigbeder (beig@ens.fr) is the system engineer at the ENS. Someone who will empower me to join you ? Noone but myself, I fear. If you do earn reasonable amount of money, I'll need the school's board to agree; but else, I need nothing. ############################################################################# > 2. Battle Cry... How to Win > ============================ Implementing the OS in a portable fashion over foreign OSes is exactly what should be done. But don't expect having the version that runs over OS X run faster than raw OS X itself !!! > [Also writing a killer app to demonstrate what the system can do that others > can't] The UDD (Universal distributed Database) will arise one day ! > [Also implement the OS directly over common hardware] (say, PCs or PPCs or whatever) That's good: demonstrate that we offer not only power, but speed at low cost. But convincing the Fortune-1000 is harder than that: you must provide something that I can't give myself -- maintenance over years. You need some large organization for that. > [Using universities to launch the project] That's an idea. But there already are a bunch of university-specific systems running accross the world. How should we compete with *Amoeba*, *Grasshopper*, or *STAPLE* (and perhaps *SELF* or *BETA*) ? > Exploit that size of your microkernel, most computers out there are hidden > in microwaves and cellular telephones. Compete for the position to connect > all of them together. NT and beepers do not mix. Despite pagers abundance, > they are ignored. And here come the set-top boxes and ISDN interfaces... ??? > [have a ultra-portabble OS as a glue to computer] Yep. > Battle from on top of their OS, not from below! You can win with > technological merit and marketing genius, you do not need marketing bucks or > huge R&D budgets. That's all ok to me ! > 3. Mission Statement > ===================== > We are here to design a microkernel based operating system to serve > as the basis for the next generation of higher-level operating systems > and consumer electronics. I'd prefer a no-kernel OS. Why need a kernel at all ? Let's have a decentralized system. Of course we locally have conventions, but locally means any convention can be later replaced by a better one some day, and the OS part independant from the convention still be valid. This means programming all that in a *generic* language. > The OS is to be able to optimize the use of > computing resources by re-distributing the computional burder of > applications, > during execution, over a dynamic, heterogenous, wide area network. [isn't that burden ?] Yep. Though the farther a node, the lesser interest there is in using it for a small job, and the greater interest there is in buffering objects imported from it. > It should execute on the largest range of platforms possible, from household > appliances to supercomputers. The OS will be the common denominator of all > systems. Yep. I'd love to use all those old forgot 80's 'puters forgot in their holes and have my OS migrate tasks to them or from them through serial/parallel lines. Computers will never be obsolete, just slow and tight ! > No backward compatibility will be designed in, so as to allow the > highest degree of design freedom. But local implementations *can* provide emulation if someone is masochistic enough to write it. They eventually *will* if the project becomes big enough. ############################################################################## > 4. Design Goals > ===================== > Process Migration in a Dynamic Heterogenous Environment > ======================================================= > A little secret for now, but it can be done. That's no problem. What's more problematic is a heuristic to determine the cost of migration. We also need a secure system-wide (which may mean world-wide) object identification protocol. > Application-Centric Paradigm > ============================ > All commercial OS's are based on the machine-centric paradigm. In this, I'd say a low-level resource-centric paradigm. > an application is based on one computer and does communications with other > applications on the same machine or others. An application is grounded > to the machine it was initially executed on. An application must rebuild everything but low-level I/O from scratch. This is just unbearable. Also persistent storage and human interface are to be rebuilt everytime, which is 95% of current application programming, whereas all that stuff should go in generic OS modules. > Due to this prespective > software engineers have had a great deal of latitude in typecasting > their applications and OS's to one platform, thus reducing their portability. Because of low-level-ness, programmers must manage raw binary files instead of well-typed objects. Hence they *must* use typecasting. All this is *very* unsafe, and implies a *slow* OS with run-time checking everywhere, without ensuring security for all that. > An application-centric OS allows applications, during execution, to be > migrated to different machines. Applications engineers can no longer > assume certain static attributes of their platforms. The environment becomes > a dynamic one. The job of the OS is to allow freedom of the application. A high-level OS will hide all the low-level concerns: persistent storage to contain data, machine choosen to run code, low-level encoding of objects, object implementation, human interface code (will be semi-asutomatically generated). > Logical Configuration > ===================== > The largest object is the tool box. A tool box is composed of an array of > arbitrarily sized data and code segments and a number of agents. Code > segments are viewed as tools. Data segments are viewed as stacks, however > data within the stacks can also be accessed directly. Agents are the > execution primitives. Agents execute tools, and have access to the global > tool box stacks, plus their own private array of local stacks. Agents can > move from tool box to tool box carrying their local stacks. This seems a bit complicated and low-level. Can't we use unifying semantics a la SELF (everything is message-passing) or BETA (everything is a pattern) ? or STAPLE (everything is a function) ? Let's only have arbitrarily typed objects with a global GC as a basis. > Physical Configuration > ====================== > Physically, a tool box resides within one working space, and is usually > serviced by one CPU. Normally a working space contains several tool boxes. When emulating Unix/DOS or working under Unix each working process is itself an active working space, so no need for multiple CPUs to test our multi* algorithm. > Tool Box Migration > =============== > At the discretion of the OS a tool box may be migrated to another working > space. At such time all constituent parts of the tool box (tools and global > stacks, resident agents) and bundled up and moved to the new working space. > At the new working space the tool box is unbundled and all tools are either > re-compiled, or are deemed better interpreted for overall system performance. > The intermediate code is retained in case another move is warranted. Moving big objects is not always beneficient. Allowing small objects to nigrate seems a better policy to me: when using the "archie" equivalent, the search process is migrated, but not including the human interface. > Resource Management > =================== > Tool boxes can be viewed as resources. Each tool box is named and all > inter-tool box communications are vectored according to that name. Names > may be shared by tool boxes, in the case of libraries for which there may be > instances in several working spaces. All services provided by tool boxes > must, by default, be stateless. Ok. But again, I prefer having as light-weight objects as possible to reduce object manipulation overhead. > Inter and Intra Tool Box Communications > ======================================= > Agents carry all data in their local stacks. Typically, parameters will > be pushed onto a stack before a call, and popped off during the call. > The actual parameter passing format is up to the application. That's well. But why force using stacks ? Some languages have no stack (see ML or LISP implementations), and just use a heap. Let's not specify internal behavior. The only thing is: objects must be able to migrate in some way whatever. Being able to migrate is the same as being able to be saved/restored to/from a file (the file just being transmitted over the net in case of migration). > Security > ======== > All communications (agents) are vectored through a gate upon entry to a > tool box. The entry code can choose to do minimal checking to optimize for > speed, or extensive checking to maximize security. This checking is not > a function of the operating system, but instead of individual tool boxes. Yes. let's have a compiler-based security system. All binary code *must* be secure. When it comes to migrating it, let's have some optional PGP signature system to ensure that code comes from a trusted compiler or user. > Intermediate Language > ===================== > All code is distributed in an intermediate language, below human programming, > but high enough to be applied to a wide range of microprocessors. It will > be simple to interpret, and quick to compile down to binary for speed > intensive applications. It is expected that human-oriented programming > languages will be layed on top of this intermediate language. I would like > to do an implemention of c(++) for the intermediate language. Though > c would not effectively utilize the attributes of the OS, it would satisfy > the short term complaints of those still bound to c. Some kind of FORTH or byte-code is good. See the byte-code interpreter from CAML-light. I've always wanted such a beast. > Automatic Stack Contraction/Expansion > ======================================= > I'm not sure about this one yet. Each stack (tool box or agent) > grows from the bottom, and is used like a stack. It has a profile ( > max size, grow/shrink increment, and stack pointer). Data can be pushed/ > popped from the stack, or accessed arbitrarily inside the range below the SP. > When the stack overflows, the segment is automatically expanded. When > memory resources in the workspace run low, garbage collection can commence > by contracting stacks that are under utilized (stack top - SP > shrink > increment). I believe this might save space by applications using > only what they need, and by bundling the memory allocation code in the > kernel which might otherwise have many instances in the application code. > What do you think? I love stacks. But why have them as OS primitives ? To me, let the OS handle arbitrary objects, and have stacks in what resemble the standard library. Let's have an ever-running garbage collecting system and use it as a criterion for migration. > Specialized Platforms > ===================== > For truly speed intensive applications, the actual application code (tool > box) would be bundled with the PIOS microkernel and coded in the native > machine language. The tool box would be tied to the machine to prevent > migration, or an additional copy of the tool box (the intermediate language > version) could be migrated. Again, in a distributed system, some kind of signature must come with any low-level code, that may be checked to verify that any binary code comes from a trusted source. Objects could come with their "equivalents" under such or such assumption; then when migration cost is computed, matching equivalents are taken into account. > Optimization of Resources > ========================= > Tool boxes should include a benchmark tool, which could be compiled > on a number of different machines to determine which has the best fit > of architecture to problem. This benchmarking can take place just before > initial execution, or during a re-optimzation of resources during execution. > Taking this measure, plus that of available network bandwidth, estimated > communications demands, etc, the tool box could be placed in the most > optimal workspace. Notice that we are entering into the territory of a > priori knowledge of application demands. My opinion is that compile-on-demand and optimize-on-use is the best policy, that adapts to the users' needs. See SELF about that. I think we need some kind of persistent system with lazy-evaluation like STAPLE. > No File System?! > ================ > I don't believe in file systems (maybe I'll change my mind). In any case, We still FSes to communicate with other OSes and import/export data, though I agree they are not a system primitive. > I'd like for tool boxes to behave like organic systems, going to sleep > on persistent computers when not in use, being brought back to the fast > non-persistent computers when being utilized. What is a persistent computer? > A hard drive with a very dinky CPU could be viewed as a slow slow computer > that is persistent, with a very large memory. Using the same algorithm for > optimizing the distribution of tool boxes, the less used ones would > naturally > migrate towards the hard drive based work spaces when not in use. I look > forward to the day when all computers have soft power switches; ask the > computer to turn off, it moves the tool boxes to persistent storage, and then > turns the power supply off. To allow some security, we must also provide a regular or permanent logging process which will ensure that all system change will be written in persistent memory (that survives power failure). See Grasshopper for that. > Design Goals Overview > ===================== > The migration of processes (tool boxes and agents) during run-time in a > dynamic heterogenous environment 1) The smaller the objects, the easier the migration. 2) for read-only objects, it may be better not to *migrate* the object, but to propagate copies. 3) Now, what if there is a net split ? Will modifying the object be made impossible ? Then you must copy the object and maintain your own copy. But then, what when the net is one again ? How to merge changes ? There can be several object-dependent (object-parametrizable ?) policies. > Small minimalistic microkernel (10-20K) Why need a micro-kernel at all ? We need objects, including memory managers and intermediate-code interpreters/compilers, but no microkernel. Only conventions. > Fast This will come later. Concentrate on the power. > Application centric ??? I'd say high-level OS. Do not define bitwise behavior like under Unix/C. Just define high-level protocols, and an abstract intermediate-level language. Moreover, we'll still need machine-centric layers. Only you'll address them only if you really need to (i.e. play music on a host, and not another one ten miles away :) > Allow for any level of security, based on applications need 1) Require super-user rights to validate any low-level code before execution; 2) use the policy: "if the object is addressable, it's usable". 3) Use run-time optimization (i.e. partial evaluation) a la SELF to achieve good performance even with "object filters" that allow only partial access to an object. 4) Now, as for security, what to do when hosts do *NOT* completely trust each other ? In a WAN, that's especially critical. The answer is: in the WAN, all machines are not equal; each machine has levels of trust for other hosts (including distrust due to net link quality) which will decide it *NOT* to migrate an object. > Parallel processing intermediate language > not for human consumption Well, not for non-hacker human. But we will still have to manipulate it. And if we do, other hackers may want to use it too. Only they'll have to be superuser on the system. > Organic System > "HDD as slow persistant computer" storage (instead of file based) > No file system?! > development as an interactive process (FORTH like) > Implement initial design on top of existing OS's. > (distributed file system as improvised network? Or jump straight > in and do a TCP/IP implementation?) > All original coding!! No copies of others work (for legal reasons) I don't completely agree. We can copy these work, as long as we respect their copyrights. Thus, if we take code from say Linux, this code will stay under the GPL. But if that code is isolated in a module, it can be distributed with a separate license from the whole project. That's why I recommend again having the nano-kernel GPL'ed so we have no more problem. Of course, we shouldn't include other *commercial* work if we wanna avoid paying royalties ourselves... > 5. Preliminary Architecture > ============================ > Microkernel (10-20K) To me the Kernel is 0K. At boot process, we have a boot loader, which loads modules using some dumb convention. A second-level or nth-level loader(s) can change the convention to anything. But basically, we must think in terms of objects that depend one on the other, each using its convention, and calling other objects through a proper filter (itself a needed object). There's no need about a centralized kernel. What we need is good conventions. Each convention/protocol will have its own "kernel"/object. The only requirement is that the system is well founded upon the hardware or underlying OS. > Processor (application, when run on top of an OS) initialization That's just one basic boot module. > MMU functions Not stricly needed (though quite useful). > Creation, Bundling and Unbundling for transport, Destruction of > Agents That's an important set of modules. Perhaps that's what resemble the most a kernel, as it will be ever used. But it's no more a kernel than the MM module with which it interacts, or the IO drivers used to load them. > Tool boxes Why introduce arbitrary differences between objects ? Let the system manage a unified set of entities, called objects, agents, frames, patterns, functions, tool boxes, shit, or whatever you like (though object seems the most natural). If the user language introduces differenciation between objects, let it do so. But this is no OS requirement. What we want the OS to do is providing security protocols, including for type-checking under and between various languages. > Interpreter (in kernel for speed) Let's not specify thingsin term of kernel, but in term of modules. > Compiler (in kernel for security?) Anything that produces low-level code must be trusted (i.e. supervisor mode), which does not mean it belongs to the "kernel", even if almost all hosts will have one. > Automatic segment expansion/contraction? What is that segment stuff ? Let's not specify implementation behavior, but high-level response from the system. > Workspace tool box mapping/redirection Nothing in kernel as proper. Everything is loadable/unloadable modules. But there are various moving conventions. > Tool Boxes > Inter-microkernel packet communications manager > Tool box re-allocation algorithms > Device drivers (HDD,TCP/IP) > General applications > High level to intermediate code compiler (gcc?) > Development tools > GUI > Global tool box mapping/redirection > Nearby workspace utilization, access speed, etc statistics > Intermediate code to binary compiler (as resource for versatility?) No we don't need any *kernel. But yes we need such things as modules. > 6. Agenda > ========== It seems ok. but as for PIOS specifications: WHAT HIGH-LEVEL LANGUAGE SHOULD WE USE TO MODEL THE OS ? Clearly C is not a HLL. We need a language that's well with persistence, concurrency, etc. BETA and SELF or STAPLE may be such languages/systems. > 7. FAQ's > ========= > Q: What will be the functionality of the microkernel? > A: The microkernel will be a minimalist one, see part 5. No kernel at all ! Only moving conventions. > Q: How do you migrate processes in a heterogenous environment? > A: Thats a little secret for now. The user won't see it. Every address external to the moved module will be converted to an absolute system-wide address before being sent. Migration cost and decision is computed as part of a local address space's garbage collection, which in turn is called when scheduling detects suboptimal system performance. Migrating itself is a particular case of saving and restoring objects. It's just restoring the object as soon as possible on another machine ! > Q: What type of implementation are you looking at? You mention an > intermediate language but what? Have you considered using object > oriented technology? > A: See part 4 for implementation. The intermediate language would > be a proprietary one. > Object oriented technology in programming languages, > for the most part, is for programmers, not for computers (I know > I'll get hell for saying that). This OS is for computers. (More > inflammatory remarks expected...). Object oriented technology, as far as > viewing system components as objects which can talk to each other, is what > we are trying to accomplish, without relying on OO programming principles. SELF is an OO language that already allows much of what PIOS needs. BETA also is an OO language that has persistence and distributed objects over Unix (though the current implementation is quite trivial) (BTW, C++ or Objective C are definitely *NOT* OO languages; they are just bullshit to me). What I mean is the OS should include type-checking protocols, conventions or mechanism, or else system security and consistency cannot be ensured. Allowing the most generic type-checking (so that any language can be implemented using such protocol) leads us to something "object-oriented". > 8. Points for Discussion > ========================= > What shall be the organization of our group? > I opt for a for-profit business even though we do not have funding > as of yet. If all our work just benefits the research community > then great. But if there could be buck to be made for all of us in > the end, then even better. I'll be pushing for equity distributions > during two phases of the project. These distributions will be > based on the number of hours put into the project, capital invested, > or equipment donated. A $/hour rate for programming (which > likely will be inflated to compensate for the risk) will be arrived > at. Equipment will be valued at the street price. Everything else > we will vote for and agree upon before accepting. The distributions > would be 30% first round distributions/30% second round > distributions/40% myself. You're getting a huge share ! Let's see what the others say. If you work full-time, perhaps you deserve it. But let's have a per-work ratio (with a multiplier for you if you like). My opinion is whereas the killer-apps and migration modules such should be commercial/shareware, the "micro-kernel" (that is, enough code to run the OS on a single CPU system) itself should be released under the GPL, so that the system be wide-spread accross the net. Such an official net support *is* important (see the Linux community). That didn't prevent Linus from earning directly and indirectly money from his work. But it helped the Linux community to multiply accross the world. And I know of no OS with such a support. And if our killer-app is as good as we say, it deserves commercial distribution above the GPL'ed OS. We can also put a condition on the GPL that a GPL'ed version of the OS cannot be used in a commercial environment, which will force companies to buy OS licenses, whereas people can use it freely (but are welcome if they pay). In any cases, don't expect to earn much money from that project. If you do, that's all the better. And if you don't, I'd rather not being paid for a successful thing than not being paid for a forgotten project. > What will be the structure of our organization? Benevolent dictatorship, > republic, or just where in between? Who will provide direction ? > Who will represent us? How should we resolve differences? Etc. Basically, you get best results if you decentralize decision so that each subject has its own maintainer. But in case of conflicts, you need a referee (say the subject maintainer or ultimately you). If we are to discuss and vote, then it must be quick; that's why we need regular meetings whenever common subjects are discussed. TALK/IRC sessions are welcome. Mail is viable only if participants reply very quickly. (under IRC, I'm Fare when connected. Please send me a message if you see me). > What kind of participants do we need? Where do you fit in? What would you > like to do? We need People who participate *regularly*, and reply quickly. The one week latency between message & answer killed MOOSE. I am ready for all language-related topics, including implementing the intermediate language, compiling to it and from it. > What is a reasonable development schedule? Do we even need one? > (See agenda section.) Oh yes we need one. MOOSE had no schedule and it died because nothing was done. Typically, we should have regular meetings and schedule for next meeting; if mail is quick enough, we can have it. But TALK/IRC sessions are better if we are to vote in real-time after discussions. Also, we should write good english in mails as is slows the process, if we can use symbolic stuff. If you know IRC, we can have an IRC channel with an IRC bot to keep it open. THIS TOPIC IS OF UTTERMOST IMPORTANCE. > Should we widely disseminate our developing technologies (a la Linux), or > should we all sign non-disclosure agreements and keep this a > BIG SECRET? Is there a middle ground? I think the OS should be open, so we have a wide-spread internet support is possible. The misfeatures and bugs become much easier to correct this way, and the OS will be able to spread like Linux. Then, we can add a close in the standard license, so that people who make money out of the system must pay royalties to the authors. The killer-apps can be developped under non-disclosure agreements if you see the needs. > Start thinking about terminology. We are going to be breaking some new > ground here, and there is an opportunity to coin some new terms. > Most importantly though, we need to agree on the usage of current > and new terminology so we can communicate. There are already a lots of systems whose terminology we can reuse. But yes, an official glossary is needed and when we communicate, we must have a one-to-one word -> meaning mapping. Thus we also need a referee for words. Again, I suggest that the subject maintainer ultimately decides (after vote) while the global referee (you) will end discussions if there still are. Glossary is of course modifiable, if *new* arguments come for a new terminology. references: SELF: ftp://self.stanford.edu/pub/papers Grasshopper: http://www.gh.cs.su.oz.au/Grasshopper/ Xanadu: http://www.aus.xanadu.com STAPLE: ftp://ftp.dcs.st-and.ac.uk/pub/staple MOOSE: ftp://frmap711.mathp7.jussieu.fr/pub/scratch/rideau/moose/ and see the comp.os.research FAQ. in the MOOSE directory, get papers.zip From smcl@sytex.com Thu, 20 Oct 94 14:45:29 EDT Date: Thu, 20 Oct 94 14:45:29 EDT From: Scott McLoughlin smcl@sytex.com Subject: MOOSE Project -- new OS ? rideau@ens.fr (Francois-Rene Rideau) writes: Howdy, Of course, you might use Lisp. There's a long history to draw from and just about _everything_ has been done in some Lisp dialect or another. Nice project. I'd like to keep posted of your progress. I'm particularly interested in object/tagging formats and VM architectures. ================================================= Scott McLoughlin Conscious Computing ================================================= From kyle@putput.cs.wwu.edu Fri, 21 Oct 1994 11:50:19 +0800 Date: Fri, 21 Oct 1994 11:50:19 +0800 From: Kyle Hayes kyle@putput.cs.wwu.edu Subject: MOOSE Project -- new OS ? Vous-avez dit: > [snip] Ceci m'interesse aussi, mais je l'attaque de l'autre cote. Je suis en train de faire une language base sur les idees de Self avec un "syntax" RPN (donc a la Forth). J'ai le noyau termine, mais le process de bootstrapping s'announce long. Si ca vous interesse, je peut vous envoyer un petit document decrivant ce-que j'ai fait. Ce document n'est pas tout a fait a jour, mais il n'y a pas beaucoup de difference entre la language et le doc. Ca fait un peu du temps depuis j'ai ecris quelque-chose en francais... Best, Kyle kyle@cs.wwu.edu From terra@diku.dk Fri, 21 Oct 1994 12:00:07 +0100 Date: Fri, 21 Oct 1994 12:00:07 +0100 From: terra@diku.dk terra@diku.dk Subject: MOOSE Project -- new OS ? Re. your MOOSE project. ---------------------- Let me start by saying that what you are proposing is not a one-man project. You don't have time enought for it. You simply have to get others to work with you or give it up. The Linux kernel was written by one man, but there would be no stable Linux today if not hundreds of other has joined the project. One man does not have the time to find all the bugs, find all the errors the Cpu and its documentation, test against and port the program to zillions of different pieces of hardware (hard disks, busses, video adapters, mice, sound cards, ...), and what's not. I don't know the Linux details since I am not a Linux user, but I am under the impression that the Linux society holds quite a few very able men and women with experience in lots and lots of different hard- and software. Then comes the question: why? Wouldn't you be far better off by implementing the language of your choice on top of an existing and stable multiprocessing kernel? Think of Emacs which is a Lisp interpreter (with, i.e., garbage collection) with its core implemented in C. Emacs is provably portable. Morten Welinder From jvs@iconz.co.nz Fri, 21 Oct 1994 23:18:25 +1200 Date: Fri, 21 Oct 1994 23:18:25 +1200 From: Johan Van Schalkwyk jvs@iconz.co.nz Subject: MOOSE Project -- new OS ? Hi You're probably way ahead of me in most respects. But I have written my own (little) language in 8086 ASM & am interested in corresponding. Have one or two ideas about assembler / language design, if you're interested. Just mail me.. JVS From bkyee@mtu.edu Fri, 21 Oct 94 12:20:27 EDT Date: Fri, 21 Oct 94 12:20:27 EDT From: Ban Keong Yee bkyee@mtu.edu Subject: Basic Protected mode Hi, Can I join you? I want to write a OOS too. Please accept my application. I porgram in C++ and a little bit asm. Thanks in advance. BanKeong bkyee@mtu.edu In article you wrote: : : I'm still looking for the high-level language to use, which must be able to : integrate all those features. Can somebody help me ? : I'm considering BETA, SELF, Icon, or something like that. Else I'll have to : design my own :( :( :(. Any comments ? : : I'm also considering joining Mike Prince and his PIOS project. If there's : another project (personal/university/commercial) that includes all (or a big : part) of those features, please tell me. If you see any reason why it shouldn't : be possible or wishable, please tell me too. : : Any help, comment or feedback appreciated. : Please reply by mail (but you may post your reply *too*). : Thanks. : -- : -- , , _ v ~ ^ -- : -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- : -- ' / . -- : MOOSE project member. OSL developper. | | / : Dreams about The Universal (Distributed) Database. --- --- // : Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // : Phone: 033 1 42026735 /|\ /|\ / From sfp@mpeltd.demon.co.uk Fri, 21 Oct 94 17:25:38 GMT Date: Fri, 21 Oct 94 17:25:38 GMT From: Stephen Pelc sfp@mpeltd.demon.co.uk Subject: MOOSE Project -- new OS ? > The project is called MOOSE, and I'm writing it alone. It means > Multi-* Object-oriented Operating System and Environment. *I* didn't choose > the name as I wasn't alone at that time. ... > - machine-independent low-level (stack-based/FORTH-like ?) language for > portable binaries, with common interpreter or compiler back-end. We have done this under ESPRIT project (EP5497 PROCIC and EP9152 SENDIT) funding, and it is quite possible to make a stack language be a suitable target for conventional compilers. It is also possible for back-end generators to generate quite good code. You should also look at the ANDF technology produced by the OMI-GLUE project, which was considered for use by one of the Unix consortia. Regards, Stephen -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From jvs@iconz.co.nz Sun, 23 Oct 1994 00:37:21 +1200 (NZST) Date: Sun, 23 Oct 1994 00:37:21 +1200 (NZST) From: Johan Van Schalkwyk jvs@iconz.co.nz Subject: MOOSE Project -- new OS ? Dear Francois-Rene > I'm always interested in other people's ideas. Please tell me your ideas, > or send me docs or code about your work. You're welcome. I myself have ideas > about how assembler should be integrated in a high-level language (with > completely parametrizable specifications about calling conventions, and > efficiency, and possible optimizations). Ok. Where to start. Perhaps a few ideas, or thumbnail sketches, first. 1. I have played around in several languages, but apart from assembler, the only one that I have found to be more or less what I've been looking for has been Lisp. It is however crippled by its parentheses (not just "LISt Processing" but "Lots of Irritating Single Parentheses". Also, parsing Polish notation from left to right is a real pain in the a***! 2. So I've played around with what I call "POWER" parsing (for POlish With Evaluation in Reverse). Let me give you an example: In Lisp you might write something along the lines of:- Defun (Factorial (lambda (n) (cond ((greaterp n 1) (times n (factorial (sub1 n)))) (T 1) ) )) This may not be 100% kosher, but I haven't played around with Lisp itself for several years. You more or less get the flavour, however. What about the following syntax? Define Factorial' ( Return 1 (Return Times n Factorial Sub1 n If Greater n 1))' This is evaluated as follows: a. Start at the rightmost item: It is a quote mark, so the tree to the left is quoted. Put this whole tree (or a pointer to it) onto your stack. b. Move left past the tree, to the quote mark to the right of the word Factorial. So we quote this in turn, putting it onto the stack. c. Now we encounter the verb "Define". This takes two arguments off the stack, and then attaches the tree (as a definition) to the newly defined "verb" Factorial. Then if we say (in this idealised function) eg: > Factorial 2 It will be evaluated as follows: a. go to the rightmost item. It is a number (2), so just put it on the stack. Then move left to the word Factorial. b. Factorial is a verb, so go to it's rightmost item and start moving left (ignoring the parentheses). c. Put the "1" on the stack, find the value of n (remember this is idealised, I have obviously worked out ways to represent arguments etc), and put it on the stack . Then evaluate the greater, and so on. Ie a sort of Forth-like / Lisp-like approach. I have been playing around with this simple approach for some time now, and it has several merits. It is easy to read (provided it is set out well) and evaluation is fast (even interpreted code moves along on an 8088 (!!) using a few tricks of my own devising). I have also made the structure _extremely_ simple: basically the above defines practically the whole language, and the only structures one needs are: ( something If condition ) ( Loop count etc ) ( End etc ) The idea being that the expression "something" is performed only if the condition is true, and End moves to the corresponding right parenthesis (and continues to do this forever, unless a Return or If is interposed somewhere along the line. Loop is similar to End, but only performs an "End" if the count specified is nonzero. Note that there is no "If then else" construct. This is for several reasons: a. It has been shown that ( something if condition) ( something_else if Not condition) causes fewer programming errors and is more legible; b. It keeps the syntax simple c. With the above structures, evaluation is faciliated d. Compilation is dead easy (yes I wrote a simple compiler) e. etc. 3. This basically defines my top level. Obviously, there are a hell of a lot of technicalities, etc. It is quite workable. I can control practically every aspect of eg. a PC's function with about a hundred verbs. Also, logical extensions to the language are easy and intuitive. Let us say you have a verb AtX that moves the cursor position on screen to the position specified by (leaving the Y position unchanged). If you want to define a verb that finds the current X position on screen, you _might_ define it as WhereX (adding another verb to your endlessly growing list), but I find it more mnemonic to just have something like: > AtX ? This has an added advantage (apart from being a good mnemonic) in that you can have an error handler that traps bad syntax (eg a ? supplied as an agrument for AtX) and simply "patch in" a new routine (even dynamically?) to handle the extension to the language. Furthermore, you can use a similar construct for other verbs. eg if > Go A means change to drive A from the current drive, Go ? might mean "where the hell am I?" 4. A further note: I define a few very simple "verbs" and "nouns" (types of atom, if you wish). They are: a. nouns: 1. characters/immediates eg A , / ? 2. numbers eg 123 3. words eg Fred alpha 4. sentences eg (this is a (nested (tree structure))) A word can take on any value, or even become a sort of "verb" b. verbs: 1. Pre-Defined verbs eg If AtX 2. User defined "verbs" (I call them "friends") eg the Factorial, defined above. 4. Okay, that's quite enough about my crazy language - you probably think that I'm totally nuts, by now. I just wanted to give you a flavour of what I'm playing around with. 5. Now, the assembler part. Most of the above (because of its simplicity) is extremely easy to implement in assembler. Extensions are easy to add, as explained. But there are also a lot of ideas that I have had (about assembler design) that would make things even easier. I feel that one of the reasons why languages such as C tend to be non-intuitive and ugly to program in (my crazy opinion, anyway) is that the design does not stress a minimal approach - they seem to never have heard of orthogonality. Also, I really believe that whenever you program a computer to do anything more than an absolutely trivial task, you are effectively creating a language (even if it is just a very simple language where all the instructions consist of pressing a few keys or clicking a mouse on a menu). So if you are working on a high level, you are effectively working within a whole hierarchy of complex and badly designed languages, and trying to create your own little "language" on top of this. The lower levels are meant to be transparent, but this is almost never the case. The more complex the setup, the more likely an intermittent and irritating error is. The solution as I see it is to keep things absolutely simple (a la RISC), and rigorously exclude any instructions/ constructs that impair lucid interpretation on any level. 6. So I see any programming attempt as part of a continuum. There may be several "levels", but one often has to have a good grasp of what is happening on several of those levels, in order to be able to program effectively!! Every time I have tried to do something more than slightly challenging in a higher level language, I come up against this problem. This does not mean that one must not define "levels", but one should be able to understand with exquisite clarity what is going on at a lower level, should the need arise. This also means that appropriate instructions must be available on the relevant levels. What do I mean by "appropriate"? A difficult question - I think that to a certain degree it depends on what is available at lower levels, but much more important is really what is intended on a higher level. For example, if your primary goal is to have a magnificent graphics-orientated program on the top level, it _may_ be entirely appropriate (in an idealised setup) to have a primitive instruction on a lower level that eg "draws a line of a certain colour between two defined points". It may be a lousy tradeoff to have to (on that same level) plot a series of dots using complex manipulation of memory and / or output ports. Unfortunately, we often seem to be driven by the hardware designers .. they define what is available, we construct our program (on all levels) around this, rather than saying "WE WANT THIS. THIS IS OUR STANDARD. WE WILL DEFINE OUR SOFTWARE AS SUCH AND SUCH. IF YOU CANNOT PROVIDE THIS FOR NOW, WE WILL STILL DEFINE THE STANDARD AS SUCH, AND WILL JUST HAVE TO MUCK AROUND (ON A SLIGHTLY LOWER LEVEL OF OUR SOFTWARE HIERARCHY) TO SIMULATE WHAT WE REALLY WANT" !! 7. The flipside of course is that one should know what one is dealing with. If I ask for a number, I want to know _exactly_ how long it is, not some arbitrary assurance from the programming language that it may be such or it may be such, depending on the system on which we are running, thank you for nothing! (If I go into a restaurant and order a steak, I want to know if it is 250g or 500g)! I have a lot of ideas in this regard, specifically with respect to assembler design. Tentatively, I think that there should be just three levels: Level 0: lowest level. May need considerable effort / ingenuity to implement concepts defined on Level 1. But ideally, should all be ultra- fast and implemented in hardware. All timing should be precisely defined, and accessible to the next level. Level 1: The "assembler" level. But cf my example above about drawing a line! I have several ideas about what "ideals" should be implemented on this level. Level2: The "top" level. Perhaps something along the lines of the incredibly simple language I gave you a flavour of above. You may well find the above ideas too trivial to comment on, or disagree totally. Please feel free to be completely honest! If you want to hear more, just say so! Perhaps you could give me a few ideas of your own? (I hope there are not too many typos in the above, as I composed it on the fly). Bye for now, JVS. From bkyee@mtu.edu Sat, 22 Oct 94 11:01:42 EDT Date: Sat, 22 Oct 94 11:01:42 EDT From: Ban Keong Yee bkyee@mtu.edu Subject: Basic Protected mode Hi, > > > Please accept my application. > > I porgram in C++ and a little bit asm. > I'll be glad to, though I fear it will be a long time before C++ will be > supported in my OS (an entirely new compiler would have to be written, as > my OS won't support the usual unsafe flat C memory model as a native mode). > My most important grieves against C++ are its unsafety, static typing, > and very complex semantics. > I have been wrote program since 1989, and I have try BASIC, Pascal, C and C++. The only language that increase my productivity is C++, because of code reuseable. Well, I know a OS is very hard to write, I don't mind to work on a very small part, such as compiler writing. How can I know more about your OS? > > Thanks in advance. > If you can bear writing an application in a language still partially defined, > you're welcome. > I don't mind to learn a new language. How can I know more about this language? > I'm not trying to disgust you from helping me. I do need help. But I must > warn you that my way is long and difficult, though I hope it to be full of > reward. > Yes, I understand that. In fact, when I write a small OS for 8088, all I have is the OS, no compilers, no assemblers, no applications. So, I need to write compiler, assembler, and more for that. It is a long way to run. Therefore, I think if I have a C compiler, then I can port most software from other platforms. I am sure a C or C++ compiler will make your OS more close to perfection. > So, should I add you to my project team ? > Yes, please. How many persons in you project team currently? Thanks again. BanKeong bkyee@mtu.edu > I wish you good luck and success anyway. > > -- , , _ v ~ ^ -- > -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- > -- ' / . -- > MOOSE project member. OSL developper. | | / > Dreams about The Universal (Distributed) Database. --- --- // > Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // > Phone: 033 1 42026735 /|\ /|\ / > From SMHELM01@ULKYVM.LOUISVILLE.EDU Sat, 22 Oct 94 13:10:12 EDT Date: Sat, 22 Oct 94 13:10:12 EDT From: Pen Helm SMHELM01@ULKYVM.LOUISVILLE.EDU Subject: Moose Comment: From the account of smhelm01@ulkyvm.louisville.edu Things that may be of interest: Oberon Smalltalk The old "Lisp Machine" from Symbolics GNU's recent selection of Scheme as their universal language I have no expertise in this field, unfortunately, but I was thinking of doing something similar (but much less ambitious) for my little HP100. I had understood that Lisp-like languages would make it easy to manipulate code as if it were data... Let me know if you discover anything currently available... thanks, pen % smhelm01@ulkyvm.louisville.edu From sfp@mpeltd.demon.co.uk Sun, 23 Oct 94 08:57:25 GMT Date: Sun, 23 Oct 94 08:57:25 GMT From: Stephen Pelc sfp@mpeltd.demon.co.uk Subject: MOOSE Project -- new OS ? > Now, if I could use other people's work, or join other projects (whether > personal, universitarian, or commercial (as long as the result remains > essentially free)), I'd be glad. Can you help me contact interested people ? The problem is, we are a commercial operation, so we *must* sell our work at a profit. We shall be selling implmentations at a profit. However, the low level language specifications are public. If you want help from us, it would have to be in return for source code of your implementations, or some contribution to the project. > > You should also look at the ANDF technology produced by the OMI-GLUE project, > > which was considered for use by one of the Unix consortia. > I'd be glad to. Where can I find papers (or code ! or netfriends) to > learn about such technology ? For the ANDF/DEPLOY project contact: Gianluigi Castelli ETNOTEAM SpA Via Adelaide Bono Cairoli, 34 I-20127, Milano Italy tel: +39 2 261 621 fax: +39 2 261 10755 For pure Forth portability, talk to Mitch Bradley, who appears on this conference from time to to time. -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From jvs@iconz.co.nz Sun, 23 Oct 1994 21:23:13 +1200 (NZST) Date: Sun, 23 Oct 1994 21:23:13 +1200 (NZST) From: Johan Van Schalkwyk jvs@iconz.co.nz Subject: MOOSE Project -- new OS ? Dear Francois_Rene >See ML for a typed functional language (CAML-light on ftp.inria.fr is a >free imlementation that runs on macs, pcs and unices). Thanks >Well, I mean no offense, but syntax is not what's the most important to me. >To me, semantics are quite more important, and user-level macros or parsers >should allow any type of syntax one likes. Maybe I've been a bit _too_ specific, but my problem is (as noted) that I would attach less importance to syntax if I had found just _one_ language whose syntax appealed to me! I prefer to try and see a synthesis between the message and its form (!?). Also, I have found (have you not?) that often when programming, you say "dammit what I really want to do is test and set the bit, but because I'm on an 8086, I have to say TEST BYTE PTR etc OR BYTE PTR etc ;rather than:- BTS BYTE PTR. or eg. on a Z80 (really going back a bit) you might want to simply exchange two registers, but have to do this via the stack because the architecture simply does not permit you to do so directly. The meaning is the same, but the form is different. Such examples are trivial (and make no difference to the final result unless timing is critical) but unfortunately when we are working in real life, especially with very complex programs, it may be critically important to a. have readily comprehensible code (and a small difference can make an enormous one - cf. the early space probe, I think it was one of the earlier Mariners, where a comma was left out, (in a DO loop) resulting in a minor course correction instruction causing the several hundred million dollar spacecraft to do a sharp left and never be heard of again) b. Define right from the start not only what you want to say, but how you want to say it. Let me give you an example. Let us say you are contemplating designing a complex virtual reality system, and one component is obviously the display of realistic visual information. There are several components:- 1. inputs which determine (ultimately) what should next be displayed 2. processing 3. display of the information. Now, a simple nuts-and-bolts approach might be to have a perfectly generalised and very fast system that displays an eg 2k x 2k pixel image in 32k colours. Let's now look at this ideal system in terms of idealised levels of processing. On the top level, you might have the user sitting in his abstract world and interacting by speaking/pointing to a part of the picture, or whatever. The next level down might be a complex high-level processing determining "what to do next etc". Then we have a lower level of coding (perhaps a sort of assembler level, where the nuts and bolts are assembled(!)), and finally we have the hardware implementation. Now, What you are saying is that what counts is the semantics, not the syntax. Ultimately, that is correct, but my concern is that if the syntax is not appropriate to the task, the semantics never get off the ground. I have seen too much commercial software that is complete crap because (at least in my opinion) the whole design philosophy and implementation is poor. I'm sure the chaps had great ideas and put an enormous amount of effort into the product, but somehow they screwed up along the way, and the end result is slow, clumsy and unattractive, and, worst of all, has intermittent errors that are difficult to trace. Great ideas. Poor implementation. Or, to put it another way, great semantics, poor syntax? In other words, I think that there is a minimum level of syntactic "correctness" (for want of a better word) without which your Airbus 400s plunge into the ground (if they even get off it in the first place)! The semantics work with this, rather than leading it. I also think that the buck has to stop somewhere. Let us say (in the above VR example) that you want to draw a line. On the top level, you might be an artist drawing an image, or an engineer drawing a machine component, or whatever. Lower down there might be the equivalent Draw instruction, and lower still there is the implementation that brings this about on the actual image. This is really what I meant by having three levels - you can have a lot more, but to me, three is the minimum, and in my plan you should see everything on level "2" as high level (you can stack as many levels on top of it as you want, in my idealised viewpoint, they are all much the same), and level "0" as the machine-dependent level (ideally all done in hardware, especially if speed is a consideration). Level "1" is the key, and it is here that I would try and succeed where C (for example) fails - I would make it in many ways resemble conventional assembly languages (BUT, as I will explain later(**), not perhaps your perception of assembler), but with the capacity for quite dramatic information hiding where appropriate. Here is really the nub. Unfortunately, one could sit and speculate forever about an ideal language (on level 1) but in real life I feel that you have to steer a middle course between the Scylla of making things too general (and sinking beneath the waves because everything is too wishy washy to actually work in real life), and the Charybdis of being too specific (with the consequence that you are rapidly overtaken by technology, and, even worse, you have to continually modify your code, indeed your whole approach, with the consequence that you go under in a welter of backward compatible amendments). I really believe that the decisions you make about (that filthy word) syntax on this level colour your whole approach to implementation, and ultimately affect the quality of the result. A painter may have great ideas, but if his technique and tools are poor, it is highly likely that his art will be awful. Contrariwise, if his tools are good and his ideas are rubbish, he will definitely produce rubbish. To me, the syntax and the semantics go hand-in-hand, and you cannot neglect the fine structure if you want the whole picture to turn out right! So, in answer to your >>> I think that semantics and syntax are equally important, and in a workable system must be considered as working together. I hope I'm not being too simplistic! I've mentioned how I consider the buck to stop on level 1, but have given no answers to the question of how to steer the middle course alluded to above. I have a few ideas about this, although I probably haven't considered things in enough detail. I would like to illustrate a concept that I could perhaps call "impedance matching". The basic idea is that if you want to communicate with a human being using sounds, you would employ a frequency range between a few hundred Hz and about 15-20 kHz. If you wanted to communicate with a bat, you might have to work up to 50kHz or more. But if you want to communicate with a human and want him to _enjoy the experience_ you would have to modify your signal considerably in terms of amplitude, frequency distribution etc etc etc. Similarly, if we look at input / processing / output in a very general fashion, can we not apply similar ideas, ie. make both the i/o and the processing relevant to communication with real human beings (or, in computer <-> computer communication, real computers)? Returning to my VR example, one can (with justification, I think) ask the question "What are appropriate level 1 constructs that will allow us to near-optimally visualise and implement a VR system, as a sub-component of all possible communication with humans using visual means"? You'll notice that I'm keeping this entirely general. Much recent progress in computers centres around eg. voice-activated control, - can we not look at the input constructs on level 1, and "match the impedance" to what is required? (I'm not making specific recommendations, note, just asking a general question)! For example, if careful analysis of the requirements of such a system suggests that a primitive instruction "get a phoneme" is a good idea, then have it as a simple construct on level one. The buck stops there. There may or may not be multiple layers of processing on level 0, but this should be transparent to the level 1 user, and also to users on the higher "level 2". We have considered i/o. Now let's look at the actual processing. I see level 1 as being completely general in this regard, with no committment to (in your example) list / array-based processing. But the same criteria that I applied above (ie impedance matching) should be applied to the choice of "processing" constructs available on level 1. Likewise for the implementation of a language on level 2. Unfortunately, in trying to be general, I became very specific. I was merely giving an example of syntax in my language, but, if you think about it, this does not preclude the use of e.g. arrays or whatever. I made no mention of handling of memory or whatever, I was just giving an example of a convenient syntax that I find fairly explicit, and, well, pretty general. (I have a whole lot of ideas about memory handling that will probably make you tear your hair out)! I think that in designing any system, half the art is in asking the right questions. So I have a few for you!! Q1. Do you accept the general idea of having 3 levels, as defined above? If not, is this because you a. feel that my "drawing the line" at level 1 is too rigorous (I feel you have to draw the line somewhere), or b. Some other reason? Q2. Do you have a "minimum component list" in terms of what you would like a CS to do? Do you perceive the CS as having "components", and how do you conceive of them interacting (I'm trying to keep this as general as possible). Q3. Have you thought about legible constructs for _parallel_ architectures? (**) By the way, I have some slightly unorthodox ideas about assembler. Many people seem to have completely the wrong concept of assembler, and this is often fostered by the totally incompetent assembly "environments" that are foisted on us by incompetent designers of assemblers (which at best work most of the time, but make IBM/370 JCL seem almost pleasant)! And assembly language programmers often seem to use totally bizarre constructs either for the hell of it or just to save a miniscule amount of time or space! A lot of the blame must also be taken by the chaps who design the instruction sets. CISC should never have come about, and would not have had _any_ chip designers had a modicum of insight into how to _really_ program in assembler! (This may sound arrogant, but I do not lay claim to any magnificent insights into assembler, dammit I'm still on the learning curve with no end in sight). Also, a lot of people seem to delight in going down to the assembler level and then immediately trying to climb back up again by creating really disgusting "high-level-type" constructs with "if then else" syntaxes etc. Yeeech. Assembler should be the easiest language to program in. Perhaps we can discuss a few ways in which this could be implemented (if you accept the "level 1" idea). > >That's prolog-like definition of a name according to what is input or output. >I like it. But perhaps the BETA way of doing it (having an x subobject, where >any object setting calls an object-defined function) is better. I dunno. Me neither. I think that I'm too stupid to use OOLs. Or maybe the chaps who design them are too stupid to advertise them in a way that the common idiot can understand! My supply of metoclopramide ran out long before I got into C++. ((Metoclopramide is an anti-nausea agent)). > > >But I think you're overstressing the syntax. I myself lost several years >for the same reason. What Iearnt those last years when I could see the world >through internet and CS courses, is that semantics (i.e. the meaning, the >contained thing) is more important than syntax (i.e. the aspect, the >container); this I've always known, but it somehow became clear and obvious >to me. Of course, badly designed syntax won't allow easy >description of the semantics, but I'm sure that semantics should be designed >first, and that syntax should be designed and modified to conform to it. >Please think about it. I'm talking from experience I'd like to share. >I lost much too much time thinking about the perfect natural-language like >or simple-constructor based syntax. See the above. > >What we need is a single language that can extend itself naturally, specialize >to any field of computing. Agreed, absolutely. If you cannot fit this into the framework of my ideas above, _please_ tell me your ideas in this regard. >> The solution as I see it is to keep things >> absolutely simple (a la RISC), and rigorously exclude any instructions/ >> constructs that impair lucid interpretation on any level. >Yes, and no (according to the point of view). >Yes, basic constructors should be simple, so the semantics is easy to >understand. >But no, everything shouldn't be done directly from those simple construtors. Agreed. Abstract all you want on level 2, _and_ design level 2 to make abstraction easy. Ideas? > Every program must be defined in its most generic form, >and the user will specialize to the form that allows best performance. Wellll.. Often performance is defined on the lowest level (level 0). You may _have_ to leap down to the lower levels to get best performance, but all the dirty work should be done there, and be transparent to the top level user who doesn't want to know about it. BUT if you have knowledge of all levels, it should be _easy_ to get into the lower levels, with helpful debuggers etc as a standard part of every CS, even down to arcane details of timing etc. I think that obscenities where you _cannot_ even find out what some components do (eg certain registers on the pentium) should never be acceptable!! > >Reuse *is* important. Today, reuse above language constructs is 0%, because >there is no secure form of genericity in commonly used languages. >A language like ML (see CAML-light again), allows genericity; but having >complete genericity in ML leads to verbose programs (which is why actual >genericity of existing ML programs is a compromise), because ML understands >no kind of implicit or partial information passing (which is called >Object-oriented techniques). I'm disgusted when I see that 99.9% at least >of code being written is just rewriting old stuff for use in a new program, >because no reuse thing exists. Hear, hear. That's one of the reasons why I'm all for simplicity, and at least the basic defining of what is on which level. Also, it is then easier to define an intelligent "apprentice" program that will help you on several levels, and ultimately even understand _exactly_ (is this possible??) what imported code does! At some level, all code should be lucid and explicit, and straightforward. >But also note that for reuse to be possible, security is a must, thus >type checking and more than that, program specification. If you can't be Yep. Agreed. Details of implementation are another matter. Ideas? >> 6. So I see any programming attempt as part of a continuum. There may be >That's exactly what I just said. We constantly need abstracting some part >of the code. There is no fixed limit of three or four or any finite number >of layers in abstraction (which is why ISO standards try to do with their >bullshit OSI layer model). Each program is well defined in its own proper >layer of abstraction; and layers are not in a total ordering, but a partial >one: if A needs B and C, D needs B and E, there's no reason to put A and D in >the same layer, or one above the other; they're just defined in different >non-disjoint contexts. Hmm. Q4. How would you relate this to my ideas above? The way I see it is that ultimately everything devolves to level 0. Level 1 I see as a necessary evil, and what you do on level "2" (and how you subdivide/extend it) is your business. >> memory and / or output ports. Unfortunately, we often seem to be driven >> by the hardware designers [...] >> THIS. THIS IS OUR STANDARD. WE WILL DEFINE OUR SOFTWARE AS SUCH AND SUCH. >That's even worse than OSI: just one big level of abstraction, with an >arbitrary choice of functions. I hope I have more clearly explained what I mean above (!?) >>If I go into a restaurant and order a steak, I ... >You too see that program specification is needed. I too have known it for >a long time, but now, I understand it and why it is needed (and not only a >toy). And timing specification can be as useful as effect specification, >as our computers will never ever execute programs instantaneously. But as >for the *exactly*, it is impossible. *enough* is quite enough. Absolutely. I would like to have timing considerations built into level 1. Maybe "absolute maximum time", "absolute minimum time" and "mean time"?! But keep the specs. as simple as possible. Life is complex enough as it is! >> Level 0: lowest level. May need considerable effort / ingenuity to ... >Yes, but this level should also be implementation-dependent, and reserved >for use by those who *really* want it, in time-critical portions of their >programs (i.e. ultra-fast graphics or signal processing, OS code, compiler >back-end, etc). Normal users shouldn't *have to* use it. And a code >portion could have several equivalents in several different low-level contexts. Yes, as above, but accessible if required. Also, where you anticipate (in designing level 1) that several options are/will be needed [got your crystal ball handy?] make this explicit!! > >> Level 1: The "assembler" level. But cf my example above about drawing a ... >Assembler is still in the implementation-dependent part to me. >Note that I do not want to forbid low-level parts; just to allow not to use >them, and to provide portable equivalents (thus a time-critical routine may >have several versions to run optimally on different hardware, whereas a >non-time-critical routine will only have a slow high-level version). In my scenario, the machine-dependent part is all on level 0. Level 1 is "low level" but abstract and machine-independent. The "assembler" is a symbolic "assembler" that is idealised to make it user-friendly. (Lots of ideas here). You absolutely CANNOT use explicit level 1 code in level 2. Such an idea (inline code etc) is an abomination!! >> Level2: The "top" level. Perhaps something along the lines of the >> incredibly simple language I gave you a flavour of above. >Your language is too low-level to me. Again, I love low-levelness (or I >wouldn't be writing an OS !), but only when it is needed. Sometimes (most >of the time, once the OS is written, if it really is well written), a high >level of abstraction is needed. "Abstract" as much as you want! As explained. I'm really eager to hear you ideas in this regard. >I really need someone ready to dirty his hands with the low-level stuff in >my OS. Uhappily, whereas I have many ideas, I *know* that this stuff is the >non-essential part of the OS. By non-essential, I mean that if I am to convince >people helping me in my project and later using my OS, I must have a *working* >version, however slow, whereas low-levelness will bring me speed and >efficiency but nothing that would make my OS better than it would be if >running on a faster computer (that would be available for a higher price, or >just by waiting long enough). Thus, I deeply need help from someone who will >cope with the low-level details of the system. Will you be that man ? >I cannot promise any success, just tenacity. I would be very keen to give it a bash. I can also be pretty tenacious. What time-frame are you looking at, and do you have any (no matter how tentative) specs on the "OS/CS"? What are your constraints? Note that I rather fancy top-down development (even here) so I would try and give you a skeleton working system ASAP. >You really recall me my previous self two years ago: full of good ideas, but >without an overview of the why it should be done in such perfectionistic >way, and enthousiast about small things when I didn't see the big thing yet. >Please do not see any offense in my words. I don't know if I'm older than you >(born 28 nov 1973), but I *think* (may be wrong !) I've made more errors than >you in the past, and thus have gained a little experience about how things >are and should be. No offence whatsoever! I've made quite a few errors of my own. One may have been being born in 1960. I'm glad that you consider me a trifle naive and enthusiastic. I like to preserve this image!! I probably am. Bye for now JVS. >(BTW, can you talk from your site to mine ? do you have IRC connection ?) Not to the best of my knowledge. JVS. From kyle@putput.cs.wwu.edu Sun, 23 Oct 1994 23:30:24 +0800 Date: Sun, 23 Oct 1994 23:30:24 +0800 From: Kyle Hayes kyle@putput.cs.wwu.edu Subject: MOOSE Project -- new OS ? Salut Francois-Rene, Voila, ce-que j'ai comme doc. Pas beaucoup, et, tout en anglais. Ce document decrit comment la language fonction. l'idee est tres proche a celui de FORTH. En FORTH, tout code est compose de mots (words). Chaque mot fonction totalement independent des autres. Il y a que la pile qui les lie (?). En TSOL, c'est la meme chose. Par contre, en TSOL il n'y pas de mots. Il y les messages et les objets (comme en Smalltalk ou Self). En FORTH tous mots sont definies par un array (conceptuellement) d'autres mots. La machine virtuelle de FORTH appele ces mot un apres l'autre jusqu'a la fin d'array. Menfin, c'est approximativement ca. En TSOL chaque method est un array de messages ou d'objets constants. Au lieu d'appeler un fonction direct comme en FORTH, le VM (machine virtuelle) de TSOL envoi le message vers l'objet en haut de la pile. Ceci donne un autre niveau d'indirection et permet le polymorphisme. Je dit tout ca tres mal en francais :-) Peut-etre un exemple est en ordre: en FORTH: : inc 1 + ; (ajuter un au numero en haut de la pile) en TSOL l'equivalent est un code array (un peu comme un mot FORTH sans nom): [ 1 + ] Si ce code array est mis dans l'objet traits d'entier dans un slot avec le selecteur `inc', on l'utilisera comme ceci: [ 3 inc ] Le VM envoi le message `inc' a l'objet "3". Dans l'objet traits de ceci, le fonction lookup() trouve le code array [ 1 + ]. Ce code array est en suite execute. Jusqu'ici, c'est le meme resultat qu'en FORTH, non? Maintenant, on fait un autre code array: [ 0 self at 1 + 0 self atPut ] (ajuter un au premier caracter dans la chaine) On met ce code array dans le traits object de la chaine de caracters avec le selecteur `inc' (comme on a fait en haut). Maintenant, on peut ecrire: [ "Gello, World" inc printString ] Le resultat sera: Hello, World Dans le code array en haut il y a trois objets. Le premier est une chaine de caracters, "Gello, World". Le deuxieme est le message `inc'. Le troisieme aussi est un message, `printString'. En executant ce code array, la VM de TSOL fait trois etapes. 1) La VM examine le premier object, la chaine de caracters. Parce que ceci n'est pas un type d'objet special, la VM le met sur la pile. 2) La VM examine `inc'. Ceci est un objet de type message. La VM envoi ce message a l'objet en haut de la pile (la chaine qu'on a mit la en etape 1). Le resultat de ce lookup est un code array. La VM l'execute. 3) La VM examine et envoi le troisieme et dernier objet dans le code array, `printString'. Comme en etape 2, le lookup trouve un code array qui est en suite execute par la VM. Pour voir ou on utilise le polymorphisme, il suffit de regarder ces deux code arrays suivants: [ 3 inc ] [ "goobar" inc ] Tous les deux sont parfaitement legal. On ne peut pas faire ca en FORTH. Il faut deux mots: 3 incInt et "goobar" incString Franchement, on ne fera jamais un code array comme j'ai fair pour la chaine de caracters. C'est trop debile pour etre utilisable :-) J'espere que ce petit exemple t'a donne neanmoins une petite idee comment TSOL marche. Actuellement, j'ai termine la VM. Je suis en train de dessigner une sorte de parser en TSOL pour TSOL. C'est ce partie qui n'est pas tres "fun" :-( Dit bonjour au 10eme pour moi. J'ai habite 18 mois au 10, rue de la grange au belles. C'est pas loin du 19eme. Ce doc est en LaTeX avec quelques figures en postscript. Il y a cinq fichiers. Tous sont dans un fichier "tar" que etait compresse avec gzip. Best, Kyle begin 600 TSOL.doc.tar.gz M'XL(""5$JRX U133TPN9&]C+G1A<@#M?6V3&[F1IK\>?@5N9(6E6S;5[#>- M%'NQEGHD6WNCD<+2VK=A.KQ%$B3+*A:X5<7NYC+Z?OOEDYE H8JMGO7MS"CB MQ(Z=53>) A*)S"=?41X^^?CAW??#QMW\ZF?[.1X='U\<'__JF'Y.3^C?T<7Y MZ&S$?Q\?GY^>G#W]U?'YQ?G)Q=GH_/R"/A^='C^E[W\^DMJ?3=UD%2WY:5NX M^\:5?N)GV\]_SWLYDTT>CY[^U&3^7#_CF9]N5JYLZH88\&>WKN>#T6C=_&4W M\?[3K3'CTEU/_6J5E;/=."]G-#0O%[>[7_]U=_OK\;)>9U.W&^7E[6UW:-W< M_GGTE]UNW#3VP6C_VVG5^7X\[HW(JLI?TS+C*E\L&_[KU_^G-V;ILIF3><:E M%^+L;CR9W[GB9T8'^LQXG57UIWQM1\/SU8K_U$''^+/)F\+MH"W/;68_YN76 M?FBRZ2?[;O(W-VWL]UFYV&0+AYFR3;/TU>Y_$4OM[[.MJ\=C8_7GT>5C.WKV M[,RVWQIZ!C_CB5ODY2X<">U@DD^*W"^J;+W<\@GMLF*]S&Y!W<*5F]7$$9&+ M7>5IE_3I*OODF%"B-YL4SL^GOFQPO,P-/&3ZSV95-LFG('NZS-:-JW9ORJ;R ML\VTR3U-:CXNG<6^;:%;M/[:U39O:DOSN#JO;>-M<^WC@'I@7_NJ65IBO?W@ MBOG0O)FYK+9S(M322=2N.]XNLRMG)\Z5EDYLDI=N9O/27B^SQKZQUWY3S&R1 M?W(&"RWS\I.E13-ZJEKY,O>;FH;ZP@VM_5>_J>PJ+QSH7&5;>Y556_K\C2R1 MS3QM<6;F+FLV%2WL*YNWI+ELNHQ4T5,?\G)*VRWIOSGHM@N?%37^ $/,=<9; MGSA[Y:JMK?/5FLZ4/MF0X%2$+.5L0"L7;MY8OVG"?N:NH-]=Y6SM5\[HU"M/ M'V35-*/52/::.JP)3M$'.,6A,6"G75?^BLB>\?>>5"0OL\+2\J[9,$D0!*:1 M-O&G90ZJ:"0]UOAFNW9FDM7T]+MWMB:YGJJ"F.6 MM-L%> %N994AUDT<'1=_L*DA;[3:QW0=ZT4Y5G[F"AHCQZHKF82O4SHP$J4F MG),3AI) Z)3T+,;2-&Z103#-(U>OW33/BF)+4Q!C\?6VS%;YE#\C:2X7#E0E M3SVV?NU*(G=M2&.V=NWK.I_D1=[D3K8^]W1XH+(5SNN<1)E.L\FG] 5Q)*>3 MG3H#B;27__ / _MA14LV6?$)\O0JG],)TU&)#D ]EGRR2T<\ 75VYH_RYFA+ MLEH3+TPB<__#^!U:@K&2B00'!#4Y69G0W;KK!IH2]*3M7GEBIXIA5V)%. MG?%>MRRUF[R8\0(-& _Y-WAVXIN&5&&S!N5K[ROB9;U9KVDSGKR]B6H6CE"@BV3>G$F']77V9H@ ME$ C+PI;;4@@2H*_PM4U'<**0(L04XBIO:V)UT11Q*9Y14Y.E<%NTR>&Z :R MD>:6LV([$&VLE_YZ2IA06U8+8.RB'K!"_(V>[J ')-BDBJV'3U"P)J2I2)ZF MR](7?K%-<24CJ%Y$Z339[ I*Q!*%)7LZX&Y(3'(1 K":8)H,634G=R.BGV$& M8L: 8A '>K2!^.!0\ @)-W:>$<]7ZP8\(>G*&CH<>Y77&]H+S4 MY94O17[HK,1ZM:JLZ B+TN!OB*;]5/KK4KF=1;VC V2]C3O#"9+Y\(RD(+MR MZXV*!IWRQ#&=]IMK AAW!+'ZIL<6 TQ(R66G@)>JM\2J&SL#^%1V@2T2!U@% M6&%765Z2&+AL95*M?5>V:OJ;VGX3#.,W@ELDG7D3U%<7KDV^6KE9SCR$]F4U M2=MT2M(H@E_-KLE<[4\^+S*:A8"?YR49J\-C.8P=^2G$D7_?Y)4+<"601Q(B M_&=-,S,:,&U:5*J9Y^4"0)\UF87A&8@&"VY^K7@T;^ZZA-806#H6"O) MA#\&%_EAL;UQ%[Y,G*5FN1'1H!6P-UX!#Q'CYW!.?3?V5NWOX+*H&]=Q7WA>V'+/Q_L\.J!P#@D.&_9E8S+[$8D,5!O^\$,X(#&K-P H=& M[."&'0^20+@ P9?3 .Q]E6$"9)*WV(<(\NZR+:T9P&QJ2/>Y/!^"1/7M(UZ M0YYH5B>NB_ P8'"YB&+)3J2;TYP-(PN[T2L*=J(C"'*9S>O*T?^W-)CX0(P: M0+O9J! ;#&P%+)$K_6:Q9"*!S&Q6L#M+W@9[#P$(AB)5\YQ\7>$_*Q% M'$&W6!)H&ASF%6S)Q*FLL/X1$JS(]U.P :612Q1AP'9T'QH8%I*F9C?IC@D1 M7*@LD&&=6=47D7(P7#&&H]Y6Z"&1! 2W*ILL(#R[6ALZPD5634#7E*8B#2,1 M4UN=&(VA/O\*O@)O/M)(:$]R3F/H03HFL:#U<&]!["M:$0 ^H^ 1N?GR;,_O M&XIF1/K-![CD:^?Q^,RS@+.GVB.?)F!^D72V'&=],#AYBF#K, V-^[[K#>_/ M)>>WS)",#=$K%4<2?[,Z4 M42254G ,;@2)**-M\#&F-!7[V\D!U74KP74] M;A*K3QH?DD(4 S$,#*?"-0I&"=]KYGK>J);4['&IFHBUFV8;N%RD4Q2R)P$' MB>Q5[@L8V";HE^$':4V2K!*G=%3[H[TG*7JT+,_J7!+S:1J"4@1$B+%8>U2V M8(C$@E_YXHHA@@!C4^#4%MEDVX"-0&-?2WR$(S9+7U7Y?(L0K53O7:-3^\@- M"98H(GI,=/Y ($Q?PTEEF(%L.< B!>1F7]EA7R82/9/0 M-$>U(S0K/^,S0D MJ\T:\<5\4_+IT0FW+&#$P_,"IK58Z72:01>,$A/%C@X<2(H1(140*N$;_.+2 M5>HR1*KI(9,(UV?AA-=2#T2P=.Y]LZZ(Y8-TR$1MJUC*CIU-APF=[.+ /*H# MR0F'K$ <&!"Z/SGY:GDAP05OBW[7W2)Z[R/)]WWQ"E:)P4IDN-ZPP\F.)H4D M\->(E/9DV-RVZ,$''\DGV6$A[ S7LU)2F3PX^YIKX#3)VJ\W10:0RDK5.9D8 M0@'_#GIRDT'*V=T!W2:=D/>;;(Q"SF)#(/]Q*H+PGK";\3%Q,D!IQW@P]H3I MQ#*&8+\-LY&,L)5] M)"X3'/=! "["VF8Z?*P2>TTFK":0RV:!>40?4D\UH;5#=FU" 3!;[B6GVR8( M@.&9L0557RJ5^Z[5,V\]>4G8W?0.>6GS(R$CJ-(SY_2N(UBZSN#"(5>9:\1' M6+QQ:KY)4!+.M[X"AI-/'N*_%6?]E)>%SV9"/2)FSO:(5D3/B?^6^,-(],5N M$Q2?9R*NYFOX6H,4G+$VJ@9-3&>*:,1H%!XGA(:6+3%I@3V*FS411(0V-[K[;TC*@BF/KF1/TI5-H0[&\[L@(@UTFB8F0?.D<4@T+Q<$?^YJ VP-]KMHH3UUS# M(>V* .]4#2/)3!7L(IL9HC-&1Y&IW7QQ]/*-2J;ZH%F5<;9W+)&_ ^WW7S7]1-. T+A!*0*Y$'O(\P?DV MY+%>4WS!F +EB( # K%]G+6Q#]_*REZ7B/,1%[)$%GFK49) \D M40;"+Z $$9CD.O=,PT=.7V!G8.'$$:K--+//Y&/_':R$X!(^$1>0_P/4#WD2 M221B.(2T%Z%J6$0/J2.K4S*;B'##H==GTLW$NW9?Q,/?^VL$)2H:G$Q*]MZ654\/>'.G%/U M??88]@V"UU*J4QJ%7V2*14+3H5932*P\:F*)YY=S,KQ2;-/&DD.B%FQT)>AV-/-*.0:?U.?%D MNTLC9F<<@=&CPZN."F1W#5O]=&J)LC7RG#L:J1)Y1*LPRG\WHS#+= M@1LM_QH"0/,&YBG=D9Z(F+4!DLLOP]=:J7K!'"SIF\&5=NOKND;:?2^'@8(6S.PV[_O&PFZ[_$2JE^.07=U6W[<5ZN M-PWGMH;TX' T7!.7;O[:)$. 57O/3;,U:\BE\I^+=%T%B6.+;.**/9(%!)5: M8\QW?162 ZL#6FW8+\WKKEB'M)/!L6R5V[Z4("FD3Y:H/B\B=O )H! D =+ M;O84N,V"ZUET\AZ$1P12/%P K3;)&=EX1BVE/]D1G?S7CBBAZ*X32K_N'= / MOG%!)9 :PZ%HE1D,(O:^#$E]8NZ+%$??!Z-2,XY>DE4CW*1)^;>C")FM"T!8 M2-BN,3L:#UR%\J1E_$$:NE,I')B/FVKB[?NL)D=_H%5#]ME9D=F.AP-_,L6B M$9Z5&!2OIE4^<4:+"9)>BO&@ @S#V;5ZS%M.$10$.'3#>?2GV-F M(^5@;!?&O17Y6FHG[2>,?R%VTMAZY9J,'PX%JLB5Q%/E/)6.BRY#;Y+^1"%5 M%HFEK0%R>!CG*U"E03CB:'\< "(4"%K%SD*.0-FTVB'125M8 M"A(;"'?5%?A6]SI!0I8_;"QX)9_IY,!"!9=7'@F&/C9M9 3B(V1PD9D<;3ZN MSIH1QUZ46YD-J %O^"HK6!Q][P&6LU"M:6. K.EM1K++K#(:+ NQNE8\\#)F M5<"0)(*@4WDASTC5ANPPQ[_PV7IXI'X45\T9DWVI."E!BPE"*$5[-KF62SP0 MV<:)#<*C+Y%I)2',MK7&[+#]=<@8F/ $X@LQ[.)3AJUQPC^L%E(N4$7R$:L- MJ2G%Y!0K8>HR+V*]AU,\P0Y^A&D Y&_*_-\W6KTNN3SIXNZA-6;*> ,^=X _ MUEXDI!!QK1JJR( M1(31FMI M_):.SKS=2*ZXM^4@10,[:<5K$/\%?B M,.%:;8+T8SG(>D!,.6T.Z"N5;CYT*=H(8TVTAZ%Q@G,3#&0"CHA; YL9?:)W M8925Z$%C$TG3DAF;%6YFDS8U+YM 3@%(VU,H:2#FBR*I;--Q6TQH>:8NLAO M5BN5/3T2/?TVY C,*G'6VI'7$W,F3,I60<)-1\)#@T&CST,$.AF5J)X & PK M.-U&6/XGCIJ0ZI0\L$A'ZYV"3;LQ^;H,I;=![P5C.'VS-95K-E79;;14EQ"L MV$P"-_Y%@//'6-%B;&@_$7<[I&AK/HC0S)?Z*6AQE&S')5N.Z.V%J8F+ HP& M:6S8O"3+&QHM >4MB(FE39C8V75]Y[8[9$>K'&LZ[61&"CF*TIR.BZ@EK&NY M]T->*,M:M84)5F GT>3N49IQ7F0+]GE1EQ5+*-2R9+QVU\:W,*R"-0,[8S:M M76&?#K@L1,B+^J[A(C''*\!D_^9201/.[,$GE* 2YYE1S,2D8NSV5H&"I9'3R;8[KYQAP\1RR_< M02;-BRJ9B12DG55<24HC9,[4\P./%@NZK"410A.=^!D&9@ M+"]HFL0,(;#B_>@6TZ"V\%-&/6ZT[$T39V"8W"^L:84VR2K<46IK*C8]87.Z MMXRAY#T%1ME:*[J,>]EL)F94Q\>F7$DG;5!E%$S&/*76H2797?==.2/AWAVR M^49/]19.'O]ZAT!D'":RBR=#$N<(F5SD$6CL-$=$'AKI>8SJ6W#$N (K'5TA M/ ]_2R/1Z8F=4,20.(HH/_!MC%8U8"32=J')EI?XMW^;^0U9MM_\AO;#X0JG M=YF$EG#ABXE\X=(+N>2L+BT,]714?%\6FK?J_MZCJ3E?!)KG3CMC"!-I!/ID M1$Y,# K"Q,'$^Y)421+1J%_J4K .(>S!?%<(F-%BF0W-/D;+E&AUTLE;PF@9 M7W+/3YBN'Z6\1L!K%X2II9$QQ+(0]D@((/%-'7;)R0$M^\:L;$QXB3,;V%>C M [!I^:%C]QWB.I(^+\18,C8M77;%MBZBAE"4UWV!B#1W=<,8Z3% XTK/IQ_T M:-L3LRQLQ @$$PU_%"R.W14EIUJO7(K:-&DR(KFBP=_L"W]7OOJ\X1Y]1YB< M^TKZX<4IB_%-.!<<9D!RRV/'3ZC3O'BZW2#K]+0V=-)!+O+D-_"M'U+VM?Q@XF<8/T2X4+4SO. M!L$@IM"OG%.'5W*K[;-J $(>#&WW:1R]1G:-A9T^S*K%9J4YIRQQC'T5O4JY M&D.BM+_5&!C?AY7IM"%I$)W ('@,B*8K:/N"*A9Z*H4^=]>\/2H4=1SQWFK].J]S:VVL70 M3+ZSCW->P$>_F@T%IM[8_B.?!,N M%")/KQ\P K(04 1:D7G5"TQ)IJ1GH,3TP$"I$6JE@3MMF,$U1?HN%%=>?+A\ M\\:V\X<$D)#,19%R4Q1']!U7F2 1TN]7<0+Y,K@UB0AW9,"TEE>[CD 7-Z*# M(IBUO7UP8I(9>:]\1]X1RW)BI[1"D,RAMXJWRBDHM2F&S9KHJ,1'-9V ]IE- M.%V_*7MN'\W]+?RS.W@=R9,##[4ASG3<1>/GSK?OM\ IK=I>!4F.IH5T&,MP M )=A ;)'DN$)]V&@:P!/VM]F&DL<8M^1DNZ6@Z!<:,,G=RU>C9*I]S<.0](> MSHL$.;0H)+]+XUB=]/_'FQ$16PRP)>ADUINI[8"1BPY=XQ=:>Q$,E88[!6=( M.;AH2625]EY7!\_0D(@E*O:U<0"RKNA&(VFS1]'H')--=X4+@!V:I1Y+31*/ MTS=52&/U61)(O].$VVC".1_:[KK62FAD7US,ZF)<*&B3 H,T3F_C=VZ JI?( MA*A'JE4W:26+\I@FBC0;<]=SW#7B*]3'8;HTFYAN.73JH?M85NQK76&^O5J/?CI-KMHZ#"3M\EMFWS3% 8N)+J(1\)2JVS/ "R MZ3K/=1(UQ= S^-6Q64@=&%7UMJ"LZA9$D1.]P1/9(Y1E7<[+!--8.[Y5+#"> M1;(#DR*F--.EFN@X)A3[=?% #=]^'J2+A;72C* DM\B-\E.^!=C>P]39I?:G MC.)O8]S0L@@3;%:"^ZNL^A0B!R<1A:C9'9R(*4<].Y/LO+/7P-CP;9IHJ]L# M8L\+WR0--1+3\!$+CQDT1=U(0.3&+E2;,W'L7@'\N"+8_9CD^[)?6XG"KPI4 MM^4M/19.QW0:K&.!K@U^\C)I#J?5/[08%.).W\$6<^?Z:K#:^RUMW47KFG(O M-1Y$VULA^"A]Q77.(22K&E+LF5>Q'K>W<7,/<@@SG?,6%JPI,%7[,^' M2IIE5MU%6UK[8N\K2NMG!#4/'2SA>ERX*RP=J](9<>U%_&HN>U44#<)G%/35 M"RAZ#;IN=9:X,]T427H;02WJ=2&>K=7KY.)5S.:TD-"=LO&Q_F2T8"$3R+59 M[7B)%[EUVN# M(K'GYA[R?AF ^*'3%Z>1(MP.HK 2V@^GG'#3306"ODQJ8ZX1U_ M--Y-3KC12W)P(((;UG4[62B@^?D\UL"BW+QA*]3PZW+:6708[G1RK)ZOR7M 9)2LN<*(0#. M5<.T294?U.DKQV]L$+<*Z)"TQ>)-,!DGBF#_ M5CGCL^1/$W@86)3_"DY+(%6BS-?KQ*7GSF%SF>")QM-MC!O4H^/SAK!3T@Q2 MT.NN%(.])'7<%IL%8'#Z<*):@H?AI5AW.0#:F8D[ZW+%B'=J'G%14Q(1^K*+ MQ]K'!<]3+FQ$!J3M7!3DSOMD2XVAAD .[K@1%STEK8K7)C%@>"VYASHY4?C[ZG#=&=)KLU%B2K2XMY>-Z68L"W3S\ZU)"(U]$8E>E3&] L8OH;K+@G+BH4[S&7L"ICID7+3$>N-8 MQH5*!]=F))SN26KP0;(Z"6&#KR*GH&J*CNC@>AY%!T;A.58HXKMUH@)\9 DF M\NLU.1A@9H>0-FRNV>V2_JR^1G!2*(8;G%35ESU)_8:SRF7T^Q,K/=?W;VEO M>UOZY[:93L9?Q?GN=,]<"=*J1-)"<&_58!:.T:3'&&#C4>KBE#-W,^A,%H8' M-CP.9Z%6< #S&\RUK*5%&-*:8RT--QT):C-B&G<$9P;O^\NGRS3Y@!?LM:6U M\)JIBB\\Z(L.ZJ0/AK/D_/*61!M%'*-'?Z><0[]#D_)>?Z>^22&\#T*I#ISI MN[7ZQK:0N4[O'\CQS^5Q3G5F3E,G:*I,44I*6-.RV(\PTX9&? M!^W @<("A$OCN+2(MV!M=37N A%<"OZ_UHF =YTZ3LO -N< ?P.R!7T!6UQT M,7JR*V>0.*7FS7POT2QOWKMNJ]?WZH4)+N!ES]?V9>R-"IW2T;7NY+)-/PL< M"4U[;VIC7L1VG)[_'5XJM.VI;(*%W5NS[9N9LOH3WJ-*TBB_)5>.\VE _S^^ M#>Y/^Q*:E4,;9%ZOX.#0%AIZWM;$-6[S9+#E/^05)D4^W28N%-XLUK ''AJL M(T6ON)WN]^A9%<)BK@9SOD_>.?:J34OQRT[7#'\WO2=>XKT.[24J&OEP7/HI M\6+W/_B/]-VFNY?)'[?*MO8]J.;0__CTS-] M__/ITZ=/^?W/9Z=XE?)/3\K^SU?^_N>'__W]AZ,7,S]Q1R?#8_OJ_8?7^,4\ M?/@1KQ%^;I\TJ_63&Y*/(_KO>'1R1N>/2$Q M^M:^1Q:>[VK;XS":OOV.Y/JY_; I[3N2Q)-3>W+R_/CD^?D9OQ"9!K[&E#B) MWZXW#?V??=2^)/DQ??^.7X'%*V_9-?OSY9U]_E(./XV.*=4J2@2I#[IOE6[L;7GQK MA]^>V^&S>\8]P[:&I\_NY^ Q9J.91D_YOWM&CD#:\/Q^^DVT\N4K MZ9_ZT'#I$)45>EKE4@?,]-G.4%4H9#9E-&,$N2R%7QC3KFN80*CZ-%O;^,?? MR#\W1Z/3"\+-T=-S^O\$1V7-;VT['CXC6#F2?]#R[WI M^3,[.GMF5_&WPB*X9-VJ[:(R#PGGBBV>V1_^],>&/Z-!A*XK^8U8?>]PS">S M\V]WS/[D(T*"HS_@;?-XD983Y#$TSLI@%@^RC MEYQSQ366[6-&)VE'8JX@GK;C[Z;E]+.TO.#+HC\' M*1?WL.7L3E)^20J>G=UU,+\0!:T@?RD>L$;<3<%O?DDF?-EC>/99"O[?F1 @ MUWQIW_;P\^,_^_'?7YN?>HT?B?]&%VG\=_&4X[^+B[-#_/<+_&A!8)WSA8/; M1\>#X\E+G^?KL['E+, M2(Y/7M*@AUI_6%1^L^;_K9J,!N)_"V&#K&^V]O M=O+5+OWNEC=QLT8'+UR \4V8R-[PCSQJ^='MKEX7&6^"2;T9;ZVU#^WWV4?W MOU&&_U#D]-L_F?$"P]N=R(J[AP8O19J7FY5],/K'T=-QDY?;L<.%R?;CD^,Q MOYR1/^\\<'(VECH37E6_]]BS<9%5"[?_V.G9^/OX3?+YV6C\_8L__.Y5> *O M4UIN:-P\[_T?IIO6S)0'ISAR^8-9AV<_L]WDF'D&7''X[8-1X*@0WD_&+P[=/'CT;G)X.+L_/' M7:7Z1>QG@O\G7RC_1UA_'O'__/3TD/_[!7^^?/[O^/EH=,C_'?)_A_S?(?_W ME>7_NLFZIW]?;J\=_NP_,?R0VSOD]@YIK?]*6NOO).%G$(286/L)[?^^__]E M\S_G9Q>:_SGX_[_$S]^9_SDYY'\.^9]#_N?_G_S/X>?P<_CY>G^^?/[OT/]W MR/\=\G^'_-]7F/\[]/\= bit, but because I'm on an 8086, I have to say > TEST BYTE PTR etc > OR BYTE PTR etc ;rather than:- > > BTS BYTE PTR. To me, this means a hardware abstraction layer must provide abstraction for all those kind of bit operations, where C (for instance) only provides ands, ors, xors, and shifts. Being able to do this directly on registers also means this hardware abstraction layer should still allow hardware access when needed (much like _AX statements in turbo pascal). But as I'd like to write portable code, I want the capability to have multiple versions of the same procedure, for different processors, and a version without hardware dependency, that the compiler will have to optimize itself. When possible, I'd also like to give more or less info to the optimizer. It doesn't always need exact register allocation directives (on RISC computers, reg. alloc. is done much better by computers than by humans) GCC allows such things, but in a clumsy way. > [...] > Now, What you are saying is that what counts is the semantics, > not the syntax. > Ultimately, that is correct, but my concern is that if the syntax is not > appropriate to the task, the semantics never get off the ground. I also said that the syntax should be designed to make the semantics easily accessible. I never meant to say that syntax is not important at all. Perhaps I've not been clear about that. > I have seen > too much commercial software that is complete crap because (at least in my > opinion) the whole design philosophy and implementation is poor. > [...] > that are difficult to trace. Great ideas. Poor implementation. Or, to put > it another way, great semantics, poor syntax? I've never ever seen any commercial software with good semantics, and syntax was even more horrible. > In other words, I think that there is a minimum level of syntactic > "correctness" (for want of a better word) without which your Airbus 400s > plunge into the ground (if they even get off it in the first place)! The > semantics work with this, rather than leading it. Ok. I agree. > [about 3 levels of abstraction] ok, there is the machine, the software, the human. But as you said in your previous message, but the software is infinite in diversity, and sub-levels. > Here is really the nub. Unfortunately, one could sit and speculate forever > about an ideal language (on level 1) but in real life I feel that you have > to steer a middle course between the Scylla of making things too general > (and sinking beneath the waves because everything is too wishy washy to > actually work in real life), and the Charybdis of being too specific (with > the consequence that you are rapidly overtaken by technology, and, even worse, > you have to continually modify your code, indeed your whole approach, with > the consequence that you go under in a welter of backward compatible > amendments). I think that with the "have multiple versions of the code" technique, we can have both the advantages of specific/optimized code and generic/portable code. > [...] > So, in answer to your >>> I think that semantics and syntax are equally > important, and in a workable system must be considered as working together. > I hope I'm not being too simplistic! Ok ok. They must be working together. I do not deny it. But these last months have been working with a purely syntactic system, which had no designed semantics, and where features had been added and added without a general plan, ending with a syntactic monster (if you read french, I'll send you my masters report). It's just unusable. So what I say is you shouldn't add syntactic features on the fly without studying the semantical effects, and that things that appear syntactically simple are unusable semantical monsters (like this B stuff I've been working with). Not to say that what YOU wrote is such (I do not know it very well, and it did not look that way to me). > [...] > I think that in designing any system, half the art is in asking the right > questions. So I have a few for you!! I think it's 90% of the art, as the right formulation of the question leads to the answer 80% of the time. > Q1. Do you accept the general idea of having 3 levels, as defined above? > If not, is this because you a. feel that my "drawing the line" at level 1 > is too rigorous (I feel you have to draw the line somewhere), or b. Some > other reason? Well, yes and no: to me, the level 0 (hardware dependency) is very limited, and expands very slowly. Level 2 (human interface) we have little control on it, and it's not the algorithmically interesting part of a program; let it be automatically generated when possible. Level 1 (the algorithmic part of the software) is infinite, and contains an infinite partially ordered only hierarchy of sublevels. > Q2. Do you have a "minimum component list" in terms of what you would like > a CS to do? Do you perceive the CS as having "components", and how do you > conceive of them interacting (I'm trying to keep this as general as possible). As for a minimum component list, I see none. Well if you want a minimal system for computing, then I'd had enough to allow lambda-calculus and end up with Scheme (i.e. skimmed Lisp). If I wanted a portable system, I'd first abstract level 0 completely. If I wanted secure system, I'd first add a type-checking system. But I do not see a "minimal component" list independent from the task to program. Again, program has its own minimal component list, from which it builds (say, by disabling function definition inside the current one). What I see is the infinite hierarchy of level 1 modules, each using lower ones. I also see some of these modules recursively defined, with multiple sub-objects tightly interacting with one another. > Q3. Have you thought about legible constructs for _parallel_ architectures? Yes. first thing: do not use global variables when possible, so that distribution be as simple as possible (without some global thread being ever accessed). Then a generic FOR construct with a variable taking all values in a set, and a recursive FOR construct to use recursively defined structures, will provide distribution. Annotating objects by their expected/measured size (in memory/time) will allow automatic scalable distribution. For optimal thread migration, all thread information should be minimal; a portable low-level language should also be used to allow distribution on heterogeneous architectures; but architecture-dependent versions could nevertheless be used to allow optimal performance on common architectures. > (**) > By the way, I have some slightly unorthodox ideas about assembler. Many > people seem to have completely the wrong concept of assembler, and this > is often fostered by the totally incompetent assembly "environments" that > are foisted on us by incompetent designers of assemblers (which at best > work most of the time, but make IBM/370 JCL seem almost pleasant)! And > assembly language programmers often seem to use totally bizarre constructs > either for the hell of it or just to save a miniscule amount of time or > space! A lot of the blame must also be taken by the chaps who design the > instruction sets. CISC should never have come about, and would not have > had _any_ chip designers had a modicum of insight into how to _really_ > program in assembler! (This may sound arrogant, but I do not lay claim That's why RISC chips were designed (see the ARMxxx series of commonly available RISC chips since 1985). > to any magnificent insights into assembler, dammit I'm still on the > learning curve with no end in sight). Also, a lot of people seem to > delight in going down to the assembler level and then immediately trying > to climb back up again by creating really disgusting "high-level-type" > constructs with "if then else" syntaxes etc. Yeeech. Assembler should > be the easiest language to program in. Perhaps we can discuss a few ways > in which this could be implemented (if you accept the "level 1" idea). If you're designing an new chip, that sounds ok. But if you're writing a computing system on existing architectures, then I think it's too late to correct the asm. > Me neither. I think that I'm too stupid to use OOLs. Or maybe the chaps who > design them are too stupid to advertise them in a way that the common idiot > can understand! My supply of metoclopramide ran out long before I got into > C++. ((Metoclopramide is an anti-nausea agent)). C++ is definitely not an OO language. It's a big bunch of crap, built over C to make it look-like OO. To see real OO, look at Smalltalk, SELF, and BETA, or Eiffel, or Sather (but BETA is seem better). > >What we need is a single language that can extend itself naturally, specialize > >to any field of computing. > > Agreed, absolutely. If you cannot fit this into the framework of my ideas > above, _please_ tell me your ideas in this regard. I think your ideas are ok. > >> The solution as I see it is to keep things > >> absolutely simple (a la RISC), and rigorously exclude any instructions/ > >> constructs that impair lucid interpretation on any level. > >Yes, and no (according to the point of view). > >Yes, basic constructors should be simple, so the semantics is easy to > >understand. > >But no, everything shouldn't be done directly from those simple construtors. > > Agreed. Abstract all you want on level 2, _and_ design level 2 to make > abstraction easy. Ideas? That's where the OO design is helpful (what I call OO is not what C++ or commercial stuff present as OO): that is pure, completely parametrizable generic abstraction, with multiple numbers of more specific versions that go down and down to the hardware. The user will just ask for the abstract construct, and the compiler (either computer or human) will choose the best fit specialization for performance. > > Every program must be defined in its most generic form, > >and the user will specialize to the form that allows best performance. > > Wellll.. Often performance is defined on the lowest level (level 0). You > may _have_ to leap down to the lower levels to get best performance, but > all the dirty work should be done there, and be transparent to the top > level user who doesn't want to know about it. BUT if you have knowledge > of all levels, it should be _easy_ to get into the lower levels, with > helpful debuggers etc as a standard part of every CS, even down to arcane > details of timing etc. I think that obscenities where you _cannot_ even > find out what some components do (eg certain registers on the pentium) > should never be acceptable!! I agree. But all portions of code do not need the same attention and optimization; I really think the "multiple version" stuff should be used. Automatic version translation should also be used, so that the user justs enter the one version he needs now (using the proper abstraction), and a generic version is generated. > >Reuse *is* important. Today, reuse above language constructs is 0%, because > > Hear, hear. That's one of the reasons why I'm all for simplicity, and > at least the basic defining of what is on which level. Also, it is then > easier to define an intelligent "apprentice" program that will help you > on several levels, and ultimately even understand _exactly_ (is this > possible??) what imported code does! At some level, all code should be > lucid and explicit, and straightforward. That's also why I insist on having code specification in some version of code, so that we know what the program does externally, without knowing its internals. That's the only way of reusing code you don't have time to understand. > >But also note that for reuse to be possible, security is a must, thus > >type checking and more than that, program specification. If you can't be > > Yep. Agreed. Details of implementation are another matter. Ideas? > >> 6. So I see any programming attempt as part of a continuum. There may be > >That's exactly what I just said. We constantly need abstracting some part > >of the code. There is no fixed limit of three or four or any finite number > >of layers in abstraction (which is why ISO standards try to do with their > >bullshit OSI layer model). Each program is well defined in its own proper > >layer of abstraction; and layers are not in a total ordering, but a partial > >one: if A needs B and C, D needs B and E, there's no reason to put A and D in > >the same layer, or one above the other; they're just defined in different > >non-disjoint contexts. > > Hmm. Q4. How would you relate this to my ideas above? The way I see it is > that ultimately everything devolves to level 0. Level 1 I see as a necessary > evil, and what you do on level "2" (and how you subdivide/extend it) > is your business. Perhaps I did not get what exactly you called levels 1 and 2. > >> memory and / or output ports. Unfortunately, we often seem to be driven > >> by the hardware designers [...] > >> THIS. THIS IS OUR STANDARD. WE WILL DEFINE OUR SOFTWARE AS SUCH AND SUCH. > >That's even worse than OSI: just one big level of abstraction, with an > >arbitrary choice of functions. > > I hope I have more clearly explained what I mean above (!?) > >>If I go into a restaurant and order a steak, I ... > >You too see that program specification is needed. I too have known it for > >a long time, but now, I understand it and why it is needed (and not only a > >toy). And timing specification can be as useful as effect specification, > >as our computers will never ever execute programs instantaneously. But as > >for the *exactly*, it is impossible. *enough* is quite enough. > Absolutely. I would like to have timing considerations built into level 1. > Maybe "absolute maximum time", "absolute minimum time" and "mean time"?! > But keep the specs. as simple as possible. Life is complex enough as it is! > >> Level 0: lowest level. May need considerable effort / ingenuity to ... > >Yes, but this level should also be implementation-dependent, and reserved > >for use by those who *really* want it, in time-critical portions of their > >programs (i.e. ultra-fast graphics or signal processing, OS code, compiler > >back-end, etc). Normal users shouldn't *have to* use it. And a code > >portion could have several equivalents in several different low-level contexts. > > Yes, as above, but accessible if required. Also, where you anticipate (in > designing level 1) that several options are/will be needed [got your crystal > ball handy?] make this explicit!! It should be accessible to users *but* only in a way such that it can be proved (automatically or manually) that their program is correct and won't take over system security. This can be done if each component is annotated by an exact specification. > >> Level 1: The "assembler" level. But cf my example above about drawing a ... > >Assembler is still in the implementation-dependent part to me. > >Note that I do not want to forbid low-level parts; just to allow not to use > >them, and to provide portable equivalents (thus a time-critical routine may > >have several versions to run optimally on different hardware, whereas a > >non-time-critical routine will only have a slow high-level version). > In my scenario, the machine-dependent part is all on level 0. Level 1 > is "low level" but abstract and machine-independent. The "assembler" is > a symbolic "assembler" that is idealised to make it user-friendly. (Lots > of ideas here). You absolutely CANNOT use explicit level 1 code in level > 2. Such an idea (inline code etc) is an abomination!! To me, you can, but only if a specification and portable version already exist (though these can be automatically generated from your inline code). > >> Level2: The "top" level. Perhaps something along the lines of the > >> incredibly simple language I gave you a flavour of above. > >Your language is too low-level to me. Again, I love low-levelness (or I > >wouldn't be writing an OS !), but only when it is needed. Sometimes (most > >of the time, once the OS is written, if it really is well written), a high > >level of abstraction is needed. > "Abstract" as much as you want! As explained. I'm really eager to hear > you ideas in this regard. I already told everything: you have absolutely high level abstractions, annotated by lower-level versions, so that to be actually run, an object must be ultimately build on level 0 (though as intermediates, there can be arbitrary code, including interpreters, inference machines, and any kind of inefficient but generic things, that could be further replaced by more efficient things, *if you need it*). > >I really need someone ready to dirty his hands with the low-level stuff in > >my OS. Uhappily, whereas I have many ideas, I *know* that this stuff is the > >non-essential part of the OS. By non-essential, I mean that if I am to convince > >people helping me in my project and later using my OS, I must have a *working* > >version, however slow, whereas low-levelness will bring me speed and > >efficiency but nothing that would make my OS better than it would be if > >running on a faster computer (that would be available for a higher price, or > >just by waiting long enough). Thus, I deeply need help from someone who will > >cope with the low-level details of the system. Will you be that man ? > >I cannot promise any success, just tenacity. > > I would be very keen to give it a bash. I can also be pretty tenacious. > What time-frame are you looking at, and do you have any (no matter how > tentative) specs on the "OS/CS"? What are your constraints? Note that I > rather fancy top-down development (even here) so I would try and give you > a skeleton working system ASAP. Ok. I'll mail you as soon as I've gathered the team. From karlcz@moraine.HIP.Berkeley.EDU Sun, 23 Oct 94 12:55 PDT Date: Sun, 23 Oct 94 12:55 PDT From: Karl Czajkowski karlcz@moraine.HIP.Berkeley.EDU Subject: [long] Re: MOOSE project -- looking for a language In article <94-10-147@comp.compilers> you write: > As I'm sick of computing systems I know, and saw no end to them, I've >decided to write my own, on my 386 PC to begin with, but in a portable way >(have an implementation over *yuck* POSIX ?). > God, do we all get this impulse? :) > I'm still looking for the High-level language to use, which must be able to >integrate all the features described below. Can somebody help me ? > I'm considering BETA, SELF, Icon, or something like that. Else I'll have to >design my own (as a self-extended typechecking FORTH-like thing ?) :( :(; but >as our moderator say, the world is not ready for yet another language, so if >I can skip the language design phase, I'd be very happy. > Scheme... Well, at least don't engineer stacks into the system at too low of a level, because that makes it really hard to support non-stack based languages like Scheme efficiently--take unix, *PLEASE*! :) > > The project is called MOOSE, and I'm writing it alone. It means >Multi-* Object-oriented Operating System and Environment. *I* didn't choose >the name as I wasn't alone at that time. > > It's a project for an OS that will change you from Un*x and >sub-clones like MS-DOG: Hmm, I wouldn't count on changing anyone from unix until it provides a compatibile environment to use all the old code out there with reasonable performance. This means to me that gcc/g++ would have to be ported, and I don't think that would not be easy to an environment like your suggested one which changes the semantics so much. I am not throwing rocks, but I have thought about doing these same things at various times and these are some of the issues that have stopped me cold before I got too excited. >- of course multi* (tasking/threading/user) > This implies a language not centered toward global variables (no "C"), with > an ability to understand concurrency (with current-continuations ?). > >- persistence, thus garbage collection, security, type-checking > (thus again no "C") that means no *need* of file system (but still support > them to communicate with other OSes. > That also means *need* for a language that supports secure type-checking and > orthogonal persistence. > I think that a file system would be prudent even in a "modern" OS, and not just as a means to communicate with other OSes. If nothing else it could be a hidden module inside the system to abstract things like caching and device-interfacing for slow external storage. Once it is there, a unix-clone module could use it... I once considered making all of the external storage virtual-memory as a quick way to get persistence, but then realized how attrocious the performance would be without more organization and structure over the storage space to provide for locality and caching. >- machine-independent low-level (stack-based/FORTH-like ?) language for > portable binaries, with common interpreter or compiler back-end. > This implies nothing for the HLL. > I would definitely think something could be lifted from another distributed OS project for this; perhaps Sprite has something to offer here? Another alternative is to transmit the HLL and recompile, which would leave more network bandwidth for other data transmissions. A fast compiler with fewer optimizations would be required, and a good scheduling heuristic to determine whether it would really be faster to migrate under whatever migration schemes are available. Maybe a module would get profiling-info tacked onto it to help the scheduler? >- partial lazy evaluation and optimization for ideal dynamic performance > This implies a HLL with lazy evaluation semantics. > Scheme has this... (delay/force constructs) >- no-kernel (not even micro- or nano-) architecture. Everything is > decentralized in modules (even the module loaders). The only thing needed > is a boot module. Modules communicate through conventional protocols (which > may change by replacing all concerned modules). > This implies the existence of a good module system for the HLL (unlike > the C header file bullsh*t). > Isn't it a bit rash to toss the whole kernel out the window? Doesn't something need to exist which syncronizes and controls access to the actual hardware? I tend toward the idea of asyncronous messaging between the various modules and the hardware manager; all of the modules see a virtualized, abstract interface and only the manager knows what is really there. >- system specifications open for a distributed version where objects migrate > or are copied on the fly from host to host to achieve best performance > (but security required more than ever). > If the language is truely high-level, this shouldn't affect it. > Security with Scheme over networks is easy, because it is a tree-language (very easy to parse and analyze)--check with the Scheme Underground project at MIT about this, they have mentioned using a Scheme-derivitive to transmit software agents safely between non-trusting hosts to do things like search remote data repositories. They have an html page, but I don't have the URL. >- Author authentification to retribute authors, or give them (dis)credit. > It would be *very* useful if the language allowed arbitrary annotation of > objects, which may mean things about object equality semantics (if > association tables are to be built). > >- dynamic typing high-level (some may say "object-oriented") language as > a standard interactive development tool -- no *need* for a shell and a > bunch of stubborn languages that cope with each other's flaws. All systems > specification are done in such a language. The language should have natural > extensions that allow program specification and proof, and do secure > type-checking. > That's the language I'm looking for. > Scheme... :) I hope I'm not sounding like a broken record, but I think Scheme is ideal for this sort of thing, and with static-typing extensions (*concessions* if you ask me) it would allow very efficient compilation for low-level system activities. Scheme as it stands can compile to pretty efficient code, but the dynamic type checking becomes extra baggage in applications which don't need its expressive power. I don't know what you mean by "secure typechecking." To me security is preventing programs from doing things that would be detrimental to the rest of the system, while typechecking is done to prevent doing things that might be detrimental to the program itself, i.e. would make it crash. Each day I inch a little closer to deciding to design and implement a Scheme-derivitive with support for concurrency, a robust module system provided through slightly modified closures, and various additions to allow the programmer to "sacrifice" constructs for extra speed; examples of constructs to sacrifice would be continuations, mutution of bindings for procedures, and even dynamic typing. However, if I do this it will not be soon enough to help you in your endeavor. I still have many years of schooling to do before I would inflict something like this on others. > I'm also considering joining Mike Prince's PIOS project, or the FIRE project. >If there's another project (personal/university/commercial) that includes all >(or a big part) of those features, please tell me. If you see any reason why >it shouldn't be possible or wishable, or that it does not go for enough, or >that it goes in the wrong direction, please tell me too. I *think* I am >open-minded enough to hear it. > I think joining another project would be a good idea; just like languages, the last thing we need is *another* new OS to fragment the communities. Even Mach would be worth looking into--could your system be implemented on top of Mach to use other Mach OSes concurrently? karl c. -- Karl Czajkowski karlcz@uclink.berkeley.edu From norman@bellcore.com Sun, 23 Oct 1994 21:37:05 -0400 Date: Sun, 23 Oct 1994 21:37:05 -0400 From: Norman Ramsey norman@bellcore.com Subject: MOOSE project -- looking for a language look into modula-3 for safe systems programming. comp.lang.modula3 faq a good place to start. From ekajewe@hall.ericsson.se Mon, 24 Oct 94 10:01:58 +0100 Date: Mon, 24 Oct 94 10:01:58 +0100 From: Jean-Pierre Weber ekajewe@hall.ericsson.se Subject: MOOSE project -- looking for a language Hi! I saw your post in comp.compilers about your ideas for a new OS. Although it is not exactly the same, some of your ideas seemed to be close to what has been done in the TAOS operating system. (Among other things, they achieved machine independence by using a virtual instruction set that gets translated to the real one when the module gets loaded in memory) I am joining a file about it I pulled off the net a few months ago. Hope this helps, J.-P. ============================================================================ | Jean-Pierre Weber | We do | | Fibre Optics Research Centre | Phone: +46 8 757 4513 | \|/ | | Ericsson Components AB | Fax: +46 8 757 4764 | ----O- | | KI/EKA/S/RF | e-mail: ekajewe@hall.ericsson.se | /|\ | | S-164 81 KISTA , SWEDEN | MEMO: ERI.EKA.EKAJEWE | lasers | ============================================================================ >From N.S.Spellings@uk.ac.bham () Newsgroups: comp.lang.misc Subject: Taos Information (long) Date: 01 Jun 94 11:33:01 BST ============================================================================== Hi all, just thought this may be of interest to you folk.... For those who wish to obtain more information, Toa Systems Ltd may be contacted at the following places : Taos Global Distributors (Japan Office) Tel. +81 3 3223 1020 Fax. +81 3 3223 1288 Internation Office (London) Tel. 081 905 5708 Fax. 081 905 5709 Taos Development Company (Toa Sytems Ltd) Tel. 081 905 5706 Fax. 081 905 5709 or write to : PO Box 2320 London NW11 6PW England Please note that I, nor Five Star Software do not have any connection wi Systems Ltd. Hope someone finds this useful.... Regards, .Neil Spellings. .Five Star Software. ----BEGINS---- An Introduction To Taos ======================= Audience -------- This document, which has been designed to address a wide audience, gives a brief introduction to the ideas behind Taos and its benefits. We have attempted to keep the technological language to a minimum although the very nature of the subject matter makes it necessary for explanations in some of the sections to be quite technical. Overview -------- Computing has been getting steadily more restrictive. The move to so called "open" systems has not helped improve portability, has not produced credible support for parallel systems and has not stopped the further development of increasingly complex interfaces between operating systems and applications. All in all, it has done nothing to improve the lot of the developer or the consumer. The Taos operating system addresses these issues. Its existence and success is good news for technology from small embedded systems through to supercomputers and large scale network applications. Taos is not conventional as it has not evolved from an existing operating system. Tao Systems developed Taos taking into account the commercial and technological realities of the time whilst also removing the limitations enforced upon the user market. Key Features ------------ Taos, a compact, general purpose kernel for parallel processing systems embodies a number of vital ideas. * Hardware Independence - Taos applications run of different processor architectures without any re-compilation of programs. * Load-Balancing - Taos provides an optimum distribution of processes over the network. * TOTAL OPEN COMPUTING : Heterogeneous Processing - Parallel applications are able to execute over networks of dissimilar processors. * Dynamic Binding - Only those parts of an application which are needed at any time are loaded into memory. * Multi-Threading - A piece of code loaded into memory, is available to all programs which need it. * Parallelism -Taos uses a process-based program design model. * Asynchronous-Messaging - Messaging does not halt the sending process * Minimal Kernel - Taos has a very compact implementation, optimising performance and minimising memory requirements. The Challenge of Parallel Systems --------------------------------- Why has parallel processing remained on the property, given the obvious potential this technique has to increase the power of computers way beyond the possible from increasing the power of a single processor? The answer is that, whilst it is comparatively easy to build massive parallel computers, programming them has proven immensely difficult. This has been due to a number of factors including : A lack of suitable general purpose programming methodology; Programs written to run a one machine tend to be tied to that one machine, possibly a single configuration; Uncertainty as to the which computation and communication model to use. Parallel - Features & Benefits ------------------------------ Taos is a software response to the challenge of harnessing parallel hardware. Parallel systems are complex, comprising thousands of processors with different amounts of memory, link standards and so on. Taos exploits the power of the hardware, whilst presenting the programmer with a clean, simple and powerful programming environment. Taos enables programmers to think about the design of their applications in terms of parallel processes. They are completely free to build and structure of processes and communications they need. It is the programmer's responsibility to think about their applications and identify the appropriate decomposition into parallel processes. But once this is determined, Taos will manage the distribution of these processes on any target network. Programmers need not concern themselves with the actual hardware and network architecture upon which their applications will run, including adjustments to the network size. Taos grows over all processors available on the network, and will expand if more processors are added; whilst applications grow over the available processors as they create objects during their execution. This means that it is easier to write "shrink-wrapped" applications for parallel computers using Taos than it is to write them for single processor operating systems, as applications code will run on any processor supported by Taos. Taos uses a process and communications model of parallelism. Each process can execute on a separate processor, and talk by sending messages to each other. The processes are fast ad can only interact by passing messages. There is deliberately no concept of shared memory, though Taos can be implemented on shared memory machines. Taos does not attempt to evolve from a sequential model; extracting parallelism from sequential programs does not and will not work. So, Taos has been designed as a perfect fir for parallel systems. Taos software exploits parallelism; creating parallel applications using Taos is easy. By creating objects and passing messages, the programmer generates the opportunity for Taos to distribute the objects over processors and thus generate parallelism. The final important point to re-emphasise is that it is up to the programmer to write their programs so that the objects can execute in parallel. parallelism is not automatically created, nor should it be. There are instances where a program must be sequential to behave correctly. Portable - Features & Benefits ------------------------------ Portability is normally taken to mean that programs written in a language (such as C) to run on a particular processor, can be re-compiled to run on a different processor without the need to re-write any (or a small portion) of the code. This approach has its limitations as a new compiler needs to be written for every processor type introduced. This can consume a great deal of effort to achieve. Taos takes a different approach. By targeting all compiled code at the Taos Virtual Processor, porting relates only to the VP itself and not to the applications, whatever language they may be written in. In effect the portability has been taken from the language level to the processor level. Furthermore, this low level portability facilitates heterogeneous processing support. See Heterogeneous Processing, below. Taos can be ported with little effort to any processor or communications hardware. The only part of Taos that needs to be re-coded to support a new physical processor, the the Translator. The Translator is the program which converts VP code into the native code for the processor. Once the translator is written, all applications written for any processor, in any language which compiles to VP, will become instantly executable on the new processor type. So, to reiterate; programs written on any supported platform will run on all other supported platforms without any changes; you dont event have to re-compile. Virtual Processor - Features & Benefits --------------------------------------- The Taos virtual processor is an imaginary 64bit microprocessor which can be extended to 128bit and beyond with no limitation but which also runs effectively on 32bit processors. All programs are compiled or assembled into virtual processor code and are kept in this form on disk. The VP code is translated into native code of the processor on which it is to run only when it is needed. The translation occurs as the VP ode is loaded from disk, across the network and into memory of the target processor. This mechanism is at the heart of Taos' dynamic binding facilities. See Dynamic Binding, below. It would be wrong to think that this slows the system down. Most processors are able to translate VP into native code faster than VP code can be loaded from disk and sent across the network, so there is no visible overhead. Indeed, VP code is often more compact than the native code; therefore less disk space is used and code is loaded faster than if it were native for the processor. If there are particular advantages in using native version of the code, then this can be stored on disc, and will be loaded in preference to the VP system. This would be because the performance of the code would benefit from specific instructions supported in hardware by a particular processor. A VP version of the code will run on any processor for which a translator is available. There is no need for re-compilation, see Portability, above. Dynamic Binding - Features & Benefits ------------------------------------- Some readers may be familiar with dynamic linking. Taos dynamic binding is more than dynamic linking. code units are brought into memory only when needed. This is how it works : As a process executes it will ask fr a named piece of code, a tool. This will be brought in from disk and translated into native code, before being executed. This tool may, in turn, call further tools, following the above procedure. Once a tool has finished being executed, it may be removed from memory if no other process is referencing it. This implies that many processes may share code (tools), i.e. multi-threading code. This is highly memory efficient. Once a tool has finished being executed, it stays on the list of available tools. Should it be needed again, this local copy will be used, thus avoiding a re-load from disk. ONly is memory get filled up will the tool be flushed and subsequent calls require a re-load from disk. Taos' dynamic binding and VP code combine to enable Taos to exploit heterogeneous parallel hardware. Total Open Computing - Features & Benefits ------------------------------------------ Taos is able to run on any hardware which there is a translator. This provides the basic facility which enables programmers to write code which can be run on a wide range of hardware. This, together with Taos' dynamic binding, enables programs to run over a network of differing processor and communications types without changes to the code, or any re-compilation. Heterogeneous processing is the exploitation of a range of different processor memory and communications hardware to create a versatile parallel computing machine. Such machines may be built from a variety of hardware to support different kinds of computation. For example, a vision system requires a front end to do the initial work on the raw images being received, tom find edges, shapes, etc. This stage of the problem is well suited to parallel hardware, whereas the back end will need to extract meaning from the shapes, which is more suited to implementation on hardware supporting list or network processing. The ability of software to run a variety of hardware is essential for this type of machine to be successfully exploited. Furthermore, Taos provides access to information about the hardware available in the network. So, programs can take advantage of special purpose hardware to run specific objects. This means that sophisticated adaptive programs can be written within the Taos model to get most from heterogeneous machines. Heterogeneous processing is the complete Open System, in which all aspects of the processing are distributed across dissimilar processors, networks and architectures. It benefits consumers who can select processors on the basis of current price; performance or whichever criteria they select as their priority, without prejudicing future decisions. For manufactures, it gives them the flexibility to improve hardware design and not become locked into historical decisions for the sake of software compatibility. Therefore, we call this aspect of Taos "Total Open Computing". Minimal Kernel - Features & Benefits ------------------------------------ The key to Taos' applicability to so many areas lies in its compact kernel. This is all that is needed for a processor to provide all of the Taos services. The Taos kernel provides all the facilities needed to support its simple execution model, yet the whole kernel is only 12K. The kernel executes on every processor in the network from boot, and its facilities include memory management and cacheing, object creation, distribution and execution, object message passing and tool calling. There are also calls to provide global name management, local timer and scheduling, and access to network hardware information. The programmer is free to add objects to the system as appropriate. Examples of these may be hardware drivers or file system objects. Objects and Messages - Features & Benefits ------------------------------------------ Taos objects are also parallel processes. Each object which Taos creates is given its own process to execute it. The difference between objects and processes lies in what they are about; objects are about data and code, they occupy memory space; processes are about processors, they consume processor time. Put the two together and you have an object which is executing, consuming memory space and processor time. A process brings an object to life. Objects can only interact with other objects by sending and receiving messages. As objects can exist om separate processors, memory can not be shared between objects. Taos provides a light-weight-mail system to communicate between processors. Messages are just like letters, you send them by posting them in a mailbox with an address on it. You use letters to communicate with people to whom you cannot talk directly. So it is also with Taos objects; you use messages to communicate with other objects, as you cannot talk to them directly since they can be on separate processors. When you send a message you specify the mail address of the recipient. The sending of mail is equivalent to popping a letter into a post-box. Conversely, each process has a mail-box in which mail is placed by the messaging system. Objects receive mail be checking their mail-boxes. Messages are typed, so the object can distinguish between a variety of possible incoming message types. Messages conform to the basic bode format, plus extensions, to hold the sender's address and the message's destinations address. When mail arrives it is left on a list for the receiving process to look at. Taos provides a simple mechanism to send messages, there being only two facilities in its messaging system, to send and receive messages. Messages are sent asyncronously; once a message has been sent on its way the sending process is free to continue its execution. Synchronous communication can be achieved by waiting for a returned acknowledge message. Taos' method of communication ensures that parallel processes execute independently of one another for as much of the time as possible. An object may need to wait for a message before it continues processing, but a sending object will now wait until the destination has received it. The mailing system uses a distributed algorithm which finds multiple paths to a destination and may use more than one route for each message sent, thus making best use of all available communication paths. If one route is bottlenecked then the message will get through via another. Distributed processing - Features & Benefits -------------------------------------------- The whole conceptual approach to the design, implementation and execution of Taos is organic. A program evolves to fill the network during runtime. Other systems introduce bottlenecks by requiring a system-wide time-stamp on all messages, or by maintaining a central control over the distribution algorithm. Taos does not attempt to impose a central control over te execution of an application. The kernel is small enough to exist on every processor, providing local services to the objects on its processor and interacting with adjacent processors' kernels to provide message passing and process distribution. Distribution is based on processes which pass messages. Load balancing (the distribution of processes over the network to maximise the performance of the system) is achieved via a simple algorithm based on the computation and communication requirements of the objects. When on object is created, the loading on the local processor is compared with the loading on neighbouring processors and th object is allocated to the most suitable processor. Each processor hold minimal routing information for each communications channel eo enable messages to be forwarded towards their destinations. Messages are routed to their destinations in much the same way as water flows down through pipes under the effect of gravity. During the execution of a program, processes distribute themselves over the available processors as they are created. The net effect is that objects spread out over the available processors in much the same way as liquid spreads out over a surface. Object Oriented Design - Features & Benefits -------------------------------------------- Taos was conceived to take advantage of the re-usablility and robustness provided by an object based approach to design. Object ideas are exploited at all levels of Taos, from kernel data structures to high level classes. Kernel objects are used to build higher level messaging passing object. The basic data node structure used bt Taos is inherited by all objects in the system. This enables Taos to manipulate all entities which conform to this very simple structure. Message passing objects, the messages which they pass to each other and the tools which they use to process their data all conform to this basic data structure. New types of objects may be introduced by the programmer. Data nodes are the basic object in the system. Tool objects are bits of code, like formal object oriented programming's methods, but without and restrictions on their use. Control objects, as they are known, are objects which have a process associated with them. They communicate via messages and can be distributed over processors. Such a message passing object will typically contain several components which are references to tool objects. See Objects and Messages above. Classes provide higher functionality such as Window and Polygon World. These are formed of message passing objects bound together to form the class object. A class may make use of many objects working in parallel. These objects are made available to the user in the form of calls to the class, for example, create new windows and manipulate them using method calls. So the user just sees functionality such as "open window" and does not need to be concerned with underlying parallelism generated by the execution of the objects in the class. Programmers are encouraged to use existing messages, tools, objects, and classes, to create their own new ones. There are presently over 3000 tools covering a wide range of basic functionality from string and file handling to classes supporting 3D polygon world. Re-use and relax! A program to fly-through a fractal landscape is under 100 lines long, when written using the existing objects. Object and Memory Management - Features & Benefits -------------------------------------------------- Taos executes objects and manages memory in a very consistent manner. The Taos software model use processes, messages and objects, whilst its hardware model uses processors with local memory and communication channels between processors. The way to view objects is that they consume memory space, whereas processes consume processor time. An object need a process to enable it to execute. Upon creation of an object Taos allocates the object to a processor and then allocates a process to enable the object. A typical Taos object is a few hundred bytes in size. So, they lie between fine-grain Smalltalk-style objects and course-grain UNIX-style objects. The lowest level object in Taos is the 'node'. The is the simplest entity with which Taos deals. It is a variable sized packet of data which can be placed in a doubly linked list. All Taos entities conform to this basic format. From this basic building block, other structures have been grown, such as tools, messages and other types of system object. Nodes have a type field which identifies what type of Taos object the node holds and hence how it should be processed. Pre-defined types include: Tools, Control Objects, Bitmaps, Graphical Objects and Class Objects. The user can define new types. Nodes are in one of two forms. When the node is on disk or being communicated across a network, it is held in 'template' form, as it is loaded into memory and made ready to be executed it si converted to 'process-ready' form. As the template is converted to process-ready, and translation from VP code to the local processor's native code is performed, and the node is inserted into a list of other process-ready objects (see Dynamic Binding and Portability). Once a mode is in a process-ready list it can be processes. The node type determines how it is to be processes. Two types to focus on are the Control object and the Tool object. When a Control object is created the object's template is distributed and made process ready on a processor. A process is made available to the object and it start to execute. A Control object is made up of one or more components, which are all Taos nodes of one type or another. Each component is executed in sequence until the last one is finished when the Control object closes and its process finishes. The components may be other Control objects, tools, graphic objects etc. Tools are bits of code which operate on the data defined in a Control object. For example, they may perform calculations and send and receive messages to and from other Control objects. All Control objects are created by another Control object, and each has the mail address of its parent, forming a tree. Tools, being nodes, can be manipulated by the kernel. A control object may consist of some local memory space and some constituent tools which operate on the data. Whilst the Control object is the smallest entity which can execute in parallel, it is not the finest granularity of memory management. Individual tool can be loaded from disk, as they are also Taos objects (conforming to the basic node format). A Control object template only holds the text names of its constituent components, not the actual code. As a Control object is created, the kernel checks to see is th tools which the components reference are already available in memory, and if they are, simply points to them. Only if an object is not present will it be loaded from disk and be made process-ready. So all Taos objects can be multi-threaded. You will never have two copies of the same object in the same memory space, unless you specifically request it (see Dynamic Binding). Another feature of the execution mechanism is that only those components which are needed are loaded. If you design your application so that it is built of hierarchically structured Control objects, then code will only every be loaded if it is executed. If the path of execution does not pass the particular component then it will not be loaded and thus occupy no space. So, the amount of memory consumed is kept to and absolute minimum and is driven by the execution of the program. Conclusion ---------- Taos is the ground breaking revolution for which the electronics, computing and communications worlds have been waiting. For years the information world has been outgrowing its boots, becoming cumbersome and sluggish. The push of new technologies and of parallel processing in particular has forced a profound re-think of what an operating system should be. Taos provides what is needed, no more no less; it is simply the right product at the right time. Elegant, compact and versatile, it provides the programmer with simple yet powerful tools to exploit the emerging technologies. Taos is not just another development, it is a Holy Grail, a complete product with substance as strong as the claims made for it, and implications that can not yet be realised. Exactly what it is that makes Taos so significant may be argued for a long time given its many benefits. For those of use who carry the torch of Open Computing, Taos provides the ultimate open platform through distributed processes across dissimilar processors to achieve HETEROGENEOUS PROCESSING or TOTAL OPEN COMPUTING. this is achieved by having totally PORTABLE CODE. Taos-based applications are written only once, so that software houses can now channel funding into the development of new products rather than having to allocate vast sums towards the porting of existing packages from one platform to another. Taos' PARALLEL PROCESSING facilities generate a MASTERLESS NETWORK with no practical limit on its size and providing LINEAR SCALABILITY of performance. Developing products for a parallel environment has traditionally been a major stumbling block. But writing parallel program for Taos is as easy as writing programs for a single processor environment; and once a program is written it will run on any processor supported by Taos without any changes. The LOAD BALANCING techniques employed by Taos enable applications to exploit additional processing power as it is added, without re-compilation, even during the execution of the program. Taos' OBJECT ORIENTED programming techniques have led to the creation of thousands of reusable tools which will be used over an over again in future software developments. Other Object Orientated techniques have so far failed to live up to expectations, but Taos shows that this methodology can, if employed wisely, yield massive benefits to the programmer and end user. Taos' lack of protocol layers make is very reactive to stimuli and this combined with its highly efficient DYNAMIC BINDING, provides the bases for truly REAL TIME systems. Taos' SCALABILITY enables it to underpin massive superscalable networks, whilst its COMPACTNESS makes it an obvious choice for embedded applications. This only provides a brief overview of just some of the features and benefits of Taos; despite this document's limitations, what we hope it does emphasise is the remarkable flexibility of Taos and the broad range of markets for which it is ideally suited. ----ENDS---- ---------------------------------------------------------------------- Neil Spellings Five Star Software Five Star Software 1 Dove Cottages Scropton email : N.S.Spellings@uk.ac.bham Derbyshire tel : (0374) 227802 DE65 5PN ---------------------------------------------------------------------- From jvs@iconz.co.nz Mon, 24 Oct 1994 23:53:12 +1200 (NZST) Date: Mon, 24 Oct 1994 23:53:12 +1200 (NZST) From: Johan Van Schalkwyk jvs@iconz.co.nz Subject: Shoes. ships. sealing wax. Mooses? Dear Francois-Rene >To me, this means a hardware abstraction layer must provide abstraction for >all those kind of bit operations, where C (for instance) only provides ands, >ors, xors, and shifts. Being able to do this directly on registers also means >this hardware abstraction layer should still allow hardware access when needed >(much like _AX statements in turbo pascal). Agreed. My idea would be to use "primitive" operators, and have everything very carefully delineated, with resolution into components as if everything were parallel, eg. silly code like... PUSH R0 MOV R3,&00002345 SHL R0,1 SHL R0,1 ADD R0,R2 MOV R1,SEG01:[R0] INC R3 POP R0 JZ WHEREVER might become something like:- | **(1)*************************(fork)*****************(2)* * * | PUSH R0 MOV R3,&00002345 SHL R0,1 INC R3 SHL R0,1 | ADD R0,R2 | MOV R1,SEG1:[R0] | POP R0 wait for (2) wait for (1) * * ******************************(join)********************* | JMP WHEREVER and then the intelligent programmer's apprentice (program) will point out that the left side resolves to MOV R3,00002346 / JMP.. and also implement the right hand side as MOV ECX,DS:[EAX][EBX*4] on a 386, but perhaps in some totally different way with another processor (but the source will be stored as primitives, with relevant notes about different system implementations, if desired)! Obviously, a lot of work is needed in deciding what primitives are appropriate in a general context! ...BUT I would only allow this to occur on my hypothetical level 1. If you are programming on a higher (symbolic) level 2 and are unhappy with eg speed considerations, you will not simply insert inline code there (even non-processor specific symbolic code), but you will have to formally employ a "function" of some type, and then go down one level to the symbolic assembly level 1 and define this "function" (or whatever) in terms of primitive constructs. (Do you think this is workable? Is it too restrictive?) I also like the idea of having all the core software written in such code, so that it can optimise itself. It also raises the possibility that (with a bit of judicious help) such a program could even be implemented in a higher level language, and then "tunnel down" to a lower level by analysing it's own code and optimising itself! (The amount of "self knowledge" implicit in this, especially in respect of timing, is of course quite intimidating)! >I've never ever seen any commercial software with good semantics, and syntax >was even more horrible. Yeah, well, okay, perhaps (for the sake of argument) I was being too kind! >But these last months have been working with a purely syntactic system, >which had no designed semantics, and where features had been added and added My sympathy. > (if you read french, I'll send you my masters report). Apologies. Lazy slob does not read French (yet). >So what I say is you shouldn't add syntactic features on the fly without >studying the semantical effects, and that things that appear syntactically >simple are unusable semantical monsters (like this B stuff I've been working >with). Not to say that what YOU wrote is such (I do not know it very well, >and it did not look that way to me). I agree absolutely. Some (many) of my ideas may be completely unworkable. But one can only try. I think that half the problem is with ivory tower academics who have never sat down and written twenty thousand lines of worthwhile code in their lives! >Well, yes and no: to me, the level 0 (hardware dependency) is very limited, >and expands very slowly. Level 2 (human interface) we have little control on >it, and it's not the algorithmically interesting part of a program; let it >be automatically generated when possible. Level 1 (the algorithmic part of >the software) is infinite, and contains an infinite partially ordered only >hierarchy of sublevels. I'm not sure that it's necessarily true to say that he hardware expands that slowly. cf what we had ten years ago. Also, the software most regrettably seems to lag several years behind the hardware!? Also, I see level 1 as a fairly well-defined boundary separating the highly abstract level 2 from the "hardware like" level 0 (ideally all hardware, but often necessarily containing large software constructs). But I think that perhaps we should get down to brass tacks, rather than philosophising for ever! >> Q3. Have you thought about legible constructs for _parallel_ architectures? >Yes. first thing: do not use global variables when possible, so that >distribution be as simple as possible (without some global thread being >ever accessed). Yep. But it depends what you mean by "global". I certainly agree that almost all variables must be restricted in their scope, but on the other hand, one should avoid excessive shuttling of parameters to and fro _within_ the context of (a sometimes quite large) module, just because one is obsessed with keeping everything "local"! >Then a generic FOR construct with a variable taking all values >in a set, and a recursive FOR construct to use recursively defined structures, >will provide distribution. Surely this "FOR" is a specific instance, and not general enough? How how would you, for example, represent code that searches for a particular text sequence in a long character string, given that you want near-optimal searching AND that you do not know whether the machine you are implementing the search on may be either sequential or parallel? I for one would have to do a hell of a lot more reading about parallel architectures before I was even vaguely confident that I could answer the question, and, even more importantly, create a general architecture that implements the answer for this and similar cases. (Altho I have a few ideas)! Is linear searching such a basic operation that one should have a SEARCH operation as a primitive on level 1, or should you leave it for the user to define in terms of level 1 primitives, or should the user even define this on a higher level?? I think that questions such as this are valid if one is to design a workable system, and indeed, we will probably have to ask many such questions. >If you're designing an new chip, that sounds ok. But if you're writing a >computing system on existing architectures, then I think it's too late to >correct the asm. What I meant was, that the "symbolic assembler" of level 1 can (with a lot of careful thought) be a lot more friendly than many current assemblers. (You might argue that it would be more a compiler than an assembler, but I would have a lot of trouble applying the term "compiler" to something that is on the one hand putting together something that almost looks like microcode into assembler instructions, and on the other implementing "calls" to complex level 0 constructs that may be either hardware defined or written in assembler)! Anyway, what's in a name? >Ok. I'll mail you as soon as I've gathered the team. Great. You may find that my level of expertise is not adequate to your task, but I'm prepared to give it a good tonk!! I'm sure we can look forward to some good fights! Bye for now, JVS. From basile@soleil.serma.cea.fr 24 Oct 94 13:52:38 -0100 Date: 24 Oct 94 13:52:38 -0100 From: Basile STARYNKEVITCH basile@soleil.serma.cea.fr Subject: MOOSE project -- looking for a language (i'm answering in French to) > I'm still looking for the High-level language to use, which must be able to > integrate all the features described below. Can somebody help me ? > I'm considering BETA, SELF, Icon, or something like that. Else I'll have to > design my own (as a self-extended typechecking FORTH-like thing ?) :( :(; but > as our moderator say, the world is not ready for yet another language, so if > I can skip the language design phase, I'd be very happy. Et pourquoi pas SML? Il y a-t-il des papiers sur MOOSE? -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From basile@soleil.serma.cea.fr 24 Oct 94 17:01:39 -0100 Date: 24 Oct 94 17:01:39 -0100 From: Basile STARYNKEVITCH basile@soleil.serma.cea.fr Subject: MOOSE project -- looking for a language >>>>> "Francois-Rene" == Francois-Rene Rideau writes: >> Et pourquoi pas SML? Francois-Rene> D'apres ce que je sais, tout l'interet de SML Francois-Rene> pour la reutilisation de code est dans son systeme Francois-Rene> de modules (celui de CAML est nul, par exemple). Je Francois-Rene> ne le connais pas, donc je reserve mon jugement. Je Francois-Rene> prends note de cette suggestion. Ou me Francois-Rene> conseillez-vous de chercher de la documentation a Francois-Rene> ce sujet ? Toujours est-il que j'ai besoin d'un Francois-Rene> langage permettant une utilisation dynamique Francois-Rene> (i.e. je ne sais pas si le typage statique de ML Francois-Rene> conviendra, et le mega-compilateur du new jersey Francois-Rene> peut aller se rhabiller, tandis qu'aucun autre a ma Francois-Rene> connaissance de maitrise les modules :). Je connais SML surtout par la lecture des papiers de NewJersey (ie ftp.cs.princeton.edu:/pub/ml). Toutefois SML a un typage statique. En fait, je pense qu'il vous faut inventer votre propre langage. J'aurais tendance a dire votre propre systeme - je pense que l'idee de compiler un fichier textuel est viellotte, et contraire a vos ambitions. Peut etre faudrait-il regarder du cote des editeurs syntaxiques etc etc. >> Il y a-t-il des papiers sur MOOSE? Francois-Rene> Pour l'instant, rien de bien serieux, sinon des Francois-Rene> versions non definitives d'un manifeste. Je Francois-Rene> regarde pour l'instant du cote de TAOS, qui semble Francois-Rene> etre un systeme tout a fait comparable en maints Francois-Rene> points, mais qui est commercial, crois-je. Francois-Rene> Je vous tiendrais au courant de mes choix. -- Basile STARYNKEVITCH ---- Commissariat a l Energie Atomique DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France fax: (33) 1- 69.08.23.81; phone: (33) 1- 69.08.40.66 email: basile@soleil.serma.cea.fr; homephone: (33) 1- 46.65.45.53 N.B. Any opinions expressed here are solely mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. Please cite a small part of my mail in all answers Veuillez citer une petite partie de mon courrier dans vos reponses From drichter@owlnet.rice.edu Mon, 24 Oct 94 19:29:23 -0500 Date: Mon, 24 Oct 94 19:29:23 -0500 From: David Richter drichter@owlnet.rice.edu Subject: MOOSE project -- looking for a language You might look at the work already done on OS's written in Scheme. (qv. the Scheme FAQ in comp.lang.scheme or comp.lang.lisp). Regarding typechecking, if you don't want to reinvent the wheel, check out Andrew Wright's soft-typer for Scheme. It should be extendable to support type declarations at (eg.) module boundaries. (A reference should be in the FAQ, otherwise ftp to ftp.cs.rice.edu and look around. If I remember, it wasn't overly hard to find.) David From jecel@lsi.usp.br Mon, 24 Oct 94 20:32:46 EDT Date: Mon, 24 Oct 94 20:32:46 EDT From: Jecel Mattos de Assumpcao Jr. jecel@lsi.usp.br Subject: MOOSE Project -- new OS ? > As I'm sick of computing systems I know, and saw no end to them, I've > decided to write my own, on my 386 PC to begin with, but in a portable way > (have an implementation over *yuck* POSIX ?). I am also writting my own OS. You can read about it in the WWW as: http://www.lsi.usp.br/~jecel/merlin.html > The project is called MOOSE, and I'm writing it alone. It means > Multi-* Object-oriented Operating System and Environment. *I* didn't choose > the name as I wasn't alone at that time. So, why can't you change it now? > It's a project for an OS that will change you from Un*x and > sub-clones like MS-DOG: > - of course multi* (tasking/threading/user) ok. > - persistence, thus garbage collection, security, type-checking (thus, no "C") > that means no *need* of file system (but still support them to communicate > with other OSes. That also means *need* for a language that supports > orthogonal persistence. I agree. But any language can have persistence added to it ( see the Texas system in ftp://cs.utexas.edu/pub/garbage ) > - machine-independent low-level (stack-based/FORTH-like ?) language for > portable binaries, with common interpreter or compiler back-end. Smalltalk/Self bytecodes are also a good choice. > - partial lazy evaluation and optimization for ideal dynamic performance Ok. My system doesn't do this, but is close. > - no-kernel (not even micro- or nano-) architecture. Everything is > decentralized in modules (even the module loaders). The only thing needed > is a boot module. Modules communicate through conventional protocols (which > may change by replacing all concerned modules). I don't think you can get rid of a nanokernel-like system. Something must field the interrupts. > - system specifications open for a distributed version where objects migrate > or are copied on the fly from host to host to achieve best performance > (but security required more than ever). Almost all new OSes have this. Also, agent based programming is the "in" thing in networks. > - Author authentification to retribute authors, or give them (dis)credit. I do this with the normal "user objects". > - dynamic typing high-level (some may say "object-oriented") language as > a standard interactive development tool -- no *need* for a shell and a > bunch of stubborn languages that cope with each other's flaws. All systems > specification are done in such a language. The language should have natural > extensions that allow program specification and proof, and do secure > type-checking. Good choice. > I'm still looking for the high-level language to use, which must be able to > integrate all those features. Can somebody help me ? > I'm considering BETA, SELF, Icon, or something like that. Else I'll have to > design my own (as a self-extended typechecking FORTH-like thing ?) :( :(. Any > comments ? I use Self. It is very good and getting much better! > I'm also considering joining Mike Prince's PIOS project, or the FIRE project. > If there's another project (personal/university/commercial) that includes all > (or a big part) of those features, please tell me. If you see any reason why > it shouldn't be possible or wishable, or that it does not go for enough, or > that it goes in the wrong direction, please tell me too. I *think* I am > open-minded enough to hear it. I think it is a great idea! > > Any help, comment or feedback appreciated. > Please reply by mail (but you may post your reply *too*), as I may not be > reading your group. Sorry for the noise if you think it doesn't fit the group. > Thanks. > -- > -- , , _ v ~ ^ -- > -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- > -- ' / . -- > MOOSE project member. OSL developper. | | / > Dreams about The Universal (Distributed) Database. --- --- // > Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // > Phone: 033 1 42026735 /|\ /|\ / Feel free to write me if you want more details about my work. I hope to update my WWW pages later this week with some real information :-) Regards, Jecel Mattos de Assumpcao Jr. Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil + Merlin Computers + Pontificia Universidade Catolica de Sao Paulo From agc@uts.amdahl.com Tue, 25 Oct 1994 07:43:46 -0700 (PDT) Date: Tue, 25 Oct 1994 07:43:46 -0700 (PDT) From: Alistair G. Crooks agc@uts.amdahl.com Subject: MOOSE project -- looking for a language > As I'm sick of computing systems I know, and saw no end to them, I've > decided to write my own, on my 386 PC to begin with, but in a portable way > (have an implementation over *yuck* POSIX ?). > > I'm still looking for the High-level language to use, which must be able to > integrate all the features described below. Can somebody help me ? > I'm considering BETA, SELF, Icon, or something like that. Else I'll have to > design my own (as a self-extended typechecking FORTH-like thing ?) :( :(; but > as our moderator say, the world is not ready for yet another language, so if > I can skip the language design phase, I'd be very happy. My initial reaction is to say, "Take a look at Sather" - I'll come back to this later. > The project is called MOOSE, and I'm writing it alone. It means > Multi-* Object-oriented Operating System and Environment. *I* didn't choose > the name as I wasn't alone at that time. > > It's a project for an OS that will change you from Un*x and > sub-clones like MS-DOG: > - of course multi* (tasking/threading/user) > This implies a language not centered toward global variables (no "C"), with > an ability to understand concurrency (with current-continuations ?). > > - persistence, thus garbage collection, security, type-checking > (thus again no "C") that means no *need* of file system (but still support > them to communicate with other OSes. > That also means *need* for a language that supports secure type-checking and > orthogonal persistence. > > - machine-independent low-level (stack-based/FORTH-like ?) language for > portable binaries, with common interpreter or compiler back-end. > This implies nothing for the HLL. > > - partial lazy evaluation and optimization for ideal dynamic performance > This implies a HLL with lazy evaluation semantics. You seem to be looking for a functional language here - either that, or I've got my terminology muddled up. Have you had a look at Haskell, or, more practically, Gofer? > - no-kernel (not even micro- or nano-) architecture. Everything is > decentralized in modules (even the module loaders). The only thing needed > is a boot module. Modules communicate through conventional protocols (which > may change by replacing all concerned modules). > This implies the existence of a good module system for the HLL (unlike > the C header file bullsh*t). I like this idea - like a group of co-operating objects, sending messages to each other. > - system specifications open for a distributed version where objects migrate > or are copied on the fly from host to host to achieve best performance > (but security required more than ever). > If the language is truely high-level, this shouldn't affect it. > > - Author authentification to retribute authors, or give them (dis)credit. > It would be *very* useful if the language allowed arbitrary annotation of > objects, which may mean things about object equality semantics (if > association tables are to be built). > > - dynamic typing high-level (some may say "object-oriented") language as > a standard interactive development tool -- no *need* for a shell and a > bunch of stubborn languages that cope with each other's flaws. All systems > specification are done in such a language. The language should have natural > extensions that allow program specification and proof, and do secure > type-checking. > That's the language I'm looking for. You don't want much, do you? :-) > I'm also considering joining Mike Prince's PIOS project, or the FIRE project. > If there's another project (personal/university/commercial) that includes all > (or a big part) of those features, please tell me. If you see any reason why > it shouldn't be possible or wishable, or that it does not go for enough, or > that it goes in the wrong direction, please tell me too. I *think* I am > open-minded enough to hear it. I too am considering PIOS, and would like to hear of any feedback you get concerning your project. Please keep me informed. Regards, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 125 234 6377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. [These are only my opinions, and certainly not those of Amdahl Corporation] From rockwell@nova.umd.edu Tue, 25 Oct 1994 16:02:45 -0400 Date: Tue, 25 Oct 1994 16:02:45 -0400 From: Raul Deluth Miller rockwell@nova.umd.edu Subject: [MAILER-DAEMON: Returned mail: Host unknown (Name server: clipper.ens.france: host not found)] Date: Tue, 25 Oct 1994 15:58:10 -0400 From: Mail Delivery Subsystem Return-Path: Subject: Returned mail: Host unknown (Name server: clipper.ens.france: host not found) To: rockwell The original message was received at Tue, 25 Oct 1994 15:57:31 -0400 from rockwell@localhost ----- The following addresses had delivery problems ----- rideau@clipper.ens.france (unrecoverable error) ----- Transcript of session follows ----- 501 rideau@clipper.ens.france... 550 Host unknown (Name server: clipper.ens.france: host not found) ----- Original message follows ----- Received: from rockwell@localhost by nova.umd.edu (8.6.8/16.2) id PAA02586; Tue, 25 Oct 1994 15:57:31 -0400 Date: Tue, 25 Oct 1994 15:57:31 -0400 From: Raul Deluth Miller Return-Path: Message-Id: <199410251957.PAA02586@nova.umd.edu> To: mprince@crl.com, PIOS actives , casas@cse.ogi.edu, luthers@bnr.ca, rideau@clipper.ens.france, srini@aqualung.columbiasc.ncr.com In-reply-to: (message from Mike Prince on Tue, 25 Oct 1994 12:08:10 -0700 (PDT)) Subject: Re: PIOS Feedback and short term plans I'm a bit puzzled by the line of discussion which I'm characterizing with the following quote: . FRANCOIS-RENE I'd say high-level OS. Do not define bitwise behavior . like under Unix/C. Just define high-level protocols, and an . abstract intermediate-level langua ge. Moreover, we'll still need . machine-centric layers. Only you'll address them only if you really . need to (i.e. play music on a host, and not another one ten miles . away :) What is "high level"? APL (which is, arguably, one of the highest level languages in existence) has operations on bit arrays -- which is exactly bitwise behavior. Perhaps the call, here, is to carefully focus the semantics of operations to allow for reasonable optimization when fitting into a new operating environment? [But, note that such optimization is directly at odds with rapid porting.] Also note that there are two kinds of operations that need to be considered: computations (which are transformations of symbols within some environment) and communications (which has to do with the linking of environments). At the "lowest level" we're going to need a robust set of primitives (whose existence and semantics can be relied on, in some sense of the word) which will be our communication standard(s). Above that we need layer(s) of abstraction to bridge the gap between the machine and human developers and users. Incidentally, a "Forth like" implementation model doesn't imply that (for example) continuations are not available -- continuation can be implemented with stack copying (and communications already involves a lot of copying -- except for the case where the information is already present). However, I think one good place to start would be to identify the areas where current language or os standards fall down -- these are areas where we're going to have to work harder. Finally, another related project: the Scheme Underground: http://www.ai.mit.edu/projects/su/su.html They've already got a bytecode interpreter up, which may be of interest for PIOS. Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.e As I'm sick of computing systems I know, and saw no end to them, I've >decided to write my own, on my 386 PC to begin with, but in a portable way >(have an implementation over *yuck* POSIX ?). [nice spec. deleted] Ever hear of TAOS ? It claims to do about the same as you propose, don`t know if these claims are valid though. JD From gerlingj@ims-tc.ce.philips.nl Wed, 26 Oct 94 12:25:17 +0100 Date: Wed, 26 Oct 94 12:25:17 +0100 From: Jan Derk Gerlings gerlingj@ims-tc.ce.philips.nl Subject: MOOSE Project -- new OS ? Dear Mr. Rideau, > > > Ever hear of TAOS ? > > It claims to do about the same as you propose, don`t know > > if these claims are valid though. > Yes, I've heard of it, but couldn't contact them. > Moreover they are a commercial system, which may (but may not, according > to price & distribution policy) be incompatible with my projects. > Do you know how I can contact them (but by snail mail) ? > > Thank you very much. > For Europe : TKS Corporation Global Distributors London: Tel: +44 81 905 5708; Fax: +44 81 905 5709 or Tantric Technologies Support Service Tel: +44 703 230 340; Fax: +44 702 230 440 ^ I have a suspicion this is a typo in the folder I've got ! Email: tantric@cix.compulink.co.uk or write to Tao Systems Software Developers PO Box 2320, London MW11 6PW, England Good luck, JD --- Ing. J.D. Gerlings, Philips Consumer Electronics B.V. Interactive Media System, Advanced Development, The Netherlands E-mail: gerlingj@ims-tc.ce.philips.nl Private: jgerling@iaehv.nl ####### It's not stress that kills, it's the Job ! ####### From dpw93@ecs.southampton.ac.uk 26 Oct 94 15:38:00 GMT Date: 26 Oct 94 15:38:00 GMT From: David Wragg dpw93@ecs.southampton.ac.uk Subject: Watershed -- what's up ? Francois-Rene Rideau writes: > Can you give me any news from your Watershed project ? > I'm currently trying to revive my own project, and would like to know > where yours is, if we can merge, etc. > > Thanks. > The news is ... not much. A few weeks after I had gone public and gathered opinions about the project I went on a long holiday away from the Internet, and I had a lot of time to think about the design. So some things changed quite a lot. The most important thing - what I want it to be like in use has remained the same. For a lot of efficiency reasons, I would now like to make the system pure functional, and so its roots have gone from being in OO languages to being in pure functional languages (such as Haskell and Miranda). The attraction of pure functional semantics is that it makes some important aspects of Watershed (the garbage collector and the "transaction processing" model) much easier to think about, and program. But pure functional semantics have a big problem - they don't go well with user-interfaces, since user-interfaces rely heavily on a concept of state. I intend to stick with language independence (using the right language for the right job at the right time) but I will need to write something very like a functional language compiler. This will be a difficult task (lazy functional language compilation is still very much a research topic). And that's about it. I'm confident that this is a "better" design than the one I had before, but it relies on too many things that are still being researched by people worldwide. Perhaps we could merge, or at least exchange ideas. I'd be happy to hlp with a project which has a better chance than Watershed of being completed. (At the moment I'm thinking that writing Watershed might be a good project for my doctorate, but that puts even early versions at 3+ years away). Please write and tell me what your aims are. If you are interested, I'll try to write out my current design more fully. Regards, Dave W. From bourguet@muelec.fpms.ac.be Wed, 26 Oct 94 17:07:58 GMT Date: Wed, 26 Oct 94 17:07:58 GMT From: Jean-Marc Bourguet bourguet@muelec.fpms.ac.be Subject: RE MOOSE Avez-vous considere Oberon-2 comme langage, et comme systeme ? Il y a certaines caracteristiques que vous desirez qui lui manque, mais il ferait une bonne base. ----------------------------------------------------------------------- Jean-Marc Bourguet Service d'Electronique Faculte Polytechnique de Mons Tel : +32 65 37.42.23 Boulevard Dolez, 31 Fax : +32 65 37.42.36 7000 Mons Email : bourguet@muelec.fpms.ac.be Belgique From mprince@crl.com Wed, 26 Oct 1994 14:17:03 -0700 (PDT) Date: Wed, 26 Oct 1994 14:17:03 -0700 (PDT) From: Mike Prince mprince@crl.com Subject: Newest PIOS actives The header of this message contains the most recent list of individuals who are interested in the on-going discussion of PIOS. Please let me know if you wish to be taken off this list. I also have another one for people who just want to be updated on the project periodically. I am falling a little behind on getting out my first proposal for the virtual machine architecture and intermediate language. With a lot of luck it will still be out by tonight. Tomorrow by the latest. Again, thank you all for your participation, Mike From bourguet@muelec.fpms.ac.be Thu, 27 Oct 94 08:38:07 GMT Date: Thu, 27 Oct 94 08:38:07 GMT From: Jean-Marc Bourguet bourguet@muelec.fpms.ac.be Subject: Oberon Oberon est le nom d'un systeme d'exploitation concu par une equipe dirigee par N. Wirth. Oberon est aussi le nom du langage dans lequel a ete ecris le systeme Oberon. Oberon-2 est une evolution du langage Oberon. En tant que langage Oberon est une evolution de Pascal et Modula. Il y a deux branches divergentes du systeme d'exploitation Oberon (appelee Sytem 3 et Version 4). Un 'news group' est consacre a Oberon (le langage et le systeme) : comp.lang.oberon. Je n'ai plus la liste de vos objectifs, et je ne peux donc pas vous indiquer lesquels de vos desiderata sont remplis par ce systeme. Ref: Object-Oriented Programming in Oberon-2 Hanspeter Mossenbock. Springer-Verlag. Le meilleur livre que j'ai lu sur la POO. Il utilise Oberon-2 pour illustrer les concepts, mais separe clairement ceux-ci de leur implementation. Programming in Oberon. Steps beyond Pascal and Modula-2. M. Reiser, N. Wirth. Addison-Wesley Je ne l'ai pas lu. Project Oberon. The design of an Operating System and Compiler N. Wirth, J. Gutknecht. Addison-Wesley. Contient les sources du systeme et du compilateur Oberon. C'est la que l'information est la plus claire, mais pas toujours a jour car le systeme continue d'evoluer. Oberon est disponible par FTP anonyme sur neptune.inf.ethz.ch (129.132.101.33) dans le repertoire Oberon. Il en existe des versions pour SUN SPARC, Windows, DOS,... ----------------------------------------------------------------------- Jean-Marc Bourguet Service d'Electronique Faculte Polytechnique de Mons Tel : +32 65 37.42.23 Boulevard Dolez, 31 Fax : +32 65 37.42.36 7000 Mons Email : bourguet@muelec.fpms.ac.be Belgique From dpw93@ecs.southampton.ac.uk 27 Oct 94 15:33:22 GMT Date: 27 Oct 94 15:33:22 GMT From: David Wragg dpw93@ecs.southampton.ac.uk Subject: Watershed -- what's up ? Francois-Rene Rideau writes: > [ ... ] > > Then, perhaps STAPLE is for you. It's a persistent computing system, based > on a lazy functional programming language. > > FTP://ftp.dcs.st-and.ac.uk/pub/staple staple > http://lochnagar.dcs.st-and.ac.uk:8080 staple > > Tell me if you use it and what you think about it. > I'll look at it very soon. > > But pure functional semantics have a big problem - they don't go well > > with user-interfaces, since user-interfaces rely heavily on a concept > > of state. > If you really want heavy side effects perhaps Scheme is for you. > See the WWW page > http://www.ai.mit.edu/projects/su/su.html (Scheme Underground) > for information about people rewriting OS stuff in Scheme. > But as for persistence, I don't think it's entirely included in the system. > I've heard of this project. I really want to have no side effects, many of my reasons for turning to function semantic rely on a lack of side effects. I think I have ideas on how to crete a stateless user interface (this is not as bad as it sounds), and I might experiment with this in the near future, but it seems silly to do work that I'd have to repeat for Watershed, unless there are important things I can learn from it. > > And that's about it. I'm confident that this is a "better" design than > > the one I had before, but it relies on too many things that are still > > being researched by people worldwide. > Please mail me as you progress on your quest. > > > > Please write and tell me what your aims are. If you are interested, > > I'll try to write out my current design more fully. > I also like functional programming, but I know what a computing system must > provide is *useful services*, that is, *reuse*. *Reuse* does mean > object-orientation (i.e. term-dependent types);it also mean security, > thus program typing and specification. Most functional languages go for code reuse through modules (especially SML). > A dynamic interactive persistent system should mean (I'm only 90% sure) > dynamic typing. So all these do not match the functional languages I know. > So I'm looking for a language with all these features, and am looking around > BETA, SELF, ICON, Scheme, SML; but if I need do it, I'll design my own > language, as an extension to one of these perhaps. > Yes, I am also unsatisfied with functional languages because their type systems are not sufficiently powerful (compared to the type systems of OO languages). I think this is because they derive from lambda-calculus, which is very weakly typed (mathematicians know nothing about types). Even strongly-typed functional languages lack power and flexibility in this respect. As far as I know, no-one has extended the lambda-calculus to include a polymorphic type system. I'm not sure how difficult a mathematical exercise this would be. Regards, Dave W. From jecel@lsi.usp.br Thu, 27 Oct 94 17:14:44 EDT Date: Thu, 27 Oct 94 17:14:44 EDT From: Jecel Mattos de Assumpcao Jr. jecel@lsi.usp.br Subject: MOOSE Project -- new OS ? Sorry about the previous attempt to send this message: it got truncated along the way :-( > > I am also writting my own OS. You can read about it in the WWW as: > > http://www.lsi.usp.br/~jecel/merlin.html > I've read it. Re-mail me when you update it. Ok. I should add actual information to these pages by next week. Right now they are a bit too vague... > >> [ The project is called MOOSE ] > > So, why can't you change it now? > Who said I couldn't ? I told the name just for the few who know it. Right. I thought you didn't sound too pleased with it. While I like my project's name fine, there are too many Merlins around so I may be forced to change it. > > I agree. But any language can have persistence added to it ( see > > the Texas system in ftp://cs.utexas.edu/pub/garbage ) > Nope. C can't. You need scoping. I was thinking about heap allocated objects only, as C already treats stack based objects differently. ( The Texas project and Sony's Apertos are both written in C++ ). > > Smalltalk/Self bytecodes are also a good choice. > Yes, I've thought about that. Where can I have self *implementations* ? > There are also lots of papers. Which to read ? You can FTP the current implementation ( SPARC machines only ) from self.stanford.edu. You can get it via WWW from http://self.stanford.edu Though the paper "Self: the Power of Simplicity" is very obsolete, I think it is still the best introduction. Then I would read "Organizing Objects without Classes". The current release's manuals would be the best thing to read after that. Most of the other papers are about implementation techniques. > > I don't think you can get rid of a nanokernel-like system. Something > > must field the interrupts. > The interrupts are for device drivers, not for the kernel. Really, I see > nothing that really belongs to the kernel. Messaging protocols belong to > messaging objects. We really should detach the high-level specifications > from its low-level implementation. Everything in the OS should be > reimplementable. As you mentioned multiusers earlier ( I think ), there should be some protection of the very low level objects from the application level. > In my system, everything is "user object" somehow. > But everything shouldn't be left to nomal human users, especially if money is > involved. The problem is I can't imagine a system where one could read a > document, but not copy it and produce another document identical but for the > signature. As long as the problem is "Is the document written by the author", > everything is ok; now, if the problem is "Has the author written the document" > it becomes much harder. You might want to apply some kind of digital signature system here. This ties the author identification to the document's content so that neither can be altered independently. By "user objects", I meant objects which represent a user ( like a user account in Unix ). Every application involves three "users": an application viewer pseudo user, an application editor pseudo user and a programmer user. When you get an object created with the application, the viewer user is added to your system. If you want to change the object you received, the editor user must be installed, be doing so required that you register and pay for the software. The programmer user tells you how to pay the program's author. I am using these pseudo users roughly like some kind of module system. > > I use Self. It is very good and getting much better! > Where can I contact the SELF community ? There is a mailing list at "self-interest@self.stanford.edu" which you can subscribe to by mailing to "self-request@self.stanford.edu". It has been rather quiet, lately, as they have been preparing to show the next generation Self system at OOPSLA'94 this week. If you want the email addresses of some Self group members, I can look them up for you. > > Feel free to write me if you want more details about my work. > Yes I do. I also found the description of the Pios project interesting. And in France, the Moostrap language ( while not what you want ) is very interesting - it is a simpler and more reflective version of Self. Good luck with you project! -- Jecel From rideau@clipper Fri, 28 Oct 94 2:00:57 MET Date: Fri, 28 Oct 94 2:00:57 MET From: Francois-Rene Rideau rideau@clipper Subject: MOOSE project status As I recall you, the MOOSE project is the project for a computing system (not only what is commonly called operating system) with * persistence (system life is permanent, state is conserved after shutdown), * security (objects are typed, and even have specification), * object-oriented-ness (types as first-order objects and depending on them), * no-kernel (objects interact arbitrarily through optimally fit protocols), * lazy partial evaluation (objects are evaluated and optimized on need), * a built-in self-extensible dynamic language (no distinction between high-level development languages, shell, and scripting languages) * an efficient portable low-level language (with needed interpreter/compiler back-ends, and trivial interface from high-level language) * specifications open for a distributed implementation The critical points are * the type system, which should be generic enough to allow *any* language to use directly system types; types must thus be parametrizable. * the high-level language, which should allow full use and specification of the system resources. * most basic protocols. Well, the MOOSE project (as we still name it) has got (only) four members; but I think we may join the PIOS project, which is some nine more people, and perhaps the merlin project, which is one more. Sorry for the delay, but the language choice is a really big problem. In the MOOSE group, we have Fare = Francois-Rene Rideau = rideau@clipper.ens.fr Kyle = Kyle Hayes = kyle@putput.cs.wwu.edu jvs = Johan Van Schalkwyk = jvs@iconz.co.nz bkyee = Ban Keong Yee = bkyee@mtu.edu For PIOS, contact Mike Prince (mprince@crl.com). Because of an address mistake, I've missed the PIOS discussion, so I dunno if there's any incompatibility between the projects (but it seemed there shouldn't be). Merlin is Jecel Mattos de Assumpcao Jr. (jecel@lsi.usp.br). There's a WWW page that I've not finished reading yet. There are also a lot of people interested in MOOSE progress, who may be future users or developpers if the system ever gets usable. Current status is: * only general goal settled * ftp site: frmap711.mathp7.jussieu.fr:pub/scratch/rideau/moose/ Current schedule is: Organization: * See what if PIOS, MOOSE and/or Merlin will merge * Settle a stable mailing list (ens.fr has got a daemon for such things) * See how tight the team can be (i.e. irc meetings or only mail ? ftp sites ?) Contents: * See what existing language or OS to use or extend if any; thus study them * See what platforms are current targets Any suggestion welcome. -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From rideau@clipper Fri, 28 Oct 94 2:04:25 MET Date: Fri, 28 Oct 94 2:04:25 MET From: Francois-Rene Rideau rideau@clipper Subject: MOOSE: other existing projects (ever sorry for broken english) We still do not know what language to use. One may think it's a superfluous question, and say that the system should be language-independent anyway, but actually it is *not*, as the object semantics of the language will limit the object semantics of the system. Language suggestions are * SELF a pure OO language * BETA a modern OO approach -- BETA is better * SML a strongly-typed functional language * Scheme an untyped (but run-time checked) functional language * Sather an OO language * Gopher ?? * Oberon an OO language and system * FORTH an untyped low-level postfix functional language Existing systems or projects that may be worth looking at (or may already be what we need) are: * STAPLE a (persistent (((lazy (functional language)) based) system)) * TAOS a distributed system with a portable assembler * Oberon a OO system * Amoeba a distributed OS * Grasshopper a distributed OS * VSTa a message-passing micro-kernel-based OS All these do not mean we should just choose one and use it as is and/or do nothing more (though it may mean it). It means there are already lots of things done, and we *must* know what is good about them, and perhaps we should use an existing software and "just" extend it. If nothing is usable, we'll have to decide everything from scratch (possible, but much more longer to do, and error-prone). These lists are of course subject to increase. I'll maintain a better annotated list of these. It will be available by ftp in frmap711.mathp7.jussieu.fr in pub/scratch/rideau/moose/papers/comparison. What we should do is study each of these projects: for each language/system considered, one of us must study it, and write a short article about what are the software's (mis)features and lacks, available implementation, available documentation, and what documentation to read first to have an idea, and where to get all of these and who to get in touch with about them. This means a lot of work. I'll do it, but if I must do it alone, it'll be a lot of time before the project decides. -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From rideau@clipper Fri, 28 Oct 94 2:32:59 MET Date: Fri, 28 Oct 94 2:32:59 MET From: Francois-Rene Rideau rideau@clipper Subject: MOOSE ORG: IRC meeting organization Now, as for organizing discussions, what about IRC meetings ? IRC is the global on-line discussion server. If you do not have access to it, you still can rlogin to another member's (eg. me, but the closer, the better) account to use it. What we need is meetings, i.e. all concerned people should be on-line at the same time. So tell me what hours and days are yours so we can gather on these days (please use GMT -- accessible through date -u or with any clock and dictionary); of course, all meetings should be organized with at least 1 week warning. Weekly meetings may be appreciated. -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From rideau@clipper Fri, 28 Oct 94 2:32:17 MET Date: Fri, 28 Oct 94 2:32:17 MET From: Francois-Rene Rideau rideau@clipper Subject: MOOSE: project organization Proposed Organization chart: * we divide work between a hierarchical list of subjects. * Message "Subject:" field will begin by the list of subjects (well, using abbreviations) * Each subject has got a maitainer. * The maintainer will; who must maintain a file about what was said about the subject. * He must provide regularly updated versions through ftp and/or mail. * He also must animate the debate about the subject * Decisions are done by a vote of concerned people. * If nobody disagrees, the maintainer of a subject may also take decisions. * The subject maintainer is responsible for the vote. * If no decision is reachable through vote, the maintainer will ultimately choose, or reorganize a new vote later. * If the maintainer's choice is vetoed by a member, a maintainer for a "higher" subject in the hierarchy is called to decide (or reorganize a vote). * Ultimately, an absolute arbitrary judge is to decide (or say who among those who know will decide). * The ultimate judge is chosen according to an arbitrary but known in advance method. Suggestions: one of the project founders, and/or a rotation between members. His identity may change with time, as long as there is no way to contest it. * Any decision may be later changed if someone can provide new arguments. * The same procedure applies for the new decision. * The choice for subject maintainers and absolute judge choice method are a decision among others. We still need an initial absolute judge. If we join PIOS or Merlin, I'd propose the project initiator, else myself. I also propose myself (or anyone willing for that ungrateful job) as a maintainer for the organization subject (whose mail symbol will be ORG if no one disagrees). -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From mprince@crl.com Thu, 27 Oct 1994 18:42:48 -0700 (PDT) Date: Thu, 27 Oct 1994 18:42:48 -0700 (PDT) From: Mike Prince mprince@crl.com Subject: MOOSE ORG I am happy to see you charging ahead with your ideas, that's the only way to get things done. I am looking to forward to the development of MOOSE and hope that it and PIOS can happily co-exist. I hope you have received my last mailing detailing the comments people made about my initial proposal (of which you were a great contributor). My main personal focus of PIOS will be towards the lower end (kernel stuff). On top of that we need a programming language and operating system proper. I would be pleased to see MOOSE take that position. Good luck and hope to hear from you soon, Mike From mprince@crl.com Thu, 27 Oct 1994 19:04:08 -0700 (PDT) Date: Thu, 27 Oct 1994 19:04:08 -0700 (PDT) From: Mike Prince mprince@crl.com Subject: PIOS Update (Sorry about the delay) Welcome! This message is being sent to four individuals, Francois-Rene Rideau,=20 Jeremy Casas, Andy Thornton, and Luther Stephens. Thank you for=20 expressing interest in investing time in this project. If all goes well, w= e=20 should have sample code running by Christmas, and a basic development=20 environment by February. By then our ranks will be larger. I have had numerous requests for more=20 information, and believe there will be many more interested in helping to= =20 develop PIOS once we get the ball rolling. But for now it's just us five. = =20 Give what time you can, be open for new ideas, and have faith we can=20 resolve our differences and pull together to produce an operating=20 system like none other. In my descriptions of the project I have only scratched the surface of=20 what I would like to do. PIOS will usher in the age of organic=20 computing; when computers behave as organisms. It will provide a=20 foundation upon which OS research can be done easily. It will be the=20 common denominator for all electronic devices, enabling them to=20 exchange information. Lofty goals, yes, but I know we can do it. For now let's call it the PIOS Project. If there is strong belief we shoul= d=20 change the name I am open to suggestions. I will set up a mailing=20 reflector as soon as I can to provide a more convenient forum. In the=20 mean time we should be able to set up mailing lists of each other. =20 Please excuse any mistakes or omissions I have made. I am sorry for=20 this being mailed out a day late. On Wednesday I will be mailing out a=20 more complete picture of what I would like to accomplish with the low- level side of the project. This should begin to steer us in the direction= =20 of the intermediate language and virtual machine. Hope to hear from you soon, Mike Organization =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Based on the responses I received we will be organized as a research=20 group. In the event that the project ever generates revenue, equity will= =20 be distributed during the course of the project based on published=20 estimates of the number of hours team members are contributing. All=20 coding will become the property of the project and will be distributed=20 under the Free Software Foundations GPL. FRANCOIS-RENE I think the OS should be open, so we have a wide-spread Interment support is possible. The misfeatures and bugs become much easier to correct this wa= y, and the OS will be able to spread like Linux. Then, we can add a close in the standard license, so that people who make money out of the system must pay royalties to the authors. The killer-apps can be developed under non-disclosure agreements if you see the needs. ANDREW In order to get any type of wide acceptance I would suggest that the=20 kernel is placed under the gnu copy-left type of agreement and any=20 particular tools could perhaps be marketed FRANCOIS-RENE My opinion is whereas the killer-apps and migration modules such should be commercial/shareware, the "micro-kernel" (that is, enough code to run the O= S on a single CPU system) itself should be released under the GPL, so that th= e system be wide-spread across the net. Such an official net support *is* important (see the Linux community).=20 That didn't prevent Linus from earning directly and indirectly money from h= is=20 work. But it helped the Linux community to multiply across the world. And = I=20 know of no OS with such a support. And if our killer-app is as good as we say, it deserves commercial distribution above the GPL'ed OS. We can also put a condition on the=20 GPL that a GPL'ed version of the OS cannot be used in a commercial=20 environment, which will force companies to buy OS licenses, whereas people= =20 can use it freely (but are welcome if they pay). In any cases, don't expect to earn much money from that project. If you=20 do, that's all the better. And if you don't, I'd rather not being paid for = a successful thing than not being paid for a forgotten project. FRANCOIS-RENE But remember any project deeply *needs* a referee, and won't=20 go faster than the referee. So after all the discussion has been done, a fast decision must come (even to be modified later should *new*=20 elements come). The MOOSE project once died because it had neither referee= =20 nor voting assembly, just raw discussion. FRANCOIS-RENE Basically, you get best results if you decentralize decision so that each subject has its own maintainer. But in case of conflicts, you need a referee (say the subject maintainer or ultimately you). If we are to discus= s and vote, then it must be quick; that's why we need regular meetings whenev= er common subjects are discussed. TALK/IRC sessions are welcome. Mail is viabl= e only if participants reply very quickly. (under IRC, I'm Fare when connected. Please send me a message if you=20 see me). MIKE I will act as the referee for now. Until December 1st when we will split= =20 into two teams, and a second person will become the referee of the=20 second design team. I am playing with the idea that an unchallenged=20 idea becomes law after 3 days. If an idea is challenged then the debate=20 continues until the referee stops it, or until 3 days elapses without=20 challenge (last one to talk wins). No filibusters will be tolerated, only= =20 thoughtful critique. All outcomes must be acknowledged by the referee. =20 The 3 day limit may be waived if 2/3 of the people vote to push it=20 through. FRANCOIS-RENE We need People who participate *regularly*, and reply quickly. The one week latency between message & answer killed MOOSE. Agenda =3D=3D=3D=3D=3D=3D I would like to finalize the first two items on our agenda by 10/31/94. Structure of organization Enumerate goals, finalize mission statement, very important! Please mail your suggestions to me by the 10/29, in order to be=20 integrated into the documents which will act as a guidelines for our=20 project. =20 On 11/1 I would like for our debate to begin on the virtual machine to=20 which our intermediate language will be focused. I would like to have=20 our virtual machine and the intermediate language specifications done=20 by 12/1. I will be mailing out an agenda for November on 11/1. If you=20 have any suggestions please mail them at least two days before. By December 2 we should split into two teams. One team will be=20 responsible for the low level porting of the kernel to different platforms,= =20 and deciding which language to implement it in. The second team will begin developing the tool boxes to enable the=20 kernels to do something useful. Engineering the development=20 environment. Maybe including a HLL to intermediate compiler, user=20 interface, etc. We need to discuss this. FRANCOIS-RENE {development schedule} Oh yes we need one. MOOSE had no schedule and it died because nothing was d= one. Typically, we should have regular meetings and schedule for next meeting; if mail is quick enough, we can have it. But TALK/IRC sessions are better if we are to vote in real-time after discussions. Also, we should write good english in mails as is slows the process, if we can use symbolic stuff= . If you know IRC, we can have an IRC channel with an IRC bot to keep it open= . THIS TOPIC IS OF UTTERMOST IMPORTANCE. Mission Statement =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We are here to design a microkernel based operating system to serve as the basis for the next generation of higher-level operating systems and consumer electronics. The OS is to work seamlessly in a=20 dynamic, heterogeneous, wide area network. It should execute on the=20 largest range of platforms possible, from household appliances to=20 supercomputers. The OS will be the common denominator of all=20 systems. No backward compatibility will be designed in, so as to allow the= =20 highest degree of design freedom. Design Goals =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Application-Centric Paradigm ---------------------------- All commercial OS's are based on the machine-centric paradigm. In this, an application is based on one computer and does communications with other applications on the same machine or others. An application is grounded to the machine it was initially executed on. Due to this perspective =20 software engineers have had a great deal of latitude in typecasting their applications and OS's to one platform, thus reducing their=20 portability. An application-centric OS allows applications, during execution, to be=20 migrated to different machines. Applications engineers can no longer=20 assume certain static attributes of their platforms. The environment=20 becomes a dynamic one. The job of the OS is to allow freedom of the=20 application. FRANCOIS-RENE {Application-Centric Paradigm} I'd say a low-level resource-centric paradigm. LUTHER Once again, I think that a truly portable efficient OS is neither applicati= on nor machine centric. It is really both and neither. A truly portable effici= ent abstracts the concepts of both and connects them. For instance, to applications the OS provides a consistent view of all machines regardless of the hardware. There is storage, process capacity, and some set of device= s (this is regardless of whether the underlying hardware is one "machine" or many). To the machine the OS provides a consistent view of the applications= . machines are respondent to a known set of application requests.=20 I think that this is really what you are trying to imply, however if you really want to take an application centric view, you will eventually run into the same walls as machine centric views do... FRANCOIS-RENE I'd say high-level OS. Do not define bitwise behavior like under Unix/C. Just define high-level protocols, and an abstract intermediate-level langua= ge. Moreover, we'll still need machine-centric layers. Only you'll address them only if you really need to (i.e. play music on a host, and not another= =20 one ten miles away :) Logical Configuration (Virtual Machine) --------------------------------------- The largest object is the tool box. A tool box is composed of an array of arbitrarily sized data and code segments and a number of agents. Code=20 segments are viewed as tools. Data segments are viewed as stacks, however data within the stacks can also be accessed directly. Agents are the=20 execution primitives. Agents execute tools, and have access to the global= =20 tool box stacks, plus their own private array of local stacks. Agents can= =20 move from tool box to tool box carrying their local stacks. FRANCOIS-RENE Why introduce arbitrary differences between objects ? Let the system manage a unified set of entities, called objects, agents, frames, patterns, functions, tool boxes, shit, or whatever you like (though object seems the most natural). If the user language introduces differentiation between objects, let it do so. But this is no OS requirement. What we want the OS to do is providing security protocols, including for type-checking under and between various languages. FRANCOIS-RENE {Logical Configuration} This seems a bit complicated and low-level. Can't we use unifying semantics a la SELF (everything is message-passing) or BETA (everything is a pattern)= ? or STAPLE (everything is a function) ? Let's only have arbitrarily typed objects with a global GC as a basis. Physical Configuration ---------------------- Physically, a tool box resides within one working space, and is usually serviced by one CPU. Normally a working space contains several tool=20 boxes. =20 FRANCOIS-RENE Implementing the OS in a portable fashion over foreign OSes is exactly what should be done. But don't expect having the version that runs over OS X run faster than raw OS X itself !!! Tool Box Migration ------------------ At the discretion of the OS a tool box may be migrated to another working= =20 space. At such time all constituent parts of the tool box (tools and globa= l=20 stacks, resident agents) and bundled up and moved to the new working space.= =20 At the new working space the tool box is unbundled and all tools are either re-compiled, or are deemed better interpreted for overall system performanc= e. The intermediate code is retained in case another move is warranted. FRANCOIS-RENE Moving big objects is not always beneficent. Allowing small objects to migrate seems a better policy to me: when using the "archie" equivalent, th= e search process is migrated, but not including the human interface. Ok. But again, I prefer having as light-weight objects as possible to reduc= e object manipulation overhead. FRANCOIS-RENE=20 That's no problem. What's more problematic is a heuristic to determine the cost of migration. We also need a secure system-wide (which may mean world-wide) object identification protocol. FRANCOIS-RENE {Design Goals Overview} 1. The smaller the objects, the easier the migration. 2. for read-only objects, it may be better not to *migrate* the object, bu= t to propagate copies. 3. Now, what if there is a net split ? Will modifying the object be made impossible ? Then you must copy the object and=20 maintain your own copy. But then, what when the net is one again ?=20 How to merge changes ? There can be several object-dependent (object-parametrizable ?)=20 policies. LUTHER Distributed processing has a lot of implications and hardships. Until some of the communications standards see the "realizable light of day", I don't think that Wide Area Network processing is all that effective. Take for instance WWW (World Wide Web). Even that best sites response times are on the orders of seconds (far too slow for OS activity). Until the ATM and Optical backbones are solidly in place LAN type processing is the most distributed level that you can work at (and high speed lans only function at 100Mb/s, still kinda slow). FRANCOIS-RENE The user won't see it. Every address external to the moved module will be= =20 converted to an absolute system-wide address before being sent. Migration cost and decision is computed as part of a local address space's garbage collection, which in turn is called when scheduling detects suboptimal system performance. Migrating itself is a particular case of saving and restoring objects. It's just restoring the object as soon as possible on another machine ! Resource Management ------------------- Tool boxes can be viewed as resources. Each tool box is named and all=20 inter-tool box communications are vectored according to that name. Names= =20 may be shared by tool boxes, in the case of libraries for which there may b= e=20 instances in several working spaces. All services provided by tool boxes= =20 must, by default, be stateless. Inter and Intra Tool Box Communications --------------------------------------- Agents carry all data in their local stacks. Typically, parameters will=20 be pushed onto a stack before a call, and popped off during the call. =20 The actual parameter passing format is up to the application. FRANCOIS-RENE {Inter and Intra Tool Box Communications} That's well. But why force using stacks ? Some languages have no stack (see ML or LISP implementations), and just use a heap. Let's not specify internal behavior. The only thing is: objects must be able to migrate in some way whatever. Being able to migrate is the same as being able to be saved/restored to/from a file (the file just being transmitted over the net in case of migration). Security -------- All communications (agents) are vectored through a gate upon entry to a=20 tool box. The entry code can choose to do minimal checking to optimize for= =20 speed, or extensive checking to maximize security. This checking is not=20 a function of the operating system, but instead of individual tool boxes. FRANCOIS-RENE To allow some security, we must also provide a regular or permanent logging process which will ensure that all system change will be written in persist= ent memory (that survives power failure). See Grasshopper for that. FRANCOIS-RENE Yes. let's have a compiler-based security system. All binary code *must* be secure. When it comes to migrating it, let's have some optional PGP signature system to ensure that code comes from a trusted compiler or=20 user. FRANCOIS-RENE 1) Require super-user rights to validate any low-level code before=20 =09execution; 2) use the policy: "if the object is addressable, it's usable". 3) Use run-time optimization (i.e. partial evaluation) a la SELF to achiev= e =09good performance even with "object filters" that allow only partial=20 =09access to an object. 4) Now, as for security, what to do when hosts do *NOT* completely=20 =09trust each other ? In a WAN, that's especially critical. The=20 =09answer is: in the WAN, all machines are not equal; each machine has=20 =09levels of trust for other hosts (including distrust due to net link=20 =09quality) which will decide it *NOT* to migrate an object. Intermediate Language --------------------- All code is distributed in an intermediate language, below human programmin= g, but high enough to be applied to a wide range of microprocessors. It will be simple to interpret, and quick to compile down to binary for speed=20 intensive applications. It is expected that human-oriented programming =20 languages will be layered on top of this intermediate language. I would li= ke to do an implementation of c(++) for the intermediate language. Though c would not effectively utilize the attributes of the OS, it would satisfy the short term complaints of those still bound to c. FRANCOIS-RENE An application must rebuild everything but low-level I/O from scratch. This is just unbearable. Also persistent storage and human interface are to be rebuilt every time, which is 95% of current application programming, whe= reas all that stuff should go in generic OS modules. FRANCOIS-RENE I'm myself considering writing a real light & powerful (unlike Unix) OS using (some non-ANSI) dialect of FORTH as a portable low-level language. My idea of specs for the OS seem to match yours (I'd add persistence as an important characteristics for the system; also dynamic strong typing and lazy partial evaluation and garbage collection). FRANCOIS-RENE Because of low-level-ness, programmers must manage raw binary files instead of well-typed objects. Hence they *must* use typecasting. All this is *very= * unsafe, and implies a *slow* OS with run-time checking everywhere, without ensuring security for all that. FRANCOIS-RENE SELF is an OO language that already allows much of what PIOS needs. BETA also is an OO language that has persistence and distributed objects over Unix (though the current implementation is quite trivial) (BTW, C++ or Objective C are definitely *NOT* OO languages; they are just bullshit to me). What I mean is the OS should include type-checking protoco= ls,=20 conventions or mechanism, or else system security and consistency cannot=20 be ensured. Allowing the most generic type-checking (so that any language can be implemented using such protocol) leads us to something "object-oriented". ANDREW - the "intermediate" language you mentioned should be as close to the=20 machine code that will eventually implement it to make for fast=20 translation times. I would suggest a "virtual cpu" approach where a RISC= =20 style cpu is used as a basis. This would also give the advantage that=20 the gnu tools could be used for development - all we need do is make a=20 machine description file for our virtual cpu and make a c/c++ compiler=20 for it using gcc. FRANCOIS-RENE Some kind of FORTH or byte-code is good. See the byte-code interpreter from CAML-light. I've always wanted such a beast. FRANCOIS-RENE=20 Well, not for non-hacker human. But we will still have to manipulate it. And if we do, other hackers may want to use it too. Only they'll have to be superuser on the system. MIKE I have a different idea about strong dynamic typing. The basic OS=20 should not concern itself about the content of objects. This would make=20 the OS very small, and very versatile. On top of the OS, as part of the=20 applications, ANY level of typing could be used. I want the OS to be=20 able to serve as many camps as possible. This way the OS will be a standar= d=20 building block others can use to explore different programming languages. FRANCOIS-RENE That's also how I see it. But allowing any kind of object is definitely *NOT* enforcing low-levelness and disabling any kind of typing (as is the case under UNIX where untyped objects are used). To me it means being able to parametrize declared objects by there type, itself parametrized by its the type universe, etc. A very basic (but powerf= ul) system will provide means to implement any type system inside it; it should also allow explicit mapping to a set of low-level constructors. MIKE In order to steer programmers in the direction of dynamic typing I have=20 contemplated a data encapsulation language to enclose parameters being=20 passed between objects. Objects could use a library of extraction functions to pull parameters. Just an idea though. And it would not be=20 part of the low level OS, a higher level that can be elected to be used. FRANCOIS-RENE That's about what I mean. Again in no case should an object be called with unproper parameters (or worse even -- parameters that would make a process or the system crash). Automatic Stack Contraction/Expansion ------------------------------------- I'm not sure about this one yet. Each stack (tool box or agent) grows from the bottom, and is used like a stack. It has a profile ( max size, grow/shrink increment, and stack pointer). Data can be pushed/ popped from the stack, or accessed arbitrarily inside the range below the S= P. When the stack overflows, the segment is automatically expanded. When memory resources in the workspace run low, garbage collection can commence by contracting stacks that are under utilized (stack top - SP > shrink=20 increment). I believe this might save space by applications using only what they need, and by bundling the memory allocation code in the=20 kernel which might otherwise have many instances in the application code.= =20 What do you think? FRANCOIS-RENE {Automatic Stack Contraction/Expansion} I love stacks. But why have them as OS primitives ? To me, let the OS handle arbitrary objects, and have stacks in what resemble the standard library. Let's have an ever-running garbage collecting system and use it as a criterion for migration. FRANCOIS-RENE What is that segment stuff ? Let's not specify implementation behavior, but high-level response from=20 the system. Synchronization --------------- RAUL : > Semaphores (and mutex) are optimized for the case of serial : > processing. messages are optimized for the case of parallel : > processing. : >=20 : > Imagine a semaphore that works in a system with 200 machines -- : > now imagine each of these machines trying to work with a (usually : > independent) semaphore. : Actually PIOS will be kind of a hybrid, the blocking semaphores are : used for synchronization of the agents. Agents are like messages : and carry the data between and within machines. So it sounds like you're using semaphores at specific machines, and message passing between machines. Further, it sounds like you're trying to structure the code so that transactions can be represented by an agent (which I presume is a short program that indicates (a) which [sorts of] machines to visit, and (b) what to do at each of those machines). RAUL I am wondering at what you plan on doing to avoid/deal with agent Hmm.. I don't see any obvious flaws with this plan.lossage. (e.g. something goes wrong after an agent has completed part of its work). Here's an artificial problem: Let's say you build an agent to do something significant (say, buy a plane ticket). It goes out gets part way through the process then dies. Now, eventually you notice that the agent hasn't completed its work. So, you need some mechanism to sanely pick up where it left off. Now, maybe no one ever uses this os for an airline reservation system. And, maybe it's decided that this class problem isn't appropriate for the OS to attempt to solve. But, every applications which operates in a distributed fashion is going to have a similar aspect. So, there has to be a part of the system which keeps track of all agents which have been issued (presumably this will be any site that creates an agent) and a timeout mechanism for agents that don't "complete on schedule". Furthermore, there need to be tools to debug the process -- both in the manual sense and in the sense of automatic recovery. I think that a lot of the interest in "functional languages" and the like= =20 stem from a need to deal with this class of problem. Specialized Platforms --------------------- For truly speed intensive applications, the actual application code (tool box) would be bundled with the PIOS microkernel and coded in the native=20 machine language. The tool box would be tied to the machine to prevent=20 migration, or an additional copy of the tool box (the intermediate language= =20 version) could be migrated. FRANCOIS-RENE {Specialized Platforms} Again, in a distributed system, some kind of signature must come with any low-level code, that may be checked to verify that any binary code comes from a trusted source. Objects could come with their "equivalents" under such or such assumption; then when migration cost is computed, matching equivalents are taken into account. Persistence ----------- MIKE They sound the same. I'd interpret persistence as the ability of the=20 system to remain running (i.e. no bugs crashing the system) for long=20 periods of time. I would add to that resilience, the ability to survive=20 the failure of several CPU's which are working on part of an application. FRANCOIS-RENE More than that, I'd say persistence would be being able to survive indefinitely, permanently even beyond power-down (on system that don't have permanent memory, this means that the complete system state must be regular= ly logged on permanent media (say, hard disk). Applications ------------ FRANCOIS-RENE The UDD (Universal distributed Database) will arise one day ! FRANCOIS-RENE That's good: demonstrate that we offer not only power, but speed at low cost. But convincing the Fortune-1000 is harder than that: you must provide something that I can't give myself -- maintenance over years. You need some large organization for that. Optimization of Resources ------------------------- Tool boxes should include a benchmark tool, which could be compiled on a number of different machines to determine which has the best fit of architecture to problem. This benchmarking can take place just before= =20 initial execution, or during a re-optimization of resources during executio= n. Taking this measure, plus that of available network bandwidth, estimated=20 communications demands, etc, the tool box could be placed in the most=20 optimal workspace. Notice that we are entering into the territory of a=20 priori knowledge of application demands. FRANCOIS-RENE My opinion is that compile-on-demand and optimize-on-use is the best policy= , that adapts to the users' needs. See SELF about that. I think we need some kind of persistent system with lazy-evaluation like STAPLE. LUTHER Anything you run on top of someone else=92s (OS or whatever) will be bounde= d by their capabilities. I don't think that distributing it across a bunch of someone else=92s boxes will give you that much more capability. There ar= e always bounds (communication link bounds, their bounds, device bounds...) No File System?! ---------------- I don't believe in file systems (maybe I'll change my mind). In any case, I'd like for tool boxes to behave like organic systems, going to sleep on persistent computers when not in use, being brought back to the fast non-persistent computers when being utilized. What is a persistent compute= r? A hard drive with a very dinky CPU could be viewed as a slow slow computer that is persistent, with a very large memory. Using the same algorithm for optimizing the distribution of tool boxes, the less used ones would natural= ly=20 migrate towards the hard drive based work spaces when not in use. I look forward to the day when all computers have soft power switches; ask the=20 computer to turn off, it moves the tool boxes to persistent storage, and th= en turns the power supply off. FRANCOIS-RENE We still FSes to communicate with other OSes and import/export data, though I agree they are not a system primitive. Design Goals Overview --------------------- The migration of processes (tool boxes and agents) during run-time in a=20 =09dynamic heterogeneous environment FRANCOIS-RENE { Fast} This will come later. Concentrate on the power. Small minimalistic microkernel (10-20K) FRANCOIS-RENE=20 Why need a micro-kernel at all ? We need objects, including memory managers and intermediate-code interpreters/compilers, but no microkernel. Only conventions. Nothing in kernel as proper. Everything is loadable/unloadable modules. But there are various moving conventions. FRANCOIS-RENE A high-level OS will hide all the low-level concerns: persistent storage to contain data, machine chosen to run code, low-level encoding of objects, object implementation, human interface code (will be semi-automatically generated). FRANCOIS-RENE I'd prefer a no-kernel OS. Why need a kernel at all ? Let's have a decentralized system. Of course we locally have conventions, but locally means any convention can be later replaced by a better one some day, and the OS part independent from the convention still be valid. This means programming all that in a *generic* language. FRANCOIS-RENE To me the Kernel is 0K. At boot process, we have a boot loader, which loads modules using some dumb convention. A second-level or nth-level loader(s) can change the convention to anything. But basically, we must think in terms of objects that depend one on the other, each using its convention, and calling other objects through a proper filter (itself a needed object). There's no need about a centralized kernel. What we need is good conventions. Each convention/protocol will have its own "kernel"/object. The only requirement is that the system is well founded upon the hardware o= r underlying OS. Application centric Allow for any level of security, based on applications need Parallel processing intermediate language =09not for human consumption Organic System =09"HDD as slow persistent computer" storage (instead of file based) =09No file system?! =09development as an interactive process (FORTH like) Implement initial design on top of existing OS's. =09(distributed file system as improvised network? Or jump straight =09in and do a TCP/IP implementation?) All original coding!! No copies of others work (for legal reasons) Concerns ------------------- FRANCOIS-RENE There are already a lots of systems whose terminology we can reuse. But yes= , an official glossary is needed and when we communicate, we must have a one-to-one word -> meaning mapping. Thus we also need a referee for words. Again, I suggest that the subject maintainer ultimately decides (after vote= ) while the global referee (you) will end discussions if there still are. Glossary is of course modifiable, if *new* arguments come for a new terminology. LUTHER There are a lot of legal and security issues related to embedding in=20 embedded OS's (such as a microwaves). What happens if your OS goes insane and has the microwave turn-on with the door open and kills someone? The idea of embedded productive OS's is one that will come, but there are still a lot of technical issues that have to be resolved by the manufacturers of the products. IT IS GOOD TO BE READY AND WAITING! Microkernel (10-20K) -------------------- =09Processor (application, when run on top of an OS) initialization =09Creation, Bundling and Unbundling for transport, Destruction of =09=09Agents =09=09Tool boxes =09Interpreter (in kernel for speed) =09Compiler (in kernel for security?) =09Automatic segment expansion/contraction control? =09Agent synchronization FRANCOIS-RENE WHAT HIGH-LEVEL LANGUAGE SHOULD WE USE TO MODEL THE=20 OS ? Clearly C is not a HLL. We need a language that's well with persistence, concurrency, etc. BETA and SELF or STAPLE may be such languages/systems. FRANCOIS-RENE No kernel at all ! Only moving conventions. FRANCOIS-RENE Anything that produces low-level code must be trusted (i.e. supervisor mode= ), which does not mean it belongs to the "kernel", even if almost all hosts wi= ll have one. Tool Boxes ---------- =09Inter-microkernel packet communications manager =09Tool box re-allocation algorithms =09Device drivers (HDD,TCP/IP) =09General applications =09High level to intermediate code compiler (gcc?) =09Development tools =09GUI =09Workspace tool box mapping/redirection =09Global tool box mapping/redirection =09Nearby workspace utilization, access speed, etc statistics =09Intermediate code to binary compiler (as resource for versatility?) Research =3D=3D=3D=3D=3D=3D=3D=3D We need to develop arguments as to what makes our project better than=20 theirs. This is to ensure we are not re-inventing the wheel, and to=20 counter arguments from others during the process of garnering support=20 for our cause. Below are some of the OS=92s and languages that have=20 been mentioned in articles and mailings. The fundamental improvement=20 we are making is the ability to move agents during execution, and the=20 goal of a very small useable OS (10-20K). Let me know if I have=20 overlooked/misinterpreted any of the following as not having the ability=20 to do the above. Amber Amoeba BETA CORBA Dome Eden Emerald Grasshopper: http://www.gh.cs.su.oz.au/Grasshopper/ Mach MOOSE: ftp://frmap711.mathp7.jussieu.fr/pub/scratch/rideau/moose/ pvm SELF: ftp://self.stanford.edu/pub/papers STAPLE: ftp://ftp.dcs.st-and.ac.uk/pub/staple Taos Xanadu: http://www.aus.xanadu.com Our Team =3D=3D=3D=3D=3D=3D=3D=3D The following four people have said they would be willing to invest a=20 few hours a week on the project. Here is a little more information about= =20 each one of them. Jeremy Casas -------------------------------- I'm currently working as a Research Associate (a sufficiently vague title)= =20 at OGI. My work here is primarily centered around cluster computing,=20 effective net-resource sharing, and high-level communication=20 protocols/libraries. I finished by bachelors degree in CS from the U. of= =20 the Philippines, Diliman ('90) and then worked in Japan as a systems=20 engineer for a while. In '92, I came here for an MS which I finished by=20 '93. I've been doing research here ever since (1 year or so already). As per papers, I have co-authored the following Ravi Konuru and Jeremy Casas and Steve Otto and Robert Prouty and =09Jonathan Walpole. "A User-Level Process Package for PVM". In =09Proceedings of the 1994 Scalable High-Performance Computing=20 =09Conference. pages 48-55, May 1994. and Jeremy Casas and Ravi Konuru and Steve Otto and Robert Prouty and =09Jonathan Walpole. "Adaptive Load Migration Systems for PVM". To =09appear in Supercomputing '94 proceedings. Nov. 1994. Francois-Rene Rideau =20 -------------------------------------------- I've finished my masters in C.S. (even though I'm still struggling to obtai= n the diploma). The thesis was about translating logical expressions from a language (B, kind of Z cousin -- based on explicit substitutions and joke= rs) to another (Coq -- based on lambda calculus). I'm interested in all the parts of the project, except the low-level specific device-driver stuff (say, write a SCSI interface for such board -- yuck).=20 I also hate *unix* programming, so if there's low-level thing to code, I prefer writing a direct OS (through the PC BIOS to begin with) rather=20 than coding it over *unix*. Not that I deny interest in writing the stuff over *unix*. I am ready for all language-related topics, including implementing the intermediate language, compiling to it and from it. Andrew Thornton ------------------------------------------- My name is Andrew Thornton and I am second year computer science=20 student at Durham niversity, UK. My particular interests are in=20 operating systems and parallel computing so this project is right down=20 my street. I have spent that last year or so reading up on current=20 implementations of micro kernels and parallel processing environments=20 with a view to commencing on a project like this. Luther (l.w.) Stephens --------------------------------------- Currently employeed as a telecommunications software developer with Bell Northern Research. Projects include O-O software design and development of billing systems for telecommunication switching systems. I have a B.S. Computer Engineering from N.C. State University and am currently working on my Master's. Glossary =3D=3D=3D=3D=3D=3D=3D=3D These are the defining terms for our project, Let=92s see if we can finali= ze=20 on the usage and names by the 1st of November. I am not attached to=20 any of the names, they are all fair game. Application-centric: This NEEDS to be changed. I used it to convey an=20 =09idea. Resource centric has been suggested. What shall it be? What=20 =09does it mean exactly? Intermediate language: It would be nice to have a formal name (Like=20 =09Taos' VPcode). PIOS Project: Shall we keep the name? Stack: an array used to store data Tool: an immutable segment of code. Tool Box: a collection of tools Work Space: a collection of tool boxes Virtual Machine: This is what I was describing as the logical=20 =09configuration to which our intermediate code would compile down to. From mprince@crl.com Thu, 27 Oct 1994 19:05:34 -0700 (PDT) Date: Thu, 27 Oct 1994 19:05:34 -0700 (PDT) From: Mike Prince mprince@crl.com Subject: PIOS Virtual Machine and Code Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is our first big test; agreeing on the virtual machine=20 architecture. I have been piecing this virtual machine=20 together for a while now, and every part interplay=92s with=20 every other part. Unfortunately the justification for this=20 model exists on millions of scraps of papers and in my head. =20 This text file was put together in only a few hours and lacks=20 most of my justification for this model, so please give do not=20 be too harsh for the glaring omissions. In time, through=20 discussion, they will all be resolved. As I have said before, nothing is cast in stone, and I am very=20 versatile. Please critique any and every part of this=20 proposal. I would be happy to be proved completely wrong if=20 we end up finding a better way to do this. We can not=20 compromise the project due to individual pride. I am looking=20 forward to you opinions. My date for beginning to discuss the virtual machine/language=20 issue was the first of November, so we are running a little=20 ahead of schedule. You can still look forward to a more=20 detailed agenda of November on the 1st though. Now on to the work... For this project we will need to define at least two=20 languages. First we must define a basic model for our computing world. =20 That model will be represented by a virtual machine. Our=20 tools will be distributed in the programming language of this=20 virtual machine. For now we will call this language vmcode. We could program all our tools in this low level vmcode. But=20 there are two immediate disadvantages. First, we may decide=20 to change the vmcode. If we did, all prior coding would have=20 to be re-written. Secondly, there are many good programming=20 languages already out there that we could choose from. We=20 might even decide to create a hybrid language of our own=20 better suited to programming our virtual machine. I would like to model vmcode and the machine loosely on Forth. Virtual Machine --------------- The largest object is the tool box. A tool box contains=20 tools, stacks, and agents. Tools are executable code and are accessible to all agents=20 within the tool box. The tool box stacks are data global to=20 the tool box. Agents are the execution primitives. Agents have their own=20 stacks which are only accessible to the agent to which they=20 belong. Agents reside in one tool box at a time. Agents can=20 move between tools and tool boxes at the tools discretion. =20 Agents carry their own stacks with them as they move between=20 tools or tool boxes. An agent has two active stacks at any time A and P. A is the=20 stack used for generic operations. P is the path stack and is=20 used as a return stack for program flow control. Each stack=20 also has a stack pointer. Neither A nor P may be a tool box=20 stack (global) when an agent transfers control to another tool=20 box. NOTE: Should we have more active stacks? A floating point=20 stack, secondary stack, loop counter stack, etc?=20 Agents are synchronized through the use of blocking=20 semaphores. All semaphores are stored in tool box stack 2. =20 Semaphores are 32 bits and are referenced as an array. Vmcode=20 has up, down, and setsemaphore primitives. Up increases the=20 value of the semaphore by one. If an agent is blocked on that=20 semaphore, then only one agent will be unblocked and the=20 semaphore will automatically be reduced by one again. A down=20 attempts to reduce the semaphore by one. If the count is=20 already zero the agent blocks until the count can be reduced. =20 A set forces to semaphore to a particular value. Our virtual machine is broken up into domains. Domains are=20 further broken up into work spaces. Each work space can=20 contain one or more tool boxes. A work space may or may not=20 be accessible at any given time (i.e. has been disconnected=20 from the net, turned off, etc). Domains are used to=20 encapsulate groups of work spaces to ensure security or the=20 containment of computational resources. Each tool box provides a name for itself up to 2^7 bytes long. =20 Each tool box has up to 2^15 tools and/or stacks. Each agent=20 can have up to 2^15 private stacks. Each stack is up to 2^31=20 bytes long. NOTE: All the numbers above has lost one bit. In the case of=20 the stacks, agents use positive numbers to reference their=20 stacks, and negative numbers to reference global stacks,=20 resulting in a full 2^16 worth of stacks. Each stacks data is accessible randomly or like a traditional=20 stack. All numbers are stored little endian. Stacks grow=20 upwards. The stack pointer points to the first free byte. =20 Data is not necessarily aligned on word boundaries. Data=20 types are consistently represented on all machines. Stacks are referenced by their number. All positive numbered=20 stacks belong to the current agent. All negative numbered=20 stacks are global and belong to the tool box the agent is=20 currently in. When a stack underflow occurs, error information is pushed=20 onto the agents stack, and a call is issued to mark 0 of the=20 current tool; the error handling routine. That routine may=20 elect to kill the agent, continue on as if nothing happened,=20 or take corrective action. When a stack overflow occurs, the kernel attempts to adjust=20 the size of the stack to accommodate the new data. If the=20 stack cannot be made larger then the tool box is moved to a=20 workspace that can handle a larger stack. There are seven basic data types; 8 , 16, 32, and 64 bit=20 signed numbers, 80 bit floating point numbers(?), strings and=20 blocks. Strings are length delimited arrays of bytes up to=20 2^7 bytes long. Blocks are length delimited arrays of bytes=20 2^31 bytes long. Abbreviations ------------- 8bit,16bit,32bit,64bit: all represent signed numbers F: is an 80 bit floating point number S: is a string of 8bit length plus n bytes of data. B: is a block of 32bit length plus n bytes of data #: is a number of expected type $: stands for any one of 8, 16, 32, 64 (bit=20 numbers), F, S, or B. xx: stands for the byte code for the operation. op: stands for one of the previously mentioned=20 operations. (): surround equations which are resolved by the=20 instruction. []: surrounds optional arguments stack: a 16bit stack number, positive for agent,=20 negative for group. size: a 32bit number. flag: a 16bit number, non-zero if true. Format of Instruction Descriptions ---------------------------------- The first line is what the vmcode assembler would expect, or=20 what a disassembler would generate. The second line is the=20 resultant vmcode. The third line is the affect of the=20 instruction on the stack, to the left of the =3D> is before the=20 operation, to the right is after the operation. The rightmost=20 item on either side of the =3D> is the topmost item on the=20 stack. Items on either side of the =3D> are assumed to be on=20 the agents current stack. The last line is a description of=20 the operation. Instructions ------------ #[.$]=20 xx # -- =3D> # Pushes the number onto the stack. If a type is not defined=20 then 16bit is assumed. =93text=94 xx 8bit data -- =3D> data 8bit Pushes the string plus the string length onto the stack. { ... } xx 8bit data -- =3D> data 8bit Creates a string containing all data between the braces and=20 places it on the stack along with the resultant length. [ ... ] xx 32bit data -- =3D> data 32bit Creates a block containing all data between the braces and=20 places it on the stack along with the resultant length. Pop.$ xx # =3D> -- Pops the number, string, or block off the stack. NOTE: Should this be replaced by a simple #of bytes GetSP -=20 SetSP macro? add.$ sub.$ mul.$ div.$ xx a b =3D> (a op b) Takes the two top numbers off of the stack, and applies the=20 operation leaving the result on the stack. $.to.$ xx a =3D> b Converts types. Does not apply to strings or blocks. NameToolBox xx S =3D> -- Notifies kernel tool box has been renamed. Anchor xx -- =3D> -- Notifies kernel that tool box cannot be migrated from this=20 workspace. UnAnchor xx -- =3D> -- Notifies kernel that tool box can be migrated to different=20 workspaces. Unique xx -- =3D> -- Notifies kernel that this tool box may not be duplicated. NotUnique xx -- =3D> -- Notifies kernel that this tool box may be duplicated. Codify xx stack =3D> flag Creates a code segment from a data segment. The code segment=20 is expected to be intermediate byte code. The segment is=20 scanned for validity, and compiled to binary if deemed=20 necessary. SetA xx a =3D> -- Sets the primary stack to use stack a. SetP xx a =3D> -- Sets the path stack to use stack a. Stack a must be an agent=20 stack. ReadA xx -- =3D> a Gives the current primary stack number. ReadP xx -- =3D> a Gives the current path stack number. SetA.SP xx a =3D> -- Sets the stack pointer for the primary stack. ReadA.SP xx -- =3D> a=20 Returns the value of the stack pointer for the primary stack=20 before the instruction. SetP.SP xx a =3D> -- Sets the stack pointer for the path stack. ReadP.SP xx -- =3D> a Returns the value of the stack pointer for the path stack. NewStack xx stack size =3D> flag Creates a new stack of size, returns true if successful. DeleteStack xx stack =3D> flag Deletes stack and returns true if successful. SizeStack xx size =3D> flag Resizes stack and returns true if successful. NewAgent (Fork?) xx size =3D> flag Creates a new agent in current tool box. Returns false if=20 cannot complete. Size bytes are pulled off the primary stack=20 of the creating agent and placed in agents primary stack. =20 Execution for both continues at the next instruction. End xx -- =3D> -- Terminates execution of current agent. Cleans up stacks. >[.$] <[.$] =3D[.$] >=3D[.$] <=3D[.$]=20 xx # # =3D> flag Compares two values leaving a flag of 0 if false, non-zero if=20 true. LockUp xx -- =3D> -- Locks kernel from compiling any more machine dependent code. PortIn.$ xx 32bit =3D> # Has the CPU do an In from the port. Can only be compiled=20 before a LockUp command is executed. Code in which PortIn are=20 automatically restricted from migrating from their workspace. PortOut.$ xx 32bit xx =3D> -- Has the CPU do an Out to the indicated port. Can only be=20 compiled before a LockUp command is executed. Code in which=20 PortIn are automatically restricted from migrating from their=20 workspace. Up xx a =3D> -- Does an up on semaphore indexed by a. If agents are blocked=20 on that semaphore then one will be unblocked. All semaphores=20 are in stack -2. Down xx a =3D> -- Does a down on a semaphore. If the semaphore is smaller than=20 1 then the agent will block until another agent does an up. =20 All semaphores are in stack -2. SetSemaphore xx 32bit a =3D> -- Initializes a semaphore. Return xx -- =3D> -- Parses path stack for a path to vector execution to. Mark xx -- =3D> -- Indicates to compiler or interpreter a tool entry point. Goto xx {complex} =3D> -- Parses primary stack for path to vector execution to. IfGoto xx S flag =3D> -- If flag is true vector execution to path in string S. Call xx {complex} =3D> -- Parses primary stack to path to vector execution to. Saves=20 return path in path stack. Peek xx size offset source_stack =3D> data Copies size data starting from offset in source_stack onto top=20 of current stack. Poke xx data size offset dest_stack =3D> -- Moves size bytes off current stack into dest_stack staring at=20 offset. Dup.$ xx # =3D> # # Duplicates top item on stack, including strings and blocks. Rot, Pick? How to implement these, do we need these? I know I=92m missing instructions, the previous ones should give=20 you a flavor for the kind of virtual machine and instruction=20 set I would like. Please let me know how big the instruction=20 set should get (# of instructions), what instructions should=20 be added, what we can reduce/get rid of, etc. Program Flow Control =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Herein lays a major obstacle to migrating agents. Because all=20 the stacks have consistent representation between machines,=20 stacks can simply be bundled up and sent. Because our return=20 path is a stack, and exhibits this same behavior, it to can be=20 sent. Security is our first issue. How can we maintain secure=20 communication between tool boxes. First off, we can limit=20 migration of tool boxes to certain domains to minimize their=20 exposure. Secondly, we allow tool boxes to control the gates=20 for agents entering and exiting. All agents entering a tool box must first execute tool 1, mark=20 0. This tool is the incoming gatekeeper code. All agents=20 leaving a tool box are vectored likewise through tool 1, mark=20 2. If no security is desired the code here can simply pass=20 the agent along. However at this point code can encrypt all=20 outgoing agents and their data, and verify all incoming agents=20 validity. The level of security implemented is up to the=20 tool. Return information is stored on the path stack in the=20 following format. Tool box names are stored as strings; data,=20 8 bit length, and the vmcode byte code for push string. Tool=20 numbers are stored as 32 bit tool numbers and the byte code=20 for push 32 bit. Mark numbers are stored as 16 bit numbers=20 and the byte code for push 16 bit. When a return is executed, the path is parsed to determine how=20 to vector the agent. When a call is executed the active stack is parsed to=20 determine how to vector the agent. Immediately the return=20 mark is placed on the path stack. If an agent moves between=20 tools, then the calling tool number is also placed in the=20 path. If the agent moves between tool boxes then the agent is=20 first directed to the gate for the tool box. The gate will=20 then issue a goto to vector the agent to the remote tool box. =20 Before the agent is relocated the tool box name is placed in=20 the path. When a goto is issued that causes the agent to move between=20 tools, the path is evaluated to determine if the top entry on=20 path is tool number or tool box name. If not then the sending=20 tool number is saved in the path. When a goto is issued that causes the agent to move between=20 tool boxes, the path is evaluated to determine if the top=20 entry is a tool box name. If not then the sending tool box=20 name is saved in the path. This is only a partial explanation. Because I would like to=20 encourage more discussion early on I am sending this out=20 incomplete. By next week the full text should be ready. Here are some of my questions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D How many tools/stacks per tool box should we have as a limit?=20 2^15 or 2^31? The smaller lines up nicely with current=20 segmentation schemes of the 486. The larger allows us to=20 manage much larger numbers of objects per tool box. How many more/what kind access instructions should we have for=20 moving data to/from stacks? Should we have more fundamental types of stacks (a floating=20 point one, a loop counter one, alternate one, etc). Should the stack pointer be global or local? If it=92s local=20 then everyone has to have their own copy of SP=92s to every=20 global stack. In addition if we implement automatic stack=20 contraction/expansion then we would have to reconcile the=20 differences between all the agents global SP=92s. If it=92s=20 global than how do we handle the case of two agents accessing=20 the same stack simultaneously (i.e. a two CPU system with=20 shared memory). How do we manipulate the SP then? How do we limit access to global stacks? Should we make the=20 tools manage that themselves using semaphores, or provide=20 primitives for locking the stacks themselves? Any other=20 ideas? How do we represent the agents vmcode IP when moving between=20 workspaces? The crude get it done way is to count the number=20 of vmcode instructions up till the point execution was=20 stopped. Is there a faster way to determine this? A better=20 way, maybe using predefined stall points indicated by marks? =20 Ideas? In what order should we push arrays onto the stack? What language should we program the kernel in? What language should we select for our high level language? =20 Or should we create our own? It is a big leap of faith to jump from a simple RISC virtual=20 machine (TAOS) to a Forth like machine. What are arguments=20 for and against this? What should the format of floating point numbers be, 32, 64,=20 80 bit? Longer Term Plans =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Here is a little glimpse into how I would like for things to=20 turn out. One camp of developers will have full blown=20 development systems to write code in. If our system becomes=20 accepted these will be developed in time, at great expense. =20 For now though, we do not have the time or money. The other camp will write interactively like Forth. This is=20 the one that can be implemented relatively easily and quickly. =20 This also is closer to my idea of organic computing. I would like for the programmer to =93exist=94 within a tool box. =20 The programmer would build from the inside out, testing code=20 as he/she went along. While the programmer was writing code=20 agents could enter into the tool box and exit, or resident=20 agents could continue executing the code they were working on. =20 I believe we could write a simple debug tool that would sit=20 inside the tool box and facilitate this; keeping track of tool=20 names and mark names, sending and receiving information to an=20 assembler, interacting with the programmers interface be it a=20 GUI or simple command line, etc. How about a simple tool that sits in your tool box while you=20 are developing it that just provides a command line interface. =20 The tool could be called the basement, because it lets you=20 work in the lowest part of the OS, giving you an unadulterated=20 view and control of virtual machine. A little further down the line I hope to alleviate device=20 drivers. Each device would come with it=92s open tool box, that=20 would be found by the kernel when starting up and executed. =20 This is very similar to work being done with Open Boot (is=20 that the right name?) that embeds Forth like code that=20 initializes and provides an interface to devices that plug=20 into the computer. Just a few ideas for now. Conclusion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I wrote this to get the ball rolling. I expect for there to=20 be MANY changes to what I have just proposed. Please voice=20 any and all questions and comments. An open dialog is what we=20 need to hash out these ideas. Hope to hear from you soon, Mike From rockwell@nova.umd.edu Thu, 27 Oct 1994 22:40:17 -0400 Date: Thu, 27 Oct 1994 22:40:17 -0400 From: Raul Deluth Miller rockwell@nova.umd.edu Subject: PIOS Virtual Machine and Code Signed numbers? 1s or 2s complement? Arithmetic overflow? How to manage bit maps? Big endian or Little endian? Or we try and hide distinction? How to implement a queue? [does it get the same sorts of monitoring as a stack?] How efficient will this "operating system" be at emulating itself? Raul D. Miller n =: p*q NB. 9<##:##:n [.large prime p, q y =: n&|&(*&x)^:e 1 NB. -.1 e.e e.&factors<:p,q [.e Subject: MOOSE project status > > As I recall you, the MOOSE project is the project for a computing system > (not only what is commonly called operating system) with > [ MOOSE basic features deleted to save spave ] > > The critical points are > * the type system, which should be generic enough to allow *any* language to > use directly system types; types must thus be parametrizable. Maybe it would be better for each language to adapt to the proposed system as you are not going to reuse much existing code. This is the approach Microsoft took with OLE, IBM with SOM and OMG's CORBA. In OOPSLA'94 there was ( I only read about it ) a workshop on language independent object models. > * the high-level language, which should allow full use and specification of the > system resources. Hopefully not BASIC, visual or not :-) This is actually very important - Linux people are now considering using scheme for this ( tcl has come the closest to an "integration language", so far ). > * most basic protocols. This is *very* hard. I guess that is why everyone simply adapts the Smalltalk-80 classes. > Well, the MOOSE project (as we still name it) has got (only) > four members; but I think we may join the PIOS project, which is some nine > more people, and perhaps the merlin project, which is one more. > Sorry for the delay, but the language choice is a really big problem. > > [ MOOSE group and PIOS contact deleted ] > > Merlin is Jecel Mattos de Assumpcao Jr. (jecel@lsi.usp.br). There's > a WWW page that I've not finished reading yet. There is, unfortunately, very little real information on those pages. I hope to fix this by the end of next week, but let me make a brief description of Merlin as related to this discussion: The aim of the Merlin Project is to develop a computer for novices. The idea is not to make a watered down traditional system ( like Jeff Reskin's Cannon Cat ) but rather a powerful and extensible medium ( like Alan Kay's Dynabook ). The technology used is a custom implementation of the Self programming language in a system very much like the description for MOOSE. This is a *commercial* project ( that is, I mean to make money out of it ) that will be distributed in two versions: - Hacker's Merlin: can be installed on existing computers and will be distributed for free but without support. Porting to different machines will be encouraged. - User's Merlin: will be embedded in the ROMs of Merlin computers or licensed computer makers. Both versions will come with the full *source* code and programming environment. They should be identical, or at least very alike, except that any licensed technology ( fractal image compression, for example ) would not be included in the hacker's version. The reason I am explaining all this is because if MOOSE becomes somehow linked to Merlin ( which might be great, but see below ) I will have to rethink the above plans to divide the future profits among the contributors. The current status of Merlin is that it is in the late design phase and in the early coding phase. It has been so far developed on custom hardware, but will now move to either Sun hardware or a PowerPC PReP board. Later there will be a port to the 386. BTW. though I thought that joining Merlin with other projects was very unlikely, I changed the project's official language from Portugues to English in February just in case... > There are also a lot of people interested in MOOSE progress, who may > be future users or developpers if the system ever gets usable. A lot of people are having the same ideas. You have done a good job of getting them together. > Current status is: > * only general goal settled > * ftp site: frmap711.mathp7.jussieu.fr:pub/scratch/rideau/moose/ > > > Current schedule is: > > Organization: > * See what if PIOS, MOOSE and/or Merlin will merge I would love to see that happen, though I don't know yet enough details to know if it is possible. For my part, I will be glad to share any information about Merlin. > * Settle a stable mailing list (ens.fr has got a daemon for such things) > * See how tight the team can be (i.e. irc meetings or only mail ? ftp sites ?) How do the Linux people do it? My impression is that they use mail "channels". > Contents: > * See what existing language or OS to use or extend if any; thus study them I have my opinions on that ( see below ) > * See what platforms are current targets Though I hate them, PCs are one obvious choice. The problem with writting an OS for them is the number of drivers you need. But if you start with IDE hard disks and VGA video cards, you will make most people happy for a while. > Any suggestion welcome. You'll have no lack of them from me, if you really want them ;-) > Subject: MOOSE ORG: IRC meeting organization > > Now, as for organizing discussions, what about IRC meetings ? > IRC is the global on-line discussion server. If you do not have access > to it, you still can rlogin to another member's (eg. me, but the closer, > the better) account to use it. > What we need is meetings, i.e. all concerned people should be on-line at > the same time. So tell me what hours and days are yours so we can gather > on these days (please use GMT -- accessible through date -u or with > any clock and dictionary); of course, all meetings should be organized with > at least 1 week warning. Weekly meetings may be appreciated. It would not be very practical for me to participate in IRC meetings from home ( where I work ), but I could arrange to go to the university and use their computers for that. As I am right in the middle between the US and Europe, I would say that any time you can agree on would be fine with me. > Subject: MOOSE: project organization > > Proposed Organization chart: > * we divide work between a hierarchical list of subjects. > * Message "Subject:" field will begin by the list of subjects (well, using > abbreviations) Good idea. I was doing something like this in my project ( sending mail to myself :-) > * Each subject has got a maitainer. > * The maintainer will; who must maintain a file about what was > said about the subject. > * He must provide regularly updated versions through ftp and/or mail. > * He also must animate the debate about the subject There should be a full archive of all of the messages in addition to the file you mentioned. This file, by the way, could be the seed of the system documentation. In my project I have decided to do all my documenation in HTML so you can read it with MOSAIC or NETSCAPE. It is also a very portable way of having text+figures. My previous Pagemaker and Postscript attempts didn't work out as well. > * Decisions are done by a vote of concerned people. > * If nobody disagrees, the maintainer of a subject may also take decisions. > * The subject maintainer is responsible for the vote. > * If no decision is reachable through vote, the maintainer will ultimately > choose, or reorganize a new vote later. This sounds like the usenet system. Very nice, but slow. I think you will want some details to be decided by groups of one to speed things up ( obviously the not important parts ). > * If the maintainer's choice is vetoed by a member, a maintainer for a > "higher" subject in the hierarchy is called to decide (or reorganize a vote). > * Ultimately, an absolute arbitrary judge is to decide (or say who among those > who know will decide). > * The ultimate judge is chosen according to an arbitrary but known in advance > method. Suggestions: one of the project founders, and/or a rotation between > members. His identity may change with time, as long as there is no way > to contest it. > * Any decision may be later changed if someone can provide new arguments. > * The same procedure applies for the new decision. > * The choice for subject maintainers and absolute judge choice method > are a decision among others. Ok - this system of avoiding deadlocks should avoid the speed problems I mentioned above. > We still need an initial absolute judge. > If we join PIOS or Merlin, I'd propose the project initiator, else myself. > I also propose myself (or anyone willing for that ungrateful job) as a > maintainer for the organization subject (whose mail symbol will be ORG if > no one disagrees). Agreed. You said the subjects will be hierarchical. That means we would later have ORG.MAILING-LIST and ORG.CONTACTS and things like that? > Subject: MOOSE: other existing projects > > (ever sorry for broken english) My native language is not english either, so I don't mind :-) > We still do not know what language to use. > One may think it's a superfluous question, and say that the system should > be language-independent anyway, but actually it is *not*, > as the object semantics of the language will limit the object semantics > of the system. More or less true. Have you seen how SmalltalkAgents can "talk" with C on the Machintosh? > Language suggestions are > * SELF a pure OO language One advantage is that it has a very lightweight object model, which can simulate more complex ones like Smalltalk's. > * BETA a modern OO approach -- BETA is better I have read the FAQ, but don't know much about it. > * SML a strongly-typed functional language I am impressed with what people have been doing with this language ( see recent OOPSLA papers ). > * Scheme an untyped (but run-time checked) functional language It looks like Linux is going this route. But they need to settle on an object standard ( probably CLOS-like, unfortunately ). > * Sather an OO language I didn't see that this really improved on Eiffel as claimed. > * Gopher ?? > * Oberon an OO language and system I would much prefer this over C++. But I don't like static typing. > * FORTH an untyped low-level postfix functional language I love it! I even designed a FORTH CPU as a graduation project. But I wouldn't use it for a very dynamic system like MOOSE unless it was extended to at least a Postscript-like level. Kyle's TSOL language is like a cross between FORTH and Self. For those who like Oberon-like things, look at Craig Chamber's Cecil language ( Craig wrote the second generation Self compiler ). > Existing systems or projects that may be worth looking at (or may already be > what we need) are: > * STAPLE a (persistent (((lazy (functional language)) based) system)) Never heard of it. > * TAOS a distributed system with a portable assembler This looks great! It is the closest thing yet to what I want. Coming soon to an Acorn machine near you... > * Oberon a OO system The windowing system looks like a MS Windows 1.0 clone, though us hackers love how it ties in to the program structure. Small and fast, but to shallow for my taste. > * Amoeba a distributed OS I think Amoeba is now a commercial product. Helios is a very neat Amoeba derivative. > * Grasshopper a distributed OS Looks pretty good, specially the persistence part. > * VSTa a message-passing micro-kernel-based OS I have heard of this, but don't know any details. I can also recomend Sony's Apertos system. At least some of the above systems are closed ( no sources avaiable for hacking ). > All these do not mean we should just choose one and use it as is and/or > do nothing more (though it may mean it). It means there are already > lots of things done, and we *must* know what is good about them, and perhaps > we should use an existing software and "just" extend it. If nothing is usable, > we'll have to decide everything from scratch (possible, but much more longer to > do, and error-prone). I agree that it never hurts to know as many different ways of doing things as possible. As to starting from scratch, it takes much longer but is not necessarily more error-prone. > These lists are of course subject to increase. I'll maintain a better > annotated list of these. It will be available by ftp in > frmap711.mathp7.jussieu.fr in pub/scratch/rideau/moose/papers/comparison. If I new what the criterion for inclusion in the list was, then I might have other suggestions. > What we should do is study each of these projects: > for each language/system considered, one of us must study it, and write > a short article about what are the software's (mis)features and lacks, > available implementation, available documentation, and what documentation to > read first to have an idea, and where to get all of these and who to get in > touch with about them. Good plan. > This means a lot of work. I'll do it, but if I must do it alone, it'll be > a lot of time before the project decides. Well, it was you idea ;-). But count on me to help, even if MOOSE and Merlin don't end up together. Jecel Assumpcao Jr Merlin Computers +Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil +Pontificia Universidade Catolica de Sao Paulo From rideau@clipper Sat, 29 Oct 94 0:39:08 MET Date: Sat, 29 Oct 94 0:39:08 MET From: Francois-Rene Rideau rideau@clipper Subject: OS ORG: name needed I can open a mailing list here at the ENS. But my sysop asks me for the list's name. So we must choose a name for the OS project. if it's MOOSE, I wont have to change my existing files; but well, wherea it sounds good, I don't like the meaning: multi* OO OS & Env PIOS is Processor-Independent OS. None say anything abut persistence or distributedness. Well, after all, the name isn't that important, but as the mailing list address will be given the name, we should choos something, and quick. I'd prefer it to sound good and to be humoristical, and/or accurate. It must also be original enough so that the project won't be mixed up with another one. From rideau@clipper Sat, 29 Oct 94 1:17:00 MET Date: Sat, 29 Oct 94 1:17:00 MET From: Francois-Rene Rideau rideau@clipper Subject: OS ORG: name needed > Well, after all, the name isn't that important, but as the mailing list > address will be given the name, we should choos something, and quick. > I'd prefer it to sound good and to be humoristical, and/or accurate. > It must also be original enough so that the project won't be mixed up > with another one. I'd propose TUNES, which is a GNU-like acronym for: "TUNES is a Useful, Not Expedient, System" and refers to J.S.Mill's Utilitarianism, criticizes today's OSes, is a battle cry (being useful, not expedient -- i.e. think in the long run, do not think about immediate profit of implementatin easiness, but about usability for people years later), and it sounds as well as it can. I just got this idea ('cause I'm jus reading the Mill's book), but I really like it. Any better idea anyone ? If no one disagrees, such will be the mailing list (the sysop will still be able to change or alias the name, or so I hope). (This sounds like a ultimatum) -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From chharris@u.washington.edu Fri, 28 Oct 94 20:36:31 -0700 Date: Fri, 28 Oct 94 20:36:31 -0700 From: Chris Harris chharris@u.washington.edu Subject: MOOSE Project Hello, I've heard a little about MOOSE in the past, but I didn't know it was quite this neat. =) Perhaps you're like super-human or something, but this seems like a rather large project to take on (or even maintain) on your own. As such, I'd like to get any more details you may have about the project, as I might be interested in joining, if you wouldn't mind. In particular, I'd like to know what an object is in MOOSE, and how low-level the stack language is, and what options it supports. I won't have a decent system on my hands for a few weeks (I still need to find a decent one for a decent price), so I can't do anything right away, but I could still take a look. As for a high-level language, I would definately look at self, since it presents one of the best object models I've ever seen. Perhaps models like it will be the way of the future. Not sure how well it fits the other requirements, though. Well, I gotta' run. Look forward to hearing back from you. -Chris > As I'm sick of computing systems I know, and saw no end to them, I've > decided to write my own, on my 386 PC to begin with, but in a portable way > (have an implementation over *yuck* POSIX ?). > > The project is called MOOSE, and I'm writing it alone. It means > Multi-* Object-oriented Operating System and Environment. *I* didn't choose > the name as I wasn't alone at that time. > > It's a project for an OS that will change you from Un*x and > sub-clones like MS-DOG: > - of course multi* (tasking/threading/user) > - persistence, thus garbage collection, security, type-checking (thus, no "C") > that means no *need* of file system (but still support them to communicate > with other OSes. That also means *need* for a language that supports > orthogonal persistence. > - machine-independent low-level (stack-based/FORTH-like ?) language for > portable binaries, with common interpreter or compiler back-end. > - partial lazy evaluation and optimization for ideal dynamic performance > - no-kernel (not even micro- or nano-) architecture. Everything is > decentralized in modules (even the module loaders). The only thing needed > is a boot module. Modules communicate through conventional protocols (which > may change by replacing all concerned modules). > - system specifications open for a distributed version where objects migrate > or are copied on the fly from host to host to achieve best performance > (but security required more than ever). > - Author authentification to retribute authors, or give them (dis)credit. > - dynamic typing high-level (some may say "object-oriented") language as > a standard interactive development tool -- no *need* for a shell and a > bunch of stubborn languages that cope with each other's flaws. All systems > specification are done in such a language. The language should have natural > extensions that allow program specification and proof, and do secure > type-checking. > > I'm still looking for the high-level language to use, which must be able to > integrate all those features. Can somebody help me ? > I'm considering BETA, SELF, Icon, or something like that. Else I'll have to > design my own (as a self-extended typechecking FORTH-like thing ?) :( :(. Any > comments ? > > I'm also considering joining Mike Prince's PIOS project, or the FIRE project. > If there's another project (personal/university/commercial) that includes all > (or a big part) of those features, please tell me. If you see any reason why > it shouldn't be possible or wishable, or that it does not go for enough, or > that it goes in the wrong direction, please tell me too. I *think* I am > open-minded enough to hear it. > > > Any help, comment or feedback appreciated. > Please reply by mail (but you may post your reply *too*), as I may not be > reading your group. Sorry for the noise if you think it doesn't fit the group. > Thanks. > -- > -- , , _ v ~ ^ -- > -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- > -- ' / . -- > MOOSE project member. OSL developper. | | / > Dreams about The Universal (Distributed) Database. --- --- // > Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // > Phone: 033 1 42026735 From rideau@clipper Sat, 29 Oct 94 15:47:18 MET Date: Sat, 29 Oct 94 15:47:18 MET From: Francois-Rene Rideau rideau@clipper Subject: MOOSE Project [This is a reply to a message from Chris Harris, chharris@u.washington.edu; The message is entirely quoted, together with reply] > Hello, > I've heard a little about MOOSE in the past, but I didn't know it > was quite this neat. =) Well, actually, another one began the project (and gave it its name), two years ago, but the project got a SIGSTOP when summer came, and I had much trouble trying to gather the team back after that. The project died because its goal weren't neat at all; but as the only continuator, I could have the whole left team agree ;) and could decide the goals before a new attempt to gather the team. > Perhaps you're like super-human or something, How I'd love to be :) > but this seems like a rather large project to take on (or even maintain) > on your own. That's why I need help from all over the world. > As such, I'd like to get any more details you may have > about the project, as I might be interested in joining, if you wouldn't > mind. Not at all ! So details: 1) Organization status. The MOOSE archive is on ftp://frmap711.mathp7.jussieu.fr/pub/scratch/rideau/moose/* The mailing list will soon reappear, now at ens.fr There are currently 4 MOOSE members, plus (if we merge, which seems to be) 9 PIOS members, and one Merlin member (plus you if you join). 2) Specification status. The goals are setup (the blurb you got) (I'm writing an argued definitive version in good english). The primary target architecture are choosen: a version for 386+ PCs, one that'll run over POSIX, and one for every architecture a member will be willing to port it to. The portable low-level language is still to be choosen, though the original idea is it will be stack-based. The big problem is the high-level language to use, though it seems SELF is a good choice. 3) Distribution policy What is sure is that some working version will be available for free on the internet with a GNU (-like?) Copyleft policy, so that we may create a linux-like community that will support us. But it looks like some of us would want to make money from a commercial version of the system, and nobody seems to have a moral objection against earning money from one's work, as long as no "non-disclosure agreements" will prevent the system from being spread. > In particular, I'd like to know what an object is in MOOSE, and An object is just anything that you might consider, in a context that determines its behavior. That is anything that has a value in any language you use, and that may interact with other objects. Indeed, what actually defines an object is the behavior when being combined with another one, whether you call this combination "function application", "taking a member value", "sending a message", or whatever. This is quite unrestrictive, and indeed, a computing system should let the user be free to choose what kind of objects he'll use. But on the other hand, we must still provide some kind of security, of warranty: firstly, we must provide some standard basic combinators, that will ensure that any kind of computing may be done; then, we must ensure that no object will be ever combined with invalid other objects. Thus, we must have a system that will ensure program validity, i.e. a parametrizable type system (and we know from the Curry-Howard isomorphism, that such type system where types and objects combine freely may be used to implement all the logic, and any kind of program specification). > how low-level the stack language is, and what options it supports. The idea is that the language is portable, generates compact code (for fast network transfer), and allows efficient implementations. A stack language seemed an obvious solution, but the TAOS uses a virtual RISC processor, that maps well on newer RISC architectures; so we're not so sure. > I won't have a decent system on my hands for a few weeks (I still need to > find a decent one for a decent price), so I can't do anything right away, > but I could still take a look. You needn't code anything to be useful. Suggestions, studies, ideas, organization work, writing reports, etc: all these are quite useful. > As for a high-level language, I would definately look at self, since > it presents one of the best object models I've ever seen. Perhaps models > like it will be the way of the future. Not sure how well it fits the > other requirements, though. It really looks like SELF is a good choice for the system's HLL, or at least as a basis to it; but there are things I want about the HLL that I don't think are in plain SELF (though I don't know self well enough): * differentiate objects from their names * allow arbitrary annotation * allow secure validity checks (typing), i.e. semantical checking and not only name checking. > Well, I gotta' run. Look forward to hearing back from you. > > -Chris BTW, as MOOSE may merge with the PIOS and Merlin projects, the name problem arises; so if you have a good idea for a name, tell it ! 'MOOSE' stood for "Multi* OO OS & Env" 'PIOS' is for Processor-Independent OS At the early MOOSE times, there were also OSPREy (for OS PROject), or NT-EPT, D/QN, or Vojy (one letter better than MS-DOS, C/PM or Unix), or 'MTOIS' (pronounce "Empty-O-1-2") "Multi-T* OO Integrated Syst". I just proposed 'TUNES': "TUNES is a Useful, Not Expedient, System", which I like because it has humor, it sounds well (tunes...), it is a GNU-like recursive acronym, and it expresses system philosophy: strive to be useful, not to be something easy to program, to sell, or to agree upon, like the usual commercial stuff or POSIX; and it refers to J.S. Mill's "Utilitarianism". -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From rideau@clipper Sat, 29 Oct 94 15:49:57 MET Date: Sat, 29 Oct 94 15:49:57 MET From: Francois-Rene Rideau rideau@clipper Subject: MOOSE messages (fwd) Forwarded message: >From jecel@lsi.usp.br Sat Oct 29 02:00:18 1994 Received-Date: Sat, 29 Oct 94 02:00:17 +0100 Date: Fri, 28 Oct 94 17:07:19 EDT From: jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.) Subject: MOOSE messages To: rideau@clipper Reply-To: jecel@lsi.usp.br Message-Id: <9410281907.AA02952@ofelia> X-Envelope-To: rideau@clipper.ens.fr Hello, I have merged my comments to your messages into one long chunk to make things easier. You can forward this to the MOOSE list, if you like. > Subject: MOOSE project status > > As I recall you, the MOOSE project is the project for a computing system > (not only what is commonly called operating system) with > [ MOOSE basic features deleted to save spave ] > > The critical points are > * the type system, which should be generic enough to allow *any* language to > use directly system types; types must thus be parametrizable. Maybe it would be better for each language to adapt to the proposed system as you are not going to reuse much existing code. This is the approach Microsoft took with OLE, IBM with SOM and OMG's CORBA. In OOPSLA'94 there was ( I only read about it ) a workshop on language independent object models. > * the high-level language, which should allow full use and specification of the > system resources. Hopefully not BASIC, visual or not :-) This is actually very important - Linux people are now considering using scheme for this ( tcl has come the closest to an "integration language", so far ). > * most basic protocols. This is *very* hard. I guess that is why everyone simply adapts the Smalltalk-80 classes. > Well, the MOOSE project (as we still name it) has got (only) > four members; but I think we may join the PIOS project, which is some nine > more people, and perhaps the merlin project, which is one more. > Sorry for the delay, but the language choice is a really big problem. > > [ MOOSE group and PIOS contact deleted ] > > Merlin is Jecel Mattos de Assumpcao Jr. (jecel@lsi.usp.br). There's > a WWW page that I've not finished reading yet. There is, unfortunately, very little real information on those pages. I hope to fix this by the end of next week, but let me make a brief description of Merlin as related to this discussion: The aim of the Merlin Project is to develop a computer for novices. The idea is not to make a watered down traditional system ( like Jeff Reskin's Cannon Cat ) but rather a powerful and extensible medium ( like Alan Kay's Dynabook ). The technology used is a custom implementation of the Self programming language in a system very much like the description for MOOSE. This is a *commercial* project ( that is, I mean to make money out of it ) that will be distributed in two versions: - Hacker's Merlin: can be installed on existing computers and will be distributed for free but without support. Porting to different machines will be encouraged. - User's Merlin: will be embedded in the ROMs of Merlin computers or licensed computer makers. Both versions will come with the full *source* code and programming environment. They should be identical, or at least very alike, except that any licensed technology ( fractal image compression, for example ) would not be included in the hacker's version. The reason I am explaining all this is because if MOOSE becomes somehow linked to Merlin ( which might be great, but see below ) I will have to rethink the above plans to divide the future profits among the contributors. The current status of Merlin is that it is in the late design phase and in the early coding phase. It has been so far developed on custom hardware, but will now move to either Sun hardware or a PowerPC PReP board. Later there will be a port to the 386. BTW. though I thought that joining Merlin with other projects was very unlikely, I changed the project's official language from Portugues to English in February just in case... > There are also a lot of people interested in MOOSE progress, who may > be future users or developpers if the system ever gets usable. A lot of people are having the same ideas. You have done a good job of getting them together. > Current status is: > * only general goal settled > * ftp site: frmap711.mathp7.jussieu.fr:pub/scratch/rideau/moose/ > > > Current schedule is: > > Organization: > * See what if PIOS, MOOSE and/or Merlin will merge I would love to see that happen, though I don't know yet enough details to know if it is possible. For my part, I will be glad to share any information about Merlin. > * Settle a stable mailing list (ens.fr has got a daemon for such things) > * See how tight the team can be (i.e. irc meetings or only mail ? ftp sites ?) How do the Linux people do it? My impression is that they use mail "channels". > Contents: > * See what existing language or OS to use or extend if any; thus study them I have my opinions on that ( see below ) > * See what platforms are current targets Though I hate them, PCs are one obvious choice. The problem with writting an OS for them is the number of drivers you need. But if you start with IDE hard disks and VGA video cards, you will make most people happy for a while. > Any suggestion welcome. You'll have no lack of them from me, if you really want them ;-) > Subject: MOOSE ORG: IRC meeting organization > > Now, as for organizing discussions, what about IRC meetings ? > IRC is the global on-line discussion server. If you do not have access > to it, you still can rlogin to another member's (eg. me, but the closer, > the better) account to use it. > What we need is meetings, i.e. all concerned people should be on-line at > the same time. So tell me what hours and days are yours so we can gather > on these days (please use GMT -- accessible through date -u or with > any clock and dictionary); of course, all meetings should be organized with > at least 1 week warning. Weekly meetings may be appreciated. It would not be very practical for me to participate in IRC meetings from home ( where I work ), but I could arrange to go to the university and use their computers for that. As I am right in the middle between the US and Europe, I would say that any time you can agree on would be fine with me. > Subject: MOOSE: project organization > > Proposed Organization chart: > * we divide work between a hierarchical list of subjects. > * Message "Subject:" field will begin by the list of subjects (well, using > abbreviations) Good idea. I was doing something like this in my project ( sending mail to myself :-) > * Each subject has got a maitainer. > * The maintainer will; who must maintain a file about what was > said about the subject. > * He must provide regularly updated versions through ftp and/or mail. > * He also must animate the debate about the subject There should be a full archive of all of the messages in addition to the file you mentioned. This file, by the way, could be the seed of the system documentation. In my project I have decided to do all my documenation in HTML so you can read it with MOSAIC or NETSCAPE. It is also a very portable way of having text+figures. My previous Pagemaker and Postscript attempts didn't work out as well. > * Decisions are done by a vote of concerned people. > * If nobody disagrees, the maintainer of a subject may also take decisions. > * The subject maintainer is responsible for the vote. > * If no decision is reachable through vote, the maintainer will ultimately > choose, or reorganize a new vote later. This sounds like the usenet system. Very nice, but slow. I think you will want some details to be decided by groups of one to speed things up ( obviously the not important parts ). > * If the maintainer's choice is vetoed by a member, a maintainer for a > "higher" subject in the hierarchy is called to decide (or reorganize a vote). > * Ultimately, an absolute arbitrary judge is to decide (or say who among those > who know will decide). > * The ultimate judge is chosen according to an arbitrary but known in advance > method. Suggestions: one of the project founders, and/or a rotation between > members. His identity may change with time, as long as there is no way > to contest it. > * Any decision may be later changed if someone can provide new arguments. > * The same procedure applies for the new decision. > * The choice for subject maintainers and absolute judge choice method > are a decision among others. Ok - this system of avoiding deadlocks should avoid the speed problems I mentioned above. > We still need an initial absolute judge. > If we join PIOS or Merlin, I'd propose the project initiator, else myself. > I also propose myself (or anyone willing for that ungrateful job) as a > maintainer for the organization subject (whose mail symbol will be ORG if > no one disagrees). Agreed. You said the subjects will be hierarchical. That means we would later have ORG.MAILING-LIST and ORG.CONTACTS and things like that? > Subject: MOOSE: other existing projects > > (ever sorry for broken english) My native language is not english either, so I don't mind :-) > We still do not know what language to use. > One may think it's a superfluous question, and say that the system should > be language-independent anyway, but actually it is *not*, > as the object semantics of the language will limit the object semantics > of the system. More or less true. Have you seen how SmalltalkAgents can "talk" with C on the Machintosh? > Language suggestions are > * SELF a pure OO language One advantage is that it has a very lightweight object model, which can simulate more complex ones like Smalltalk's. > * BETA a modern OO approach -- BETA is better I have read the FAQ, but don't know much about it. > * SML a strongly-typed functional language I am impressed with what people have been doing with this language ( see recent OOPSLA papers ). > * Scheme an untyped (but run-time checked) functional language It looks like Linux is going this route. But they need to settle on an object standard ( probably CLOS-like, unfortunately ). > * Sather an OO language I didn't see that this really improved on Eiffel as claimed. > * Gopher ?? > * Oberon an OO language and system I would much prefer this over C++. But I don't like static typing. > * FORTH an untyped low-level postfix functional language I love it! I even designed a FORTH CPU as a graduation project. But I wouldn't use it for a very dynamic system like MOOSE unless it was extended to at least a Postscript-like level. Kyle's TSOL language is like a cross between FORTH and Self. For those who like Oberon-like things, look at Craig Chamber's Cecil language ( Craig wrote the second generation Self compiler ). > Existing systems or projects that may be worth looking at (or may already be > what we need) are: > * STAPLE a (persistent (((lazy (functional language)) based) system)) Never heard of it. > * TAOS a distributed system with a portable assembler This looks great! It is the closest thing yet to what I want. Coming soon to an Acorn machine near you... > * Oberon a OO system The windowing system looks like a MS Windows 1.0 clone, though us hackers love how it ties in to the program structure. Small and fast, but to shallow for my taste. > * Amoeba a distributed OS I think Amoeba is now a commercial product. Helios is a very neat Amoeba derivative. > * Grasshopper a distributed OS Looks pretty good, specially the persistence part. > * VSTa a message-passing micro-kernel-based OS I have heard of this, but don't know any details. I can also recomend Sony's Apertos system. At least some of the above systems are closed ( no sources avaiable for hacking ). > All these do not mean we should just choose one and use it as is and/or > do nothing more (though it may mean it). It means there are already > lots of things done, and we *must* know what is good about them, and perhaps > we should use an existing software and "just" extend it. If nothing is usable, > we'll have to decide everything from scratch (possible, but much more longer to > do, and error-prone). I agree that it never hurts to know as many different ways of doing things as possible. As to starting from scratch, it takes much longer but is not necessarily more error-prone. > These lists are of course subject to increase. I'll maintain a better > annotated list of these. It will be available by ftp in > frmap711.mathp7.jussieu.fr in pub/scratch/rideau/moose/papers/comparison. If I new what the criterion for inclusion in the list was, then I might have other suggestions. > What we should do is study each of these projects: > for each language/system considered, one of us must study it, and write > a short article about what are the software's (mis)features and lacks, > available implementation, available documentation, and what documentation to > read first to have an idea, and where to get all of these and who to get in > touch with about them. Good plan. > This means a lot of work. I'll do it, but if I must do it alone, it'll be > a lot of time before the project decides. Well, it was you idea ;-). But count on me to help, even if MOOSE and Merlin don't end up together. Jecel Assumpcao Jr Merlin Computers +Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil +Pontificia Universidade Catolica de Sao Paulo From rideau@clipper Sat, 29 Oct 94 16:42:51 MET Date: Sat, 29 Oct 94 16:42:51 MET From: Francois-Rene Rideau rideau@clipper Subject: (MOOSE?) ORG: merging in progress *THIS IS A CALL FOR VOTE*. Please send me your vote (conditional votes accepted) and comments. I'll summarize, and we'll have a second vote. ------------------------------------------------------------------------------ CONCERNED PEOPLE (Exerpt from my ~/.elm/aliases.text file): [Merlin] jecel = Jecel Mattos de Assumpcao Jr. = jecel@lsi.usp.br [MOOSE] Fare = Francois-Rene Rideau = rideau@clipper.ens.fr Kyle = Kyle Hayes = kyle@putput.cs.wwu.edu jvs = Johan Van Schalkwyk = jvs@iconz.co.nz bkyee = Ban Keong Yee = bkyee@mtu.edu chris = chris Harris = chharris@u.washington.edu [PIOS] mp = Mike Prince = mprince@crl.com rauldm = Raul Deluth Miller = rockwell@nova.umd.edu PIOS = PIOS project = mp,rauldm,me,casas@cse.ogi.edu,A.J.Thornton@durham.ac.uk garrett@thunder.indstate.edu, jeremy@syslab10.cs.SunySB.EDU, luthers@bnr.ca, ravi@cwis.unomaha.edu, srini@aqualung.columbiasc.ncr.com, y85steda@und.ida.liu.se ------------------------------------------------------------------------------ CONTENTS: have a new kind of OS not like existing widely-available commercial ones: - multi* (users, subusers, tasks, subtasks, threads, subthreads, etc) - persistence (indefinite system life span) - distributedness (no low-level host consideration unless needed) - lazy evaluation/optimization (no unneeded things; performant needed things) - language independence (any kind of object in any model *as system object*) - system-level object security together (parametrizable typing) with - a portable low-level language (with proper interpreter/compiler backends) - a high-level OO language to describe the system. HLL specs: - Object-oriented: types and terms are in the same universe. - allows any kind of object annotation dynamically, notably comments, equivalents in other languages (or the same language !), etc. - allows easy lazy evaluation semantics. - self-extensible syntax - powerful module mechanism ------------------------------------------------------------------------------ LICENSING: - a fully operational version freely available under the GPL or such, to attract support from a the community of internet hackers (a la Linux). - commercial/shareware versions with additional objects, apps, modules and whatever, and also support/warranties to satisfied the natural greed of the project members (not excluding myself ;). Shares according to work accomplished (if work can be measured !) or some equitable method anyway. ------------------------------------------------------------------------------ ORGANIZATION: - a democratic organization, with hierarchical division of work according to various subjects. - a quick decision procedure (in cases democratic vote is not needed or asked, or did not end by an agreement) to ensure proper decisions will be taken ------------------------------------------------------------------------------ EXISTING STRUCTURE: - a mailing list (still manual at this time -- I'll open one @ens.fr as soon as we've got a name, if we ever merge) ------------------------------------------------------------------------------ SCHEDULE: Once the major decisions (i.e. languages to use) are taken, everything should go fast; but we do need make those decisions while knowing what they mean. So we should: - collect information from all other existing OS or language projects. - write reports to compare those to each other and to our specifications - choose what languages to use - run for it [in any way, it seems that SELF is a good starting point as for language decision; but I'd still ask that we compare to other existing stuff] ------------------------------------------------------------------------------ PROJECT NAME: The three projects are called (in alphabetical order) Merlin, MOOSE, and PIOS. So we must choose a name. I just proposed TUNES (Tunes is a Useful, Not Expedient, System); but of course, the name should be democraticly decided. ------------------------------------------------------------------------------ CONCLUSION So if no one disagrees, let's merge those three projects. We can still split later, if we later disagree; but I think the more we are, the stronger we are, and the less bugs and stupidities we say without being corrected by others (when you're alone, you often commit mistakes, and are very long before understanding it). But to work together, we must strongly agree upon the *goals*. If we do not, then we cannot work as a team, whereas if we do, it'd be a pity not to join our efforts. So, if you do not like these goals, then perhaps we cannot merge (or we merge without you :( according to other people's vote). If you have minor corrections to add, please do. ------------------------------------------------------------------------------ I'm waiting for your votes. Then I'll summarize for a second, definitive vote. -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From fare Mon, 31 Oct 94 02:00 MET Date: Mon, 31 Oct 94 02:00 MET From: Francois-Rene Rideau fare Subject: MOOSE blurb Newsgroups: comp.lang.asm.x86 Subject: MOOSE Project -- new OS ? Distribution: world Mail body next line: As I'm sick of computing systems I know, and saw no end to them, I've decided to write my own, on my 386 PC to begin with, but in a portable way (have an implementation over *yuck* POSIX ?). The project is called MOOSE, and I'm writing it alone. It means Multi-* Object-oriented Operating System and Environment. *I* didn't choose the name as I wasn't alone at that time. It's a project for an OS that will change you from Un*x and sub-clones like MS-DOG: - of course multi* (tasking/threading/user) - persistence, thus garbage collection, security, type-checking (thus, no "C") that means no *need* of file system (but still support them to communicate with other OSes. That also means *need* for a language that supports orthogonal persistence. - machine-independent low-level (stack-based/FORTH-like ?) language for portable binaries, with common interpreter or compiler back-end. - partial lazy evaluation and optimization for ideal dynamic performance - no-kernel (not even micro- or nano-) architecture. Everything is decentralized in modules (even the module loaders). The only thing needed is a boot module. Modules communicate through conventional protocols (which may change by replacing all concerned modules). - system specifications open for a distributed version where objects migrate or are copied on the fly from host to host to achieve best performance (but security required more than ever). - Author authentification to retribute authors, or give them (dis)credit. - dynamic typing high-level (some may say "object-oriented") language as a standard interactive development tool -- no *need* for a shell and a bunch of stubborn languages that cope with each other's flaws. All systems specification are done in such a language. The language should have natural extensions that allow program specification and proof, and do secure type-checking. I'm still looking for the high-level language to use, which must be able to integrate all those features. Can somebody help me ? I'm considering BETA, SELF, Icon, or something like that. Else I'll have to design my own (as a self-extended typechecking FORTH-like thing ?) :( :(. Any comments ? I'm also considering joining Mike Prince's PIOS project, or the FIRE project. If there's another project (personal/university/commercial) that includes all (or a big part) of those features, please tell me. If you see any reason why it shouldn't be possible or wishable, or that it does not go for enough, or that it goes in the wrong direction, please tell me too. I *think* I am open-minded enough to hear it. Any help, comment or feedback appreciated. Please reply by mail (but you may post your reply *too*), as I may not be reading your group. Sorry for the noise if you think it doesn't fit the group. Thanks. From fare Mon, 31 Oct 94 02:01 MET Date: Mon, 31 Oct 94 02:01 MET From: Francois-Rene Rideau fare Subject: MOOSE blurb in comp.compilers As I'm sick of computing systems I know, and saw no end to them, I've decided to write my own, on my 386 PC to begin with, but in a portable way (have an implementation over *yuck* POSIX ?). I'm still looking for the High-level language to use, which must be able to integrate all the features described below. Can somebody help me ? I'm considering BETA, SELF, Icon, or something like that. Else I'll have to design my own (as a self-extended typechecking FORTH-like thing ?) :( :(; but as our moderator say, the world is not ready for yet another language, so if I can skip the language design phase, I'd be very happy. The project is called MOOSE, and I'm writing it alone. It means Multi-* Object-oriented Operating System and Environment. *I* didn't choose the name as I wasn't alone at that time. It's a project for an OS that will change you from Un*x and sub-clones like MS-DOG: - of course multi* (tasking/threading/user) This implies a language not centered toward global variables (no "C"), with an ability to understand concurrency (with current-continuations ?). - persistence, thus garbage collection, security, type-checking (thus again no "C") that means no *need* of file system (but still support them to communicate with other OSes. That also means *need* for a language that supports secure type-checking and orthogonal persistence. - machine-independent low-level (stack-based/FORTH-like ?) language for portable binaries, with common interpreter or compiler back-end. This implies nothing for the HLL. - partial lazy evaluation and optimization for ideal dynamic performance This implies a HLL with lazy evaluation semantics. - no-kernel (not even micro- or nano-) architecture. Everything is decentralized in modules (even the module loaders). The only thing needed is a boot module. Modules communicate through conventional protocols (which may change by replacing all concerned modules). This implies the existence of a good module system for the HLL (unlike the C header file bullsh*t). - system specifications open for a distributed version where objects migrate or are copied on the fly from host to host to achieve best performance (but security required more than ever). If the language is truely high-level, this shouldn't affect it. - Author authentification to retribute authors, or give them (dis)credit. It would be *very* useful if the language allowed arbitrary annotation of objects, which may mean things about object equality semantics (if association tables are to be built). - dynamic typing high-level (some may say "object-oriented") language as a standard interactive development tool -- no *need* for a shell and a bunch of stubborn languages that cope with each other's flaws. All systems specification are done in such a language. The language should have natural extensions that allow program specification and proof, and do secure type-checking. That's the language I'm looking for. I'm also considering joining Mike Prince's PIOS project, or the FIRE project. If there's another project (personal/university/commercial) that includes all (or a big part) of those features, please tell me. If you see any reason why it shouldn't be possible or wishable, or that it does not go for enough, or that it goes in the wrong direction, please tell me too. I *think* I am open-minded enough to hear it. Any help, comment or feedback appreciated. Please reply by mail (but you may post your reply *too*), as I may not be reading your group. Sorry for the noise if you think it doesn't fit the group. Thanks. From fare Mon, 31 Oct 94 02:03 MET Date: Mon, 31 Oct 94 02:03 MET From: Francois-Rene Rideau fare Subject: Re to Johan Van Schalkwyk >From rideau Sat Oct 22 15:23:17 1994 Subject: Re: MOOSE Project -- new OS ? To: jvs@iconz.co.nz (Johan Van Schalkwyk) Date: Sat, 22 Oct 94 15:23:17 MET In-Reply-To: ; from "Johan Van Schalkwyk" at Oct 23, 94 12:37 am X-Mailer: ELM [version 2.3 PL11] > 1. I have played around in several languages, but apart from assembler, > the only one that I have found to be more or less what I've been looking > for has been Lisp. It is however crippled by its parentheses (not just > "LISt Processing" but "Lots of Irritating Single Parentheses". Also, > parsing Polish notation from left to right is a real pain in the a***! Yes, I like those languages; but I also like typing, because type errors are a pain in the * to correct, whereas they are automatically findable. See ML for a typed functional language (CAML-light on ftp.inria.fr is a free imlementation that runs on macs, pcs and unices). > 2. So I've played around with what I call "POWER" parsing (for POlish > With Evaluation in Reverse). Let me give you an example: In Lisp you > might write something along the lines of:- Well, I mean no offense, but syntax is not what's the most important to me. To me, semantics are quite more important, and user-level macros or parsers should allow any type of syntax one likes. > 3. This basically defines my top level. Obviously, there are a hell of a > lot of technicalities, etc. It is quite workable. I can control > practically every aspect of eg. a PC's function with about a hundred > verbs. Also, logical extensions to the language are easy and intuitive. > Let us say you have a verb AtX that moves the cursor position on > screen to the position specified by (leaving the Y position > unchanged). If you want to define a verb that finds the current X > position on screen, you _might_ define it as WhereX (adding > another verb to your endlessly growing list), but I find it more mnemonic > to just have something like: > > > AtX ? That's prolog-like definition of a name according to what is input or output. I like it. But perhaps the BETA way of doing it (having an x subobject, where any object setting calls an object-defined function) is better. I dunno. > 4. Okay, that's quite enough about my crazy language - you probably think > that I'm totally nuts, by now. I just wanted to give you a flavour of > what I'm playing around with. If I thought so, I wouldn't answer (or perhaps something like "go to hell"). But I think you're overstressing the syntax. I myself lost several years for the same reason. What Iearnt those last years when I could see the world through internet and CS courses, is that semantics (i.e. the meaning, the contained thing) is more important than syntax (i.e. the aspect, the container); this I've always known, but it somehow became clear and obvious to me. Of course, badly designed syntax won't allow easy description of the semantics, but I'm sure that semantics should be designed first, and that syntax should be designed and modified to conform to it. Please think about it. I'm talking from experience I'd like to share. I lost much too much time thinking about the perfect natural-language like or simple-constructor based syntax. > 5. [...] > I feel that one of > the reasons why languages such as C tend to be non-intuitive and ugly to > program in (my crazy opinion, anyway) is that the design does not stress > a minimal approach - they seem to never have heard of orthogonality. Quite so. > Also, I really believe that whenever you program a computer to do > anything more than an absolutely trivial task, you are effectively > creating a language (even if it is just a very simple language where all > the instructions consist of pressing a few keys or clicking a mouse on a > menu). I can't agree more. That's why it's stupid to have a new language for every new thing: everyone would need a different language; it'd be the Babel tower. What we need is a single language that can extend itself naturally, specialize to any field of computing. > So if you are working on a high level, you are effectively working > within a whole hierarchy of complex and badly designed languages, and > trying to create your own little "language" on top of this. The lower > levels are meant to be transparent, but this is almost never the case. > The more complex the setup, the more likely an intermittent and > irritating error is. > The solution as I see it is to keep things > absolutely simple (a la RISC), and rigorously exclude any instructions/ > constructs that impair lucid interpretation on any level. Yes, and no (according to the point of view). Yes, basic constructors should be simple, so the semantics is easy to understand. But no, everything shouldn't be done directly from those simple construtors. That would mean always doing low-level things. Abstraction is needed. When a program works for any kind of structure with such kind of access, why restrict it to a list-based implementation, or an array-based one ? Every program must be defined in its most generic form, and the user will specialize to the form that allows best performance. Reuse *is* important. Today, reuse above language constructs is 0%, because there is no secure form of genericity in commonly used languages. A language like ML (see CAML-light again), allows genericity; but having complete genericity in ML leads to verbose programs (which is why actual genericity of existing ML programs is a compromise), because ML understands no kind of implicit or partial information passing (which is called Object-oriented techniques). I'm disgusted when I see that 99.9% at least of code being written is just rewriting old stuff for use in a new program, because no reuse thing exists. *That's* why I'm writing a new CS (not Operating System, but Computing System). But also note that for reuse to be possible, security is a must, thus type checking and more than that, program specification. If you can't be absolutely sure that some piece of code you got from someone you don't know will work as you want , you won't ever use it, and you'll be right not to. It was only by seeing the huge library of code available through internet then had to write some code for work without being able to use any part of these library, that I deeply interiorized this need for security. > 6. So I see any programming attempt as part of a continuum. There may be That's exactly what I just said. We constantly need abstracting some part of the code. There is no fixed limit of three or four or any finite number of layers in abstraction (which is why ISO standards try to do with their bullshit OSI layer model). Each program is well defined in its own proper layer of abstraction; and layers are not in a total ordering, but a partial one: if A needs B and C, D needs B and E, there's no reason to put A and D in the same layer, or one above the other; they're just defined in different non-disjoint contexts. > [...] > memory and / or output ports. Unfortunately, we often seem to be driven > by the hardware designers .. they define what is available, we construct > our program (on all levels) around this, rather than saying "WE WANT > THIS. THIS IS OUR STANDARD. WE WILL DEFINE OUR SOFTWARE AS SUCH AND SUCH. > IF YOU CANNOT PROVIDE THIS FOR NOW, WE WILL STILL DEFINE THE STANDARD AS > SUCH, AND WILL JUST HAVE TO MUCK AROUND (ON A SLIGHTLY LOWER LEVEL OF OUR > SOFTWARE HIERARCHY) TO SIMULATE WHAT WE REALLY WANT" !! That's even worse than OSI: just one big level of abstraction, with an arbitrary choice of functions. > 7. The flipside of course is that one should know what one is dealing > with. If I ask for a number, I want to know _exactly_ how long it is, not > some arbitrary assurance from the programming language that it may be > such or it may be such, depending on the system on which we are running, > thank you for nothing! (If I go into a restaurant and order a steak, I > want to know if it is 250g or 500g)! You too see that program specification is needed. I too have known it for a long time, but now, I understand it and why it is needed (and not only a toy). And timing specification can be as useful as effect specification, as our computers will never ever execute programs instantaneously. But as for the *exactly*, it is impossible. *enough* is quite enough. > I have a lot of ideas in this > regard, specifically with respect to assembler design. Tentatively, I > think that there should be just three levels: > > Level 0: lowest level. May need considerable effort / ingenuity to > implement concepts defined on Level 1. But ideally, should all be ultra- > fast and implemented in hardware. All timing should be precisely defined, > and accessible to the next level. Yes, but this level should also be implementation-dependent, and reserved for use by those who *really* want it, in time-critical portions of their programs (i.e. ultra-fast graphics or signal processing, OS code, compiler back-end, etc). Normal users shouldn't *have to* use it. And a code portion could have several equivalents in several different low-level contexts. > Level 1: The "assembler" level. But cf my example above about drawing a > line! I have several ideas about what "ideals" should be implemented on > this level. Assembler is still in the implementation-dependent part to me. Note that I do not want to forbid low-level parts; just to allow not to use them, and to provide portable equivalents (thus a time-critical routine may have several versions to run optimally on different hardware, whereas a non-time-critical routine will only have a slow high-level version). > Level2: The "top" level. Perhaps something along the lines of the > incredibly simple language I gave you a flavour of above. Your language is too low-level to me. Again, I love low-levelness (or I wouldn't be writing an OS !), but only when it is needed. Sometimes (most of the time, once the OS is written, if it really is well written), a high level of abstraction is needed. > You may well find the above ideas too trivial to comment on, or disagree > totally. Please feel free to be completely honest! If you want to hear > more, just say so! Perhaps you could give me a few ideas of your own? I really need someone ready to dirty his hands with the low-level stuff in my OS. Uhappily, whereas I have many ideas, I *know* that this stuff is the non-essential part of the OS. By non-essential, I mean that if I am to convince people helping me in my project and later using my OS, I must have a *working* version, however slow, whereas low-levelness will bring me speed and efficiency but nothing that would make my OS better than it would be if running on a faster computer (that would be available for a higher price, or just by waiting long enough). Thus, I deeply need help from someone who will cope with the low-level details of the system. Will you be that man ? I cannot promise any success, just tenacity. > (I hope there are not too many typos in the above, as I composed it on > the fly). None that I noticed. You really recall me my previous self two years ago: full of good ideas, but without an overview of the why it should be done in such perfectionistic way, and enthousiast about small things when I didn't see the big thing yet. Please do not see any offense in my words. I don't know if I'm older than you (born 28 nov 1973), but I *think* (may be wrong !) I've made more errors than you in the past, and thus have gained a little experience about how things are and should be. Read you soon ! (BTW, can you talk from your site to mine ? do you have IRC connection ?) From dejan@tesla.osf.org Mon, 31 Oct 1994 02:52:23 +0000 (GMT) Date: Mon, 31 Oct 1994 02:52:23 +0000 (GMT) From: Dejan Milojicic dejan@tesla.osf.org Subject: PIOS and Protestant (This is a fake mail from a Usenet message) From: dejan@tesla.osf.org (Dejan Milojicic) Newsgroups: comp.os.research Subject: Re: PIOS and Protestant Date: 31 Oct 1994 02:52:23 GMT Organization: Open Software Foundation NNTP-Posting-Host: ftp.cse.ucsc.edu Originator: osr@ftp >>Nice and wishful visions, if it only were at least a little bit >>beyond the statements. Mach certainly has deficiencies, and I >>would really be happy to see how you suggest to overcome them, >>unfortunately, beside stating what you would like to see (and >>even that in a very, very broad and fuzzy way), I haven't >>found any particular suggestion in your email. > >Before anything is built it is a vision. I have dared to make that >vision public and have been received well by those in the know. The >internet is a place to bring those with ideas together, not a place for >negativity. Next time post questions, not empty comments. Ok, I have three classes of questions: academic, commercial, and general. I apologize if I sounded negative in previous email. On contrary, I would really be happy if you can succeed in your ideas, and I wish you good luck. However, I am suspicious about a couple of issues in your proposal. About your use of migration, and about building a new microkernel in general. I've been following migration mechanism for half a decade, even doing some work of my own. In general there was not so much interest in using it. Moreover, even the other earlier implementors of well-known migration mechanisms had similar experience. Check experience of V kernel, Sprite, Accent, Mach, Chorus, Emerald (and there are many others). Check also recent feedback to NOW project at Berkeley, as presented at ASPLOS. Although I still believe in the future of migration, even at various levels (coarse, medium and fine grained, depending on applications), what bothered me in your email was the ease with which you suggest heterogenous migration when even in a homogeneous one hasn't succeeded so far. But let me get back on questions. First the academic. > Processor Independent Operating System > ====================================== > Conventional operating systems assume a static compute environment. > An application is tied to the machine it is initially executed on. > There is a need to develop an OS which operates in a distributed, > heterogenous environment. An OS in which applications, during execution, > can be migrated to, or distributed amongst, machines of differing > architectures to affect an optimization of resources. 1) How do you proof that systems/applications can benefit from migration among the same architectures, let alone the different architectures where the costs are going to be much higher. (Krueger is one of the rare who (through simulation) demonstrated benefits of process migration, however, even he changed his mind lately, check his recent publications). What is your system intended to support? General applications, scientific, data base? For each there is a different need, and probably different kind of LD support, some may not need migration at all. In general there is small class of applications that need load distribution. Check Utopia that does most of LD at user-level. 2) Estimates of the costs of migration to the machine of another architecture? They are much higher than among machines of the same architecture. Would this not outweight migration in some cases? Have you made any estimate on this. > A PIOS is application-centric, breaking the machine-centric model which > has pervaded OS design for decades. Applications are viewed as resources > and are named. The name is not tied to any specific machine. > A resource is a grouping of code and data, and agents which act on that > data. A resource is not bound to any processor and may be migrated to > any other processor. Agents execute code within resources, and can travel > between resources with data. > A PIOS will rely on an intermediate language, below programming, but general > enough to compile on a wide number of machines. The language will > compile down to binary just before run time, or after a resource is migrated > to a new processor. 3) What are the costs of doing this? Which applications are envisioned? What is predicted execution time of applications, and how many can be running at a site which could be a reason for migration of some of them? Commercial questions: > The initial goal of the project will be to design a small microkernel > (10-20K), the intermediate language, and a small toolkit of > resources for developing and testing. I would like to implement the design > on at least a 486/Pentium and a PPC. In order to encourage people to > experiment with PIOS, the microkernel would also be packaged as an application > and run on top of existing OS's. Then, when conditions warranted, the > true microkernel version could be used. 1) Time and man power for doing this? Chorus, Mach, Spring, QNX, all of them required quite a significant time/man_power. Would you not be duplicating their effort? If you want completely free code, why not starting with Linux, Lite, VST, ... not to mention many other academic systems. 2) Have you checked ANDF project at OSF that already provides some of the needs for intermediate format? > Here are some of my perceived advantages to PIOS; > Forward and backward compatibility of software > High level of sharing resources amongst applications, true > code reusability > Absolute code portability > Efficient use of disparate and dynamic hardware resources > Elimination of backward compatibility hinderence to > new processor development > Parallel processing in a heterogenous environment 3) For which applications. > Ability to upgrade PC's by simply adding boards with (arrays of) > CPU's, reduction of high cost of upgrading systems > Make networking transparent to applications > Simple data sharing between applications on different platforms > The birth of organic computing (more about this later...) > I have spent the last several years working out how this would work, now > I just need the resources to bring this project to life. > I am looking for individuals who are willing to contribute time in exchange > for eventual salary and compensation (and the personal satisfaction of > contributing). > I am looking for businesses who are willing to contribute resources > (equipment, people, capital, office space, etc) in exchange for early access > to the developing technologies. > I believe that a PIOS microkernel could provide a foundation upon which > all computing could be run, from handhelds and set-top boxes to > parallel supercomputers. > If you are interested, please email me. I would like to begin discussions > with interested parties during October, with development commencing > in November. General comment. In the today's world with Microsoft on the one side and the rest of companies offering various versions of operating systems and a number of microkernels, yet another one doesn't seem probable to succeed. Don't forget that the same idea came from DARPA, using Mach on all platforms, and it does run on different architectures, but you should be aware how much effort is put into it by many companies, including OSF. I wish you a good luck anyway. I hope I wasn't much negative this time. First time I was surprised by the amount of your optimism. Dejan, (speaking for myself). From kyle@putput.cs.wwu.edu Mon, 31 Oct 1994 17:35:50 +0800 Date: Mon, 31 Oct 1994 17:35:50 +0800 From: Kyle Hayes kyle@putput.cs.wwu.edu Subject: LLL: definition of terms The following is the LaTeX source for the glossary in my final project report. Some of it might not be that useful but there is a lot that could be reused. Some of it is specific to my project and should probably be dropped. I thought I would send this to the list in general instead of directly to Mike Prince in order to stimulate a little discussion. Best, Kyle --------------cut here-------------- \chapter{Definition of Terms} This section contains the definitions of special terms used in this document. These definitions should not be regarded as formal. \newcommand{\gEntry}[2]{\parbox[t]{1.1in}{\bf #1}\ \ \ \parbox[t]{4.5in}{#2}} \gEntry{Allocation}{The decision of which resource(s) that is to be used to perform a specific task. Allocation may be done statically (pre run-time) or during run-time. In these cases load balancing and other relevant trade-offs are also done prior to or during run-time respectively. Run-time allocation may also be termed global dynamic scheduling.} \\ \gEntry{Asynchronous\\Execution}{With asynchronous execution the distance between related sampling instants can not be guaranteed (i.e. may drift) and depends on the characteristics of the local clocks.}\\ \gEntry{Atomic\\Operations}{Atomic means non dividable, and refers to an operation that is either performed successfully or not performed at all. One example is atomic broadcast, which thus is either successfully performed to all working nodes or not performed at all. This type of updating may be required, for instance, when a distributed system is to change mode of operation. }\\ \gEntry{Availability}{A measure of the probability that a system is operational (functional) over a given interval. For most systems, the availability is simply the percentage of time the system is operational. For safety-critical real-time systems, availability is a relatively irrelevant measure.}\\ \gEntry{Benign\\Failure}{A malfunction that does not affect the correct functioning of the system. The system will continue to generate correct results at the correct times. If viewed as a black box, a system that has undergone a benign failure will appear no different than an otherwise identical system that has not suffered such a failure.}\\ \gEntry{Blocking\\Mechanism}{A mechanism for temporarily halting the execution of a process or processes that seek to enter code or access data the access of which must be limited. When the allowable number of accesses is already used, a process wishing to access such protected code or data must wait until some (or all) of the resource is freed. The blocking mechanism enforces this wait.}\\ \gEntry{Consistency}{Consistency can be defined to mean "the same and the correct view of the system state". The state of a distributed system can be represented by the collection of distributed states. Consistency can be subdivided into Event Ordering, External Consistency, Internal Consistency and Mutual Consistency.} \\ \gEntry{Control\\Delay}{The control delay refers the to time between related sampling and actuation actions. Note that it corresponds to the computational delay for a single rate control system. For a multirate system the control delay also depends on the different rates, processing and communication delays, see end-to-end delay. For feedback control it is highly desirable that control delays are constant. } \\ \gEntry{Data\\Delay}{The data delay is the time between when a data-item is created, either by sampling or by a computation, and when it is available to control components in other nodes. The data delay thus includes the end-to-end delay.} \\ \gEntry{Data\\Age}{The age of a data-item is defined as the time between the sampling instant when the data-item is created, either by sampling or by a computation, and the sampling instant when another component starts processing the data item, or should have unless sample rejection has occurred. The data-age thus reflects the age of data as it is about to be used.} \\ \gEntry{DCO}{[from Christer's thesis] A Data communication Object (DCO) is an object that is used when two or more nodes in the system are communicating. The class that describes the DCO is defined as a subclass to PEO and therefore DCO's can also be scheduled. The DCO performs all application- visible services for data transport across nodes.} \\ \gEntry{Dependability}{The trustworthiness of the service delivered by a system such that reliance can justifiably be placed on this service. Thus, dependability encompasses the more stringently defined measures reliability, safety and availability (and security, which has to do with protection against intentional attacks on a system).} \\ \gEntry{Dynamic\\Scheduling}{Scheduling that takes place at run-time, as opposed to Static Scheduling which takes place before run-time.} \\ \gEntry{End-to-end\\Delay}{This delay is the time interval counted from the instant when a process delivers a data item to the communication subsystem/operating system, to the instant when the data item is available for use by the receiver/receiving processes. The end-to-end delays in general depend on the following four parameters: Synchronism between processes; Communication delays; Processing time; and Run-time system overhead.} \\ \gEntry{Error}{The manifestation of a fault in a system. Part of a system state which is liable to lead to a failure.} \\ \gEntry{Event}{The occurrence of a specific system state. Its validity is time and system state based.} \\ \gEntry{Event\\Controlled\\Updating}{The communication principle in which data is updated from producer to consumer(s) only when the data has changed, here referred to as a data update event.} \\ \gEntry{Event\\Ordering}{describes consistency in event ordering, as observed by several processes. Events in other nodes are only observable at the times when communication takes place. See Consistency.}\\ \gEntry{External\\Consistency}{This concerns data age, i.e. whether the data item is consistent or not with the real-world item that is represents. }\\ \gEntry{Fail-safe\\System}{A system whose failures are only, or to an acceptable extent, benign failures.} \\ \gEntry{Fail-silent\\System}{A system whose failures are only, or to an acceptable extent, omission failures. Depending on the nature of the system interface considered, "omission" can mean different things. } \\ \gEntry{Failure}{Deviation of the service delivered by a system from the specified service.} \\ \gEntry{Fault}{Error cause which is intended to be avoided or tolerated.} \\ \gEntry{Fault\\Tolerance}{Methods and techniques aimed at producing a system which delivers a correct service in spite of faults. In other words, faults are prevented from causing failures.} \\ \gEntry{Global}{In a distributed system, all attributes related to the system as a whole (as opposed to the individual modules) are termed "global".} \\ \gEntry{Hardware\\Dependence}{Expresses in what way the application can be ported to other hardware without redesigning it.} \\ \gEntry{Internal\\Consistency}{describes semantic couplings between data objects. See Consistency.} \\ \gEntry{Jitter}{Jitter refers to time variations in actual start times of a process, as opposed to the stipulated release time. It is very important for sensor and actuation components that a maximum allowed jitter is guaranteed. In the periodic process model the allowed jitter can be indirectly specified by using the release time and the deadline. Jitter depends on clock accuracy, scheduling algorithms and computer architecture. Input and output jitter can be used to relate to the jitter of sampling and actuation processes respectively.} \\ \gEntry{Latency}{Time expressing how long it takes for data to move over the network.} \\ \gEntry{Link}{The communication hardware of a transputer. Specifically, the hardware connecting one transputer to the other allowing the transmission of data bidirectionally. Each transputer has a link that connects to the link of another transputer forming a point-to-point network connection.} \\ \gEntry{Local}{Refers to something to be done on a specific node, in general not interfering with the activities on other nodes (as opposed to global).} \\ \gEntry{Location\\Transparency}{This feature states that the user is not required to know the location of an object that it addresses. It can treat remote objects in the same way as local objects.} \\ \gEntry{Membership\\Agreement}{The agreement by each member of a group that all other members are members. Each member of the groups recognizes the same set of things as belonging to the group.} \\ \gEntry{Mode\\Change}{Change in the overall behavior of the program(part), see Schedule Change.} \\ \gEntry{Mutual\\Consistency}{consistency between copies of data used by several processes. Atomic update is related to mutual consistency. See Consistency.} \\ \gEntry{Node}{A cluster of one or more processors that operate with a shared memory space.} \\ \gEntry{ORG}{[from Christer's thesis] The Object Relation Graph (ORG) defines the associations between the objects that "perform the computation" of a use case.} \\ \gEntry{Object\\Mobility}{Term expressing what objects are supported to be moved over the network.} \\ \gEntry{OOTI}{Ontwerpers Opleiding Technische Informatica. 2 year course followed by the two graduate students from Eindhoven at the TUE.} \\ \gEntry{PEO}{[from Christer's thesis] A Parallel Executable Object (PEO) is an object that can be scheduled, i.e., an object that is visible in the precedence graphs.} \\ \gEntry{Periodic\\Process\\Model}{Parameterized by {S, R, C, D, T} where: \begin{itemize} \item S is the starting time for periodic execution. S can be used to specify synchronous execution. \item R is the release time which specifies the earliest allowed start time of the process each period. R can be used with D to specify low jitter on actuation. \item C is the execution time of the process each period, and may refer to the maximum execution time. \item D and T are the deadline and period of the process respectively. \end{itemize} } \\ \gEntry{Periodic\\Updating}{The communication principle in which data is periodically communicated from producer to receiver(s), regardless of whether data has changed or not.} \\ \gEntry{Permanent\\Fault}{A fault which, having once occurred, requires manual intervention (such as the replacement of a component) to make it disappear.} \\ \gEntry{Precedence\\Graph}{[from Christer's thesis] A precedence graph is a directed acyclic graph which defines the execution order between the parallel objects. The precedence graph not only defines the causal order, but also the temporal characteristics of the computation (i.e., the periodicity, release times and deadlines).} \\ \gEntry{Preemption}{temporarily stopping an action (before it has completed) to switch to another activity.} \\ \gEntry{Recovery}{The process of resuming normal operation following the occurrence of a fault.} \\ \gEntry{Reliability}{A measure of the probability that a system will not fail in a time interval of a specified length, given that the system was fault-free at the start of the interval.} \\ \gEntry{Replication}{Technique of copying data to different nodes. This technique is often used to achieve lower communication intensity, for instance when data is read more frequently than it is written.} \\ \gEntry{Sample\\Rejection}{Sample rejection refers to the case where more than one sample is obtained by a control component in between two consecutive executions of the component. The reason is typically that the sampling and control component are not synchronized and that the end-to-end delays are time-varying. Sample rejection may then occur more or less frequently. } \\ \gEntry{Scheduling}{Scheduling is concerned with the determination of when actions are to take place according to a specific scheduling policy. When one resource is shared by a number of activities the scheduler must determine how the sharing (multiplexing) is to be done. The policy specifies the aim of (e.g. meet deadlines or high average throughput) and rules for scheduling. For implementation of the policy a number of low level mechanisms may be needed. Further characteristics of scheduling policies/algorithms include when the scheduling is done, during run-time (dynamic) or pre run-time (static), where scheduling decisions are taken and whether only local or global actions are considered. Thus, for example, in global static scheduling, the actual scheduling takes place pre run-time and all relevant system resources are considered. The actual algorithms may be centralized or decentralized. A scheduling policy is only valid for one or more specific process models.} \\ \gEntry{Site}{A synonym for Node. See Node.} \\ \gEntry{Skew}{Skew is used to denote the distance in time between sampling instants or period starts belonging to different control loops which are part of a multirate control system. In synchronous execution the skew is zero or a non zero constant. It is also useful to define a skew in asynchronous execution. The skew is then a time-varying function. To describe synchronism in a multirate system the comparison can be made each major period.} \\ \gEntry{Static\\Scheduling (local/global)}{Static Scheduling takes place before the application is run. In case of global static scheduling, all scheduling is done before run-time. In case of local static scheduling, communication between the nodes will be scheduled during run-time. Remark: static scheduling does not mean that there can be no schedule change invoked during run-time.} \\ \gEntry{Synchronization}{Synchronous means simultaneous. A synchronization mechanism can therefore be interpreted as a mechanism which ensures that events occur simultaneously according to a common time base. This is contrasted with the use of the word in classical (non real-time) distributed systems where synchronism refers to logical event-ordering. e.g. exemplified by mutual exclusion, logical clocks, rotating privileges, etc. Synchronization is based on message exchange and/or a global clock.} \\ \gEntry{Synchronous\\Execution}{A number of periodic processes execute synchronously if the distance in time between related sampling instants always is smaller than a known synchronization accuracy constant. The constant distance between related sampling instants is called skew.} \\ \gEntry{Time\\Consistency}{See External Consistency.} \\ \gEntry{Time\\Deterministic}{A system quality which, to a specified extent, guarantees that certain timing requirements are always met. In a fully time-deterministic system, it is thus known in advance precisely what the system will do at any point in time. A non-trivial system can never be fully time-deterministic, but time-determinism is nevertheless a useful concept.} \\ \gEntry{Transient\\Fault}{A fault which has, or can be made to have, a limited duration. Examples are bit flips in memory and in communication media.} \\ \gEntry{Use\\Case}{[from Christer's thesis] A use case is the collection of computational steps which take place between a stimulus from the environment and a response given to the environment. The use case concept is used both in the analysis phase, where only the computation is defined with corresponding temporal requirements, and in the design phase. In the design phase the use case is defined by: \begin{itemize} \item its period time \item a precedence graph \item an object relation graph. \end{itemize}} \\ \gEntry{Vacant\\Sampling}{Vacant sampling refers to the case where no sample is obtained by a control component in between two consecutive executions of the component. The reason is typically that the sampling and control component are not synchronized and that end-to-end delays are time-varying. This means that vacant sampling may occur more or less frequently. } \\ From kyle@putput.cs.wwu.edu Mon, 31 Oct 1994 20:38:26 +0800 Date: Mon, 31 Oct 1994 20:38:26 +0800 From: Kyle Hayes kyle@putput.cs.wwu.edu Subject: LLL: choices (long) It seems like there is a bit of a difference of opinion on what is really being discussed with these things. This is only addressing low level issues. The following is a list of the kinds of questions I have seen asked, or wonder about myself. After this list, I have my own opinions on each issue (of course :-). - VM -- What should it do? At what level should the VM code be? Is one needed? Should it be RISC-like, stack based, something else? - garbage collection -- Is it needed? If so, how can it be done in a distributed system while maintaining an appropriate level of system integrity/consistency? What kind of GC should be used? Should it be global? - message passing -- Who sends messages? How are they queued (if they are at all)? What _is_ a message send, a procedure call, or something more flexible? What is a message? - hardware -- How should hardware be supported? What should a driver in TUNES look like? How are interrupts handled? How is a task switch started? What about paging, memory protection, disk access etc. on heterogeneous platforms? - security -- Where should things be checked? What level is the most useful? Where is the line between performance degradation and security? - persistance -- How much should be persistent? How should it be done? Should a persistent object store replace the traditional file system? If so, how can objects be saved onto tape or diskette for backup? More importantly, how do you spell it? Note that persistance + distribution + garbage collection becomes very complex. The interactions of these things can be very subtle. - distribution -- A workstation on a network is part of a distributed system. I think it is very important to decide what kinds of things and at what level things will be distributed. Should it be at the level of individual objects such that an object reference might refer to a local or a remote object? Should it be such that all object references are local and special interface objects actually handle the network connection to remote spaces? There are lots of possibilities. What I mention here is just one end of a spectrum of referential transparency. - parallelism -- At what level should parallelism be supported? Should it be at level of individual message sends as in Jecel's version of Self? Should it be the opposite extreme and be at a process level like Unix? Should the available processors be viewed as a pools of executors for threads or should parallelism be handled on a processor by processor basis? - consistency -- Is it necessary that the state of the system be precisely duplicated in the permanent store? If not, what kind of tolerance can be allowed. Enforcing/assuring data consistency can bring in all kinds of issues like blocking/waiting, access control, timeliness, data duplication, caching behavior etc. What kind of consistency should be addressed by the system? Data consistency, temporal consistency? To help assure that everyone is thinking the same things I do when I use the above terms, I have just sent the glossary from my final project report to the list. I see that it has just shown up in my mail box, so I will assume that everyone got it. After introducing the above issues, it seems appropriate to give my ideas about solutions/decisions regarding them. - VM -- something quite RISC-like. I think that the bandwidth constraints are less important than the ability to support multiple languages easily and efficiently. I wouldn't put the VM in the kernel. I think that superscalar processors will continue to have an advantage over VLIW processors because they dynamically schedule execution. You can apply all the tricks of VLIW compilation to a superscalar processor compiler, but you will also gain this dynamic aspect. My money is on superscalar and thus I have no problem with a simple RISC-like VM. There are several tradeoffs here. If a RISC-like or generic stack-based VM are chosen, then we have the possibility of using any one of a number of high level languages to describe programs for low level code. However, transfering such a program over a net will require a similar bandwidth to transfering a native binary. If a high-level VM is used (e.g. like that of Smalltalk), then the binaries get a lot smaller, but the VM is larger and more complex, the process of locally compiling VM code into local machine code is longer and the VM will not support all HLLs equally well. One could write a C compiler for the Smalltalk VM, but it would not be very efficient. - garbage collection -- I think this is absolutely necessary and should be implemented locally as part of a runtime, but not as part of the kernel. There is a nice collection of papers at the University of Texas at Austin by Paul Wilson. He also wrote a very nice overview of single processor collection methods that is available for FTP there. I am trying to track down a copy of a work by some people at the Queen Mary College in London that is a survey of distributed GC techniques. Francois-Rene may actually have better luck with this. One of the authors is Elliot Miranda and the last I knew, he was at the IRCAM in Paris doing LISP programming. Note that the persistent object store must be collected as well and that this may involve distributed information. - message passing -- should be directly supported in the kernel a la QNX. Distributed messaging should be handled as in QNX as well, let something else deal with it. It should not be in the kernel. I have a Master's thesis about message lookup techniques in dynamic languages that I am going through. It is by Karel Driesen now at UC Santa Barbara. - hardware -- the kernel is going to have to know about interrupts and some form of tasking. However, it is possible to separate the mechanism from the policy on this. QNX and Workplace/OS and Mach do a fair job of allowing different kinds of user-level processes to do task scheduling while the kernel takes care of actually performing the task switches. I think that the Chorus solution of having the kernel be net-aware is going to make the kernel to rigid and too large. Disks can be supported without bloating the kernel too much. DOS machines manage to boot without much in the way of ROM. Nothing more than a minimal level of boot support should be in the kernel Perhaps it is not necessary to support networking at such a low level. QNX gets a bit tricky here by having the kernel capable of noting that a message is not destined for a local task and sending it to a known user-level task that is actually the handler for remote sends. It is a little more complex than this, but not much. Chorus simply includes all this in the kernel. I think that Workplace/OS and Mach 3.0 do the same as Chorus. - security -- I am not too sure about this one. Ideally, individual operations on objects could be controlled, but I think that this would result in a terrible overhead on each message send. Any ideas? If the basic operation in TUNES is a message send, then placing security checks on each one could be prohibitive. Protecting objects individually does not map well to all the currently used MMUs I can think of. Typically, page sizes are 4kB and up. In most systems, a page is the smallest unit of protection available from the hardware. About the idea of allowing any access by an object if it has a direct reference to another object. (I think Francois-Rene said this, but I can't remember.) I don't think this is an effective solution. It is very useful to be able to allow read-only access of some objects. Adding wrapper objects that would intercept all accesses to the wrapped object and only pass through the ones allowed has a hole. Since I can have a direct reference to the wrapper object, I can access and modify it. Thus, I could simply access the instance variable that contained the direct reference to the wrapped object and I would be able to circumvent the protection scheme. Be paranoid. - persistence -- This is highly related to consistency (below). I personally think that this is one of the points that will cause the most contention. If you allow any given object to be persistent, then you don't need to have an explicit filesystem. It would be nice to be able to tell the system which objects are ephemeral/volatile and which need to be saved for later. It is probably easier to develop a system wherein the entire system image includes all objects and is stored on disk. There is a fair body of work along these lines from Smalltalk. A group at the U of Texas (Austin?) has developed the Texas Persistent Store to allow C++ objects to gain persistency as an attribute. While I would rather sell my grandmother for potato chips than do a system the complexity of TUNES in C++, the ideas may be interesting. One of the problems with a distributed persistent system is how to handle remote references. If the system saves an object with a remote reference when I shut it down, what happens when it comes back up? How is that remote reference dealt with? What if the remote system is not up? - distribution -- I think that distribution should go along the lines I described for task switching. It should not be an inherent part of the kernel. It should be implemented by user level objects outside the kernel. Note that complete location transparency requires that very low level routines be able to send messages to local objects as easily as remote ones. I think that QNX's solution of placing a hook into the kernel will be enough support. Keep the kernel small and you will have a chance at debugging it by hand. - parallelism -- This is related to distribution. I think that systems should be able to ignore how many processors there really are. Things like load balancing should be part of high level system software, not the kernel. Parallelism requires that there be some method of maintaining consistency in system structures. See below. - consistency -- This is the hardest point. There are a lot of people doing PhD work on the topic of maintaining consistency in distributed systems. A lot of questions arise like how to maintain a coherent view of the system during shutdown if things are still active. Someone mentioned the physics model of causality with light cones. The problem with a distributed system is that the "speed" of information may change dynamically and from place to place within the system universe due to load and heterogenous networks. Thus, on each node/processor you will have an expanding light/information cone, but there won't necessarily be just one due to an event. If you want a precise control of consistency, the overhead may stop the system from doing anything useful. Rebecca Callison did some very interesting work on consistency in large real-time control systems like air traffic control networks in her PhD thesis at the University of Washington. She should have finished it in June, I think. If Chris Harris could find that stuff it might be worth a look for other people. However, her object model would be terribly restrictive for general systems. Nonetheless, she came up with a very interesting way of handling uncertain data that is applicable to distributed systems. For those interested, the January (February?) BYTE has an overview of QNX, Workplace/OS, Mach and a couple of other microkernel systems. Jecel, which one is it? My memory is failing on this. In short, I would like to see the smallest kernel possible that supports message passing and task switching (but not scheduling). Everything should be built on top of this by adding objects to handle specific duties. Some objects can deal with the network and allow location transparent message passing via the hook I talked about in the kernel. Other objects can do things like handle the persistent object store on disk. This will allow small discrete, self-contained units to be written and tested. Note that the VM should be one of these add-on objects. Someone mentioned software engineering approaches to TUNES. I can't remember who said it, but I think it was today. I agree 100%. Even though the final system might actually use surprisingly little code, an extremely clean, solid specification and design will make the rest go much more smoothly. I have only had the pleasure of working on one project where there was a very clean specification. The resultant design was equally clean and the implementation was so fast it made my head spin. Testing was easy because we had a clear idea of what the system was supposed to do. At the time the constant documentation writing and iterative spec and design processes seemed far too long and hung up on detail. I have seen the error of my ways. Never again will I stray from the path... :-) Best, Kyle From mprince@crl.com Fri, 14 Oct 1994 17:32:29 -0700 (PDT) Date: Fri, 14 Oct 1994 17:32:29 -0700 (PDT) From: Mike Prince mprince@crl.com Subject: PIOS... On Sat, 15 Oct 1994, Francois-Rene Rideau wrote: > Dear Mike, > I'm myself considering writing a real light & powerful (unlike Unix) > OS using (some non-ANSI) dialect of FORTH as a portable low-level language. > My idea of specs for the OS seem to match yours (I'd add persistence as > an important characteristics for the system; also dynamic strong typing and > lazy partial evaluation and garbage collection). They sound the same. I'd interpret persistence as the ability of the system to remain running (i.e. no bugs crashing the system) for long periods of time. I would add to that resilience, the ability to survive the failure of several CPU's which are working on part of an application. I have a different idea about strong dynamic typing. The basic OS should not concern itself about the content of objects. This would make the OS very small, and very versatile. On top of the OS, as part of the applications, ANY level of typing could be used. I want the OS to be able to serve as many camps as possible. This way the OS will be a standard building block others can use to explore different programming languages. In order to steer programmers in the direction of dynamic typing I have contemplated a data encapsulation language to enclose parameters being passed between objects. Objects could use a library of extraction functions to pull parameters. Just an idea though... > If my goal and yours agree, then I'm ready to join you. > Note that there's also the FIRE project whose goal is to build a computer > & OS based on FORTH (mailing list: fire-l@artopro.mlnet.com); but from what I > understand, they don't have much idea about what a multi* OS should be (as > FORTH systems are generally single-user). The gentleman in charge of FIRE e-mailed me today. Their project is too hardware and language specific for me, although I hope to foster a healthy exchange of ideas with them. I hope that your goals are close enough to ours so that we can collaborate. I'll add you to the mailing list and you should receive the first mailing on the 17th. I hope to hear from you soon. Sincerely, Mike From rideau@clipper Sun, 16 Oct 94 21:09:27 MET Date: Sun, 16 Oct 94 21:09:27 MET From: Francois-Rene Rideau rideau@clipper Subject: PIOS... > They sound the same. I'd interpret persistence as the ability of the > system to remain running (i.e. no bugs crashing the system) for long > periods of time. I would add to that resilience, the ability to survive > the failure of several CPU's which are working on part of an application. More than that, I'd say persistence would be being able to survive indefinitely, permanently even beyond power-down (on system that don't have permanent memory, this means that the complete system state must be regularly logged on permanent media (say, hard disk). > I have a different idea about strong dynamic typing. The basic OS > should not concern itself about the content of objects. This would make > the OS very small, and very versatile. On top of the OS, as part of the > applications, ANY level of typing could be used. I want the OS to be > able to serve as many camps as possible. This way the OS will be a standard > building block others can use to explore different programming languages. That's also how I see it. But allowing any kind of object is definitely *NOT* enforcing low-levelness and disabling any kind of typing (as is the case under UNIX where untyped objects are used). To me it means being able to parametrize declared objects by there type, itself parametrized by its the type universe, etc. A very basic (but powerful) system will provide means to implement any type system inside it; it should also allow explicit mapping to a set of low-level constructors. > In order to steer programmers in the direction of dynamic typing I have > contemplated a data encapsulation language to enclose parameters being > passed between objects. Objects could use a library of extraction > functions to pull parameters. Just an idea though... That's about what I mean. Again in no case should an object be called with unproper parameters (or worse even -- parameters that would make a process or the system crash). > The gentleman in charge of FIRE e-mailed me today. Their project is too > hardware and language specific for me, although I hope to foster a > healthy exchange of ideas with them. Well, that's the same for me. > I hope that your goals are close enough to ours so that we can > collaborate. I'll add you to the mailing list and you should receive the > first mailing on the 17th. I hope to hear from you soon. I hope our collaboration will be fruitful. Read you soon (:) , -- , , _ v ~ ^ -- -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . -- MOOSE project member. OSL developper. | | / Dreams about The Universal (Distributed) Database. --- --- // Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE /|\ /|\ // Phone: 033 1 42026735 /|\ /|\ / From mprince@crl.com Mon, 17 Oct 1994 16:16:55 -0700 (PDT) Date: Mon, 17 Oct 1994 16:16:55 -0700 (PDT) From: Mike Prince mprince@crl.com Subject: Processor Independent Operating System (PIOS) Information 10/17/94 By: Mike Prince mprince@crl.com FAX: (415) 948-2172 Processor Independent Operating System (PIOS) Preliminary Information Thank you for showing interest in the PIOS project. The following document will provide direction during this start-up period. I hope after reading this document that you are as excited as I am about the PIOS microkernel. It will provide a foundation for future research into operating systems, and allow for the development of new and exciting computer applications. Contents of this document ========================= 1. How to Participate 2. Battle Cry! 3. Mission Statement 4. Design Ideas 5. Preliminary Architecture 6. Agenda 7. FAQ's 8. Points for Discussion 1. How To Participate ====================== First read this document. None of the ideas set forth are cast in stone. I am versatile, and will do what I can to make sure this idea gets off the ground. If you are interested in the project, but at this time are not able to contribute, e-mail a message stating so, and I will keep you on the mailing list. We would be more than happy to hear your opinions, and exchange ideas with you. If you have decided to join, please read the points for discussion. Then e-mail me your positions on those points and comments. Please also include a brief description of yourself, which I will compile into a contributor profile to be distributed to all. This description should include education, relevant projects, papers, etc, and small section about you personally. Also include the level of participation you would desire and which aspect of the project you interested in (an estimation of the number of hours each week you would like to contribute would be helpful). Last of all, (I hate to have to do this), please list three references, with one being a professional or academic staff member. Please send these by October 23rd. My e-mail address is mprince@crl.com. I also have a fax line at (415) 948-2172, if that is more convenient, or if there is information that is on paper you would like to submit. 2. Battle Cry... How to Win ============================ How do you win the OS war? Do not be subserviant. Create a design that does things the others cannot do, or does what they do, but better, faster, and easier. Layer your operating system ON TOP OF theirs for the mean time. For that matter, layer it on top of everything that is out there. You can not win from the bottom, you must battle from the top! Exploit the fact that your OS can service the growing distributed networking scene better than theirs. Write a killer app. Exploit the fact that your OS can make the computer run faster for less. Plug that card with 8 of the newest processors available into that empty slot in your PC-XT. Watch all the software written for your OS immediately run 100 times faster, while their software doesn't even know whats going on. Tell that to all the Fortune-1000 companies, which every two years has to upgrade their systems. Exploit the fact that your OS is a technological masterpiece. Write a course guide and give the software to every university with a computer. Professors love teaching the newest stuff, just give them the resources. Within three years you will have a force of enthusiastic programmers. Exploit that size of your microkernel, most computers out there are hidden in microwaves and cellular telephones. Compete for the position to connect all of them together. NT and beepers do not mix. Despite pagers abundance, they are ignored. And here come the set-top boxes and ISDN interfaces... Exploit the fact that the market is still fragmented. Your OS, running on top everything, is great glue, but do not get sucked in to supporting backwards technologies. When the time comes, your OS will slide towards the hardware, supplanting everything in its path. Battle from on top of their OS, not from below! You can win with technological merit and marketing genius, you do not need marketing bucks or huge R&D budgets. 3. Mission Statement ===================== We are here to design a microkernel based operating system to serve as the basis for the next generation of higher-level operating systems and consumer electronics. The OS is to be able to optimize the use of computing resources by re-distributing the computional burder of applications, during execution, over a dynamic, heterogenous, wide area network. It should execute on the largest range of platforms possible, from household appliances to supercomputers. The OS will be the common denominator of all systems. No backward compatibility will be designed in, so as to allow the highest degree of design freedom. 4. Design Goals ===================== What follows are some ideas I would like to implement in PIOS. Process Migration in a Dynamic Heterogenous Environment ======================================================= A little secret for now, but it can be done. Application-Centric Paradigm ============================ All commercial OS's are based on the machine-centric paradigm. In this, an application is based on one computer and does communications with other applications on the same machine or others. An application is grounded to the machine it was initially executed on. Due to this prespective software engineers have had a great deal of latitude in typecasting their applications and OS's to one platform, thus reducing their portability. An application-centric OS allows applications, during execution, to be migrated to different machines. Applications engineers can no longer assume certain static attributes of their platforms. The environment becomes a dynamic one. The job of the OS is to allow freedom of the application. Logical Configuration ===================== The largest object is the tool box. A tool box is composed of an array of arbitrarily sized data and code segments and a number of agents. Code segments are viewed as tools. Data segments are viewed as stacks, however data within the stacks can also be accessed directly. Agents are the execution primitives. Agents execute tools, and have access to the global tool box stacks, plus their own private array of local stacks. Agents can move from tool box to tool box carrying their local stacks. Physical Configuration ====================== Physically, a tool box resides within one working space, and is usually serviced by one CPU. Normally a working space contains several tool boxes. Tool Box Migration =============== At the discretion of the OS a tool box may be migrated to another working space. At such time all constituent parts of the tool box (tools and global stacks, resident agents) and bundled up and moved to the new working space. At the new working space the tool box is unbundled and all tools are either re-compiled, or are deemed better interpreted for overall system performance. The intermediate code is retained in case another move is warranted. Resource Management =================== Tool boxes can be viewed as resources. Each tool box is named and all inter-tool box communications are vectored according to that name. Names may be shared by tool boxes, in the case of libraries for which there may be instances in several working spaces. All services provided by tool boxes must, by default, be stateless. Inter and Intra Tool Box Communications ==================================== Agents carry all data in their local stacks. Typically, parameters will be pushed onto a stack before a call, and popped off during the call. The actual parameter passing format is up to the application. Security ======== All communications (agents) are vectored through a gate upon entry to a tool box. The entry code can choose to do minimal checking to optimize for speed, or extensive checking to maximize security. This checking is not a function of the operating system, but instead of individual tool boxes. Intermediate Language ===================== All code is distributed in an intermediate language, below human programming, but high enough to be applied to a wide range of microprocessors. It will be simple to interpret, and quick to compile down to binary for speed intensive applications. It is expected that human-oriented programming languages will be layed on top of this intermediate language. I would like to do an implemention of c(++) for the intermediate language. Though c would not effectively utilize the attributes of the OS, it would satisfy the short term complaints of those still bound to c. Automatic Stack Contraction/Expansion ======================================= I'm not sure about this one yet. Each stack (tool box or agent) grows from the bottom, and is used like a stack. It has a profile ( max size, grow/shrink increment, and stack pointer). Data can be pushed/ popped from the stack, or accessed arbitrarily inside the range below the SP. When the stack overflows, the segment is automatically expanded. When memory resources in the workspace run low, garbage collection can commence by contracting stacks that are under utilized (stack top - SP > shrink increment). I believe this might save space by applications using only what they need, and by bundling the memory allocation code in the kernel which might otherwise have many instances in the application code. What do you think? Specialized Platforms ===================== For truly speed intensive applications, the actual application code (tool box) would be bundled with the PIOS microkernel and coded in the native machine language. The tool box would be tied to the machine to prevent migration, or an additional copy of the tool box (the intermediate language version) could be migrated. Optimization of Resources ========================= Tool boxes should include a benchmark tool, which could be compiled on a number of different machines to determine which has the best fit of architecture to problem. This benchmarking can take place just before initial execution, or during a re-optimzation of resources during execution. Taking this measure, plus that of available network bandwidth, estimated communications demands, etc, the tool box could be placed in the most optimal workspace. Notice that we are entering into the territory of a priori knowledge of application demands. No File System?! ================ I don't believe in file systems (maybe I'll change my mind). In any case, I'd like for tool boxes to behave like organic systems, going to sleep on persistent computers when not in use, being brought back to the fast non-persistent computers when being utilized. What is a persistent computer? A hard drive with a very dinky CPU could be viewed as a slow slow computer that is persistent, with a very large memory. Using the same algorithm for optimizing the distribution of tool boxes, the less used ones would naturally migrate towards the hard drive based work spaces when not in use. I look forward to the day when all computers have soft power switches; ask the computer to turn off, it moves the tool boxes to persistent storage, and then turns the power supply off. Design Goals Overview ===================== The migration of processes (tool boxes and agents) during run-time in a dynamic heterogenous environment Small minimalistic microkernel (10-20K) Fast Application centric Allow for any level of security, based on applications need Parallel processing intermediate language not for human consumption Organic System "HDD as slow persistant computer" storage (instead of file based) No file system?! development as an interactive process (FORTH like) Implement initial design on top of existing OS's. (distributed file system as improvised network? Or jump straight in and do a TCP/IP implementation?) All original coding!! No copies of others work (for legal reasons) 5. Preliminary Architecture ============================ Microkernel (10-20K) Processor (application, when run on top of an OS) initialization MMU functions Creation, Bundling and Unbundling for transport, Destruction of Agents Tool boxes Interpreter (in kernel for speed) Compiler (in kernel for security?) Automatic segment expansion/contraction? Workspace tool box mapping/redirection Tool Boxes Inter-microkernel packet communications manager Tool box re-allocation algorithms Device drivers (HDD,TCP/IP) General applications High level to intermediate code compiler (gcc?) Development tools GUI Global tool box mapping/redirection Nearby workspace utilization, access speed, etc statistics Intermediate code to binary compiler (as resource for versatility?) 6. Agenda ========== Determine preliminary goals of project Determine structure of organization Determine participants and roles Determine development schedule Finalize PIOS goals Agree on methods to attain PIOS goals PIOS specifications Coding Beta testing End of phase I Creation and distribution of academic materials (specifications, development tools, sample code, etc...) Second recruiting of strategic partners Development of commercial products 7. FAQ's ========= Q: What will be the functionality of the microkernel? A: The microkernel will be a minimalist one, see part 5. Q: How do you migrate processes in a heterogenous environment? A: Thats a little secret for now. Q: What type of implementation are you looking at? You mention an intermediate language but what? Have you considered using object oriented technology? A: See part 4 for implementation. The intermediate language would be a proprietary one. Object oriented technology in programming languages, for the most part, is for programmers, not for computers (I know I'll get hell for saying that). This OS is for computers. (More inflammatory remarks expected...). Object oriented technology, as far as viewing system components as objects which can talk to each other, is what we are trying to accomplish, without relying on OO programming principles. Q: How about the big guys? You can create an absolutely great OS but if you can't get their software to run on it then you won't sell it. A: See our battle cry at the beginning... Q: Have you looked at TAOS? A: TAOS uses VPcode as an intermediate code. VPcode is tied to a virtual RISC processor, that for now is easy to compile down to the target machines. In the future machines will not match VPcode as well (larger register sets, larger word sizes, etc). Once VPcode is compiled down to a target machine, that code cannot migrate during execution. That is one of the goals of our project. 8. Points for Discussion ========================= What are our exact goals? (See goals section.) What shall be the organization of our group? I opt for a for-profit business even though we do not have funding as of yet. If all our work just benefits the research community then great. But if there could be buck to be made for all of us in the end, then even better. I'll be pushing for equity distributions during two phases of the project. These distributions will be based on the number of hours put into the project, capital invested, or equipment donated. A $/hour rate for programming (which likely will be inflated to compensate for the risk) will be arrived at. Equipment will be valued at the street price. Everything else we will vote for and agree upon before accepting. The distributions would be 30% first round distributions/30% second round distributions/ 40% myself. The first round distributions would primarily be for those who donated programming time and any equipment donations we might get. The second round distributions would be to generate capital to fund further development. What will be the structure of our organization? Benevolent dictatorship, republic, or just where in between? Who will provide direction? Who will represent us? How should we resolve differences? Etc. What kind of participants do we need? Where do you fit in? What would you like to do? What is a reasonable development schedule? Do we even need one? (See agenda section.) Should we widely disseminate our developing technologies (a la Linux), or should we all sign non-disclosure agreements and keep this a BIG SECRET? Is there a middle ground? Start thinking about terminology. We are going to be breaking some new ground here, and there is an opportunity to coin some new terms. Most importantly though, we need to agree on the usage of current and new terminology so we can communicate.