Newsgroups: comp.os.misc,comp.theory,comp.lang.misc,alt.lang.asm From: olag@ifi.uio.no (Ola Fosheim Groestad) Subject: PROTOLO A FUTURISTIC OBJECT-CODE FORMAT Message-ID: <1993Jan6.172707.14435@ifi.uio.no> Keywords: languages,objectcode Organization: Dept. of Informatics, University of Oslo, Norway Date: Wed, 6 Jan 1993 17:27:07 GMT Lines: 312 GROESTAD93.1 Oslo, 6th of January 1993 A SKETCH OF AN ARCHITECTURE-INDEPENDENT OBJECT-CODE-FORMAT by Ola Fosheim Groestad (olag@ifi.uio.no) You may use any information found in this document for whatever you want, but if you do you should provide a reference to this document and it should be refered to as "GROESTAD93.1". This is to ensure that all references to it are consistent. PREFACE ------- The trend in computer science is open systems. This is reflected in the major computer languages and operating systems as well as the major graphical user-interfaces. The only major part of a computer where there still is no sign of a common structure is the processor design and thus also in the binary object-code-formats. This must indeed change in the future. Since I don't believe in an unified processor-structure, I have worked out a sketch for an object-code-format that should be architecture independent, but still cater for special abilities in any given system. I've called this sketch PROTOLO. I must emphasize that I have neither studied compiler- or language- theory, nor read anything about a similar project, so if you find elements in this document that is embedded in existing systems or planned in future systems it is purely coincidental. **************************************************************************** BACKGROUND (or FUTURISTIC COMPUTER ENVIRONMENTS): **************************************************************************** The following section is a description of what I think the user-interface of the future will be like. Some parts relate to PROTOLO and some do not. USER-INTERFACE OF THE FUTURE ---------------------------- The computer displays will be extremely thin (LCD?). They will be touch- sensitive and be able to change the contour of the screen surface by up to 5 mm (Which will aid visually impaired users). New technology will open new possibilities for special user-groups. Architects and designers will probably want a big screen shaped as a design table, where they can move virtual sheets of paper, draw with pencils etc. The screen will also be able to show 3-d and it will contain thousands of small speakers, which enables localization of special events by sound. Localization by shaking is achieved by changing the contour rapidly. Keyboards will be superfluous for most users, except for writers and journalists (the qwerty standard will not be easy to replace though, unless one develops a system that is substantially easier to use). Microphones/speech recognition and natural speech synthesis will be considered normal, but not used much for issuing commands to the computer. It will however be invaluable for tutorials and help functions. In addition to this, the user will be wearing small sensors on each wrist and maybe on the head to help the computer guessing what the user's focus is. Virtual reality will probably not become important in general purpose user-interfaces in the near future. (It will be (is?) invaluable for doctors, space- and ocean-research though). The current trend using windows (or sheets) will continue, but the new display-technology will make them more effective and intuitive than today. As an example: To remove a calculator from the screen, I could grab the calculator-icon lift my hand and throw it away. To move some sheets I just put my hand on the screen and drag them to another place. THE FILE-SYSTEM -------------- The hierarchical file-system is coming to an end, it will be replaced by an advanced and flexible object-oriented database which enables the user and applications to interconnect objects by relations and bind descriptive information to objects. e.g.: I store a picture of myself, I want a relationship between this picture and other pictures, especially to those of myself. I want a relationship to myself, the place where it was taken, when and the person that shot it as well. To make an effective implementation it is immensely important that the system knows which roles and what information that usually pertains to a given object-type. If not, the user will have to figure out what information could be useful to store about each object, and will probably not bother or be able to store the relevant information necessary to make the system useful and powerful. Some common roles/information types are: describes, owned by, time, period of time, made by, physical, abstract, part of.. The advantages of an object-oriented file-system should be obvious. It is not possible to group files hierarchically in an effective way without duplicating information and making searches difficult. **************************************************************************** A SKETCH OF A NEW OBJECT-CODE FORMAT CALLED PROTOLO **************************************************************************** PROTOLO THE OBJECT-CODE FORMAT OF THE FUTURE -------------------------------------------- Today, we have many programming languages that enables us to write programs that will compile and run on machines with totally different architectures. The problem is however that the programs often need to be tuned/fixed to compile on a new machine, which requires some knowledge in computer-science, and the compiling is slow if the compiler is to make effective object-code. In my opinion, the only sensible thing, for those who develops software for the open systems of the future, is to agree upon a general object-code format where the program is compiled only half-way (p-code?), in other words a format where expressions are optimized/unrolled, parenthesis are evaluated, statements broken down to their atomic parts etc, but the statements is NOT converted to a specific machine-language. I've decided to call this format PROTOLO which is a short for PROTOtyping Language Object-code. This object-code is in essence source-code, but not readable for humans to enhance compilation performance. Since PROTOLO is not optimized for a specific processor it should contain information that makes optimizing, faster, easier, and the resulting code more effective and appropriate. This means that PROTOLO will have to impose certain restriction on the programming languages that can produce true PROTOLO, the most obvious is strong typing and function- definitions. I believe that even in the future developers will want to write certain sections of a program in pure machine language, this should also be possible in PROTOLO, but the developer should also include alternative PROTOLO-code that performs the same task if possible. A machine language section should always include a descriptive header defined by the processor-manufacturer. This header should include information about the use of registers, how parameters is transferred, which external variables that are read, written or both. This ensures that machines with the same processor will be able to run the same programs at maximum speed. Even if open systems are the sign of the future, I guess manufacturers still will make system specific features that software developers want to use. PROTOLO should also support this (but not encourage) by allowing system- specific headers. This header should always contain information about whether the following code is necessary for the program to compile or if it could be omitted or replaced by more general code. The best way to implement this is by setting up a set of rules (dependencies) that determines whether compilation is possible on a specific machine or not. This could include information about special capabilities like graphics, sound, special bus-layout. But it must ONLY contain information that is specific to ONE manufacturer, e.g.: If a program requires a screen-resolution of 1024x1024 this should be specified in the standard PROTOLO headers. PROTOLO-programs are distributed in this general format made by 3-different groups: The PROTOLO-consortium, processor-manufacturers and system-manufacturers. In addition to the general PROTOLO-format the consortium also establishes a certain set of functions to perform standard operations (file-handling, user-interface etc). This set will of course be expanded as the systems evolve, and this should be done in a fashion that enables older systems to emulate the new functions with the old set, even if it means very slow code. In other words, at least within a minor revision of PROTOLO, it should remain downwards as well as upwards compatible. This ensures that older system may run new programs and new system will be able to run old programs (makes hardware-upgrades more attractive to the users as they can use their old programs). Summary; Programs will be distributed halfway compiled and must be compiled (or interpreted?) and installed on every specific machine before they can run. This makes upgrading to another brand easier as you still may run your old programs. It also makes program development and distribution more cost efficient. PROTOLO puts some constraints on both programming languages and operating systems, which in my opinion is a plus. One could of course allow variable "strength" of the variable-typing and thereby make certain tricks possible, but this would make good optimizing more difficult (or impossible). PROFILING INFORMATION AND OPTIMIZATION IN PROTOLO ------------------------------------------------- To enhance reasonable optimizing PROTOLO programs can include profiling information that tells the PROTOLO compiler the priority and maximum execution time for different parts of the program, how often a part is likely to execute, which values are typical for a particular variable etc. This should ensure that the compiler doesn't optimize one section at another more vital section's expense. Profiling information may also be added based on the user's typical use of the program. The user should be able to tell a runtime "profiling-daemon" when program execution is too slow. To enhance compilation time one might want to include profiling information about the possible domain of a variable. For instance, after abs(x), x will certainly be a positive value. This domain-profiler should however always be the one provided by the consortium so the PROTOLO- compilers could decide whether to ignore the existing information or not based on the revision number. A bug in the domain-profiling info will often be fatal! Additional profiling information could be statistical data on how often a variable is converted to different format and used in the given format. Maybe execution time would benefit if the variable changed format? To make it possible to use many different languages to write a program a special linkable version of PROTOLO should be established. This would make it possible for developers to use the best suited programming language for a given task including CASE-utilities. REAL-TIME COMPILATION -------------------- Usually the entire PROTOLO program will be compiled to a system specific object-code-format when it is installed, but certain loops with a core of heavy calculations may benefit from real-time compilation (depending on the processor), because one can then treat all variables that are not altered within the loop as constants. PROTOLO EXAMPLE: ---------------- Here is a couple of examples to illustrate how PROTOLO could be implemented. I've used a C-like language as PROTOLO will not be human-readable, but mere opcodes and offsets. (I have inserted "something..." in places where I couldn't figure out the correct value) A program like: int x,i; x = 5; for(i = 1; i<100; i++) { x = (x * i )+i*2; } Could be translated into pseudo-PROTOLO as : word x; #domain x E something...; word i; #domain i E [1..100] x = 5; #domain x E {5} i = 1; #domain i E {1} if (i<100) { This one is of course redundant do { #block repeat-factor 99:1 x = x*i; #domain x E something... alloc word d1; Create a temporary variable d1 = i*2; #domain d1 E [1..99]*2 x = x+d1 #domain x E something... free d1; Free the temporary variable i = i+1; #domain i E [1..100] } while (i<100); All loops in PROTOLO are do-while loops } Notice the loop construct. PROTOLO will only contain the most elementary elements of a programming language. This program should however not be generated as PROTOLO as all variables are known, neither should the if-sentence have been there. It serves well as an example however. The PROTOLO-end-processor should have noticed the unnecessary code and replaced the code above with: i = 100; x = something... Unnecessary code is never allowed in distributed PROTOLO-code since it isn't a programming language but an object-code format with focus on optimizing. The development process of software distributed as PROTOLO-code could be: 1. edit source-files 2. compile language dependent code to PROTOLO-linkable 3. linking with debug-info 4. debugging 5. if there are bugs then repeat from 1 6. link to PROTOLO with profiling generators and existing profiling-info 7. compile PROTOLO to executable 8. run the program 9. repeat from 6 until there is no speed-improvement 10. if the program is too slow repeat from 1 11. link to distributable PROTOLO The linking process consists of at least the following steps: 1. generate domain-profiling-info 2. remove redundant code 3. add priority-profiling-info 4. verify the syntax THE NEXT STEP IN MAKING OF THE PROTOLO-STANDARD: ------------------------------------------------ I cannot (and will not) get PROTOLO on it's feet by myself, but I think it is a valid concept which both developers, manufacturers and users would benefit from if it was available. The future of PROTOLO certainly depends on the goodwill of those groups, but goodwill and intentions alone isn't enough, action is also required. For a start I would like anyone who believes that what I have outlined here is a good idea, but have some comments to it, to send me a notice at olag@ifi.uio.no with "GROESTAD93.1" or "PROTOLO93.1" as subject. If anyone feels like contributing more than a notice I will welcome anyone to participate in the making of the first draft of PROTOLO. I have however no intention of making an implementation of PROTOLO myself as it will only be of any value if the majority of the manufacturers are interested. If we however manage to produce a draft that is likely to be both effective, useful and possible to implement then we would have achieved a lot. -- * Ola Fosheim Groestad (A sonic lunatic) * .