NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/misc/1006

Text File | 1993-01-06 | 15.3 KB | 327 lines

Xref: sparky comp.os.misc:1006 comp.theory:2803 comp.lang.misc:4088 alt.lang.asm:532
Nntp-Posting-Host: gyda.ifi.uio.no
Newsgroups: comp.os.misc,comp.theory,comp.lang.misc,alt.lang.asm
Path: sparky!uunet!mcsun!sunic!ugle.unit.no!nuug!ifi.uio.no!olag
From: [e-mail] (Ola Fosheim Groestad)
Subject: PROTOLO A FUTURISTIC OBJECT-CODE FORMAT
Message-ID: <[e-mail]>
Keywords: languages,objectcode
Sender: [e-mail] (Ola Fosheim Gr|stad)
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Wed, 6 Jan 1993 17:27:07 GMT
Lines: 312
Originator: [e-mail]



GROESTAD93.1                                    Oslo, 6th of January 1993

        A SKETCH OF AN ARCHITECTURE-INDEPENDENT OBJECT-CODE-FORMAT
                                    by
                            Ola Fosheim Groestad
                              ([e-mail])

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 [e-mail] 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) *

--

* Ola Fosheim Groestad  (A sonic lunatic) *