314 lines
15 KiB
Plaintext
314 lines
15 KiB
Plaintext
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) *
|
||
|