UNCOL traduzione.pdf

01/08/1958
Traduzione de “The problem of programming communication with
changing machines: a proposed solution”
di J. Strong, J. Wegstein, A. Tritter, J. Olsztyn, O. Mock, T. Steel
Pubblicato su Communications of the ACM, Volume 1, Issue 8, 01
Aug. 1958, pp 12–18
Traduzione effettuata da Google Traduttore
Adattamento di Salvatore Giglio

Traduzione de: “The problem of programming communication with changing machines: a proposed solution”

Introduzione
Il documento, che qui ho tradotto e presento, risale al 1958 e fu elaborato dal Comitato di studio ad hoc,
per lo sviluppo di un nuovo Linguaggio di programmazione Universale, fondato in seno ad una delle
associazioni di utenti più potenti degli USA in quel periodo, la SHARE. Questa società era stata istituita
nel 1955 da dirigenti della difesa, da appaltatori di centri informatici, da esponenti di istituzioni di
sicurezza nazionale e di società che utilizzavano principalmente i computer IBM 701. SHARE è
ancor’oggi un influente protagonista nel mondo informatico americano ma, soprattutto negli anni ’50,
’60 e ‘70, incarnava la caratteristica alleanza di quel periodo tra l'industria, il mondo accademico e la
difesa statunitense. La sua ascesa è stata determinata dal ruolo strategico che essa ha avuto nella
promozione dello scambio di informazioni tra i vari centri di calcolo USA, militari e non, grazie al
sostegno attivo del colosso IBM. Tornando al Comitato ad hoc e al nuovo linguaggio di programmazione
universale, l’esigenza era quella di realizzare una piattaforma dialogo tra i numerosi linguaggi dell’epoca
così da permettere uno scambio di informazioni tra computer diversi. SHARE formò il comitato di studio
con rappresentanti provenienti dall’ambito accademico, industriale e militare; si trattava di: J. Strong e
O. Mock della North American Aviation; J. H. Wegstein del National Institute of Standards and
Technology; A. L. Tritter del Lincoln Laboratory; J. Olsztyn della General Motors e T. Steel della
System Development Corporation. Il lettore dedurrà che idealmente la struttura operativa dell’Universal
Computer Oriented Language → UNCOL rappresenta, suo malgrado, una delle matrici storiche
dell’ALGOL anche se quest’ultimo non avrebbe poi soddisfatto le aspettative dell’utenza americana
che, infatti, ad esso avrebbe preferito il FORTRAN. UNCOL fu presentato ai professionisti IT
statunitensi attraverso la prestigiosa rivista di informatica Communications of the ACM che pubblicò
l’articolo suddividendolo in due parti forse per motivi di spazio. In questa sede ho provveduto a
“saldare” le due parti e, avvalendomi di Google Traduttore, ho tradotto e adattato il testo in italiano
corredandolo delle immagini originali attraverso una serie di catture video. Chi ha necessità di consultare
e/o citare il documento, in calce le sue coordinate web:
The problem of programming communication with changing machines: a proposed solution
Autori:
J. Strong, J. Wegstein, A. Tritter, J. Olsztyn, O. Mock, T. Steel
Pubblicato su:
Communications of the ACM, Volume 1, Issue 8, 01 Aug. 1958, pp 12–18
Consultabile e scaricabile gratuitamente sul sito:
ACM Digital Library al link https://dl.acm.org/doi/10.1145/368892.368915#

1. Testo in lingua
originale

THE PROBLEM OF PROGRAMMING COMMUNICATION
WITH CHANGING MACHINES
A PROPOSED SOLUTION
Report of the Share Ad-Hoc Committee on Universal Languages, by
J. STRONG, North American Aviation; J. OLSZTYN, General Motors Corp.;
J. WEGSTEIN, Bureau of Standards; O. MOCK, North American Aviation;
A. TRITTER, Lincoln Laboratory; T. STEEL, Systems Development Corp.
I. BASICS ASSUMPTIONS.
One of the fundamental problems facing the computer profession today is the considerable length of time
required to develop an effective method of communication with the machine. Moreover, it seems that the
ability to communicate easily is no sooner acquired than the language changes, and the problem is renewed,
usually at a higher level of complexity.
A. Obsolescence of Machines. Experience would indicate that there are few machine users who do not
obtain new and different machines every three to five years-a change generally prompted by technical
obsolescence rather than by the decaying ability of the machine. In most cases, the appearance of a
new machine coincides with the necessity to expand computing capacity. Although the programming
cost involved in changing machines is high, the pressure to advance to these new machines has been
sufficiently great to justify their acquisition.
B. Growing Sophistication of Machine Languages. So far, each advance in machine design has been
accompanied by an increased complexity in the structure of its language, making programming in
machine-like language progressively more costly in both dollars and elapsed time.
C. Existing Compilers. Current compilers alleviate the problem somewhat by translating some particular
"easy-to-code" language into a specific machine code. The principal shortcoming in this approach is
the considerable lapse of time between the initial conception of the "easy-to-code" language and its
general acceptance. This time is of the same order of magnitude as the machine replacement cycle,
resulting in the ever-present danger of having a good compiler available for the old machine just after
it has been replaced.
II. APPROACH TO A SOLUTION.
Let us examine a broad set of specifications which might describe a "system" capable of solving this
problem.
A. Ideal Specifications.
1. The individual with a problem would describe its method of solution in the language most natural
to his way of thinking about the problem.
2. Once his problem has been coded in this language, the solution might be obtained by processing
the program with acceptable efficiency on any present or future computer. (Efficiency of operation
in a proposed system is equal to the lowest possible total cost, including programming, divided by
actual total cost.)
3. A minimum of "system programming" should be required to produce the system initially and to
maintain it. Most installations should not be required to do any system programming at all.
B. Practical Specifications. The ideal specifications listed above need some interpretation. In their
ultimate implications, they may be incapable of realization in this century. A few qualifications are in
order.
1. Saying that the man with the problem should speak in the "most natural" language is misleading.
His native tongue, English, is capable of almost infinite shades of meaning. Few people can use
English precisely and unambiguously. Consequently, the most natural method of expression will
have to be compromised in the interest of precision. This is not unusual; almost every scientific
discipline, and most trades and professions, have their own unique, fairly precise language.
2. The ideal of processing every problem in every language on every computer and producing
efficient results can probably be realistically approached without too much compromise by
permitting the following conditions:
- 1 -

a. The coder can achieve higher efficiency if he knows which specific computer his routine will
be processed on.
b. Any routine written for a small computer may be processed on a larger one. However, a
routine written for a larger computer might be capable of execution on only a few small
computers and certainly not on a computer several orders of magnitude smaller. For example,
709 routines would not normally be translated into E101 language since they might run for
many years on the smaller machine.
c. A large computer is available for development of the system. A run on a large computer
would prepare the system for all subsequent use on a small computer.
d. Although the existence of the system may influence computer design, the system should not
be dependent on this factor. Moreover, it would be undesirable if the system should in any
way inhibit the development of more powerful computers by restricting the complexity of
their basic languages.
3. With regard to the time required for system programming, one would hope that some useful
results of the system would be available in from three to five years. The design of the system
should not rely on a major "breakthrough" in programming art. The system, for example, should
not stand or fall upon its ability to develop a routine which is so general that it can transform
every type of language into every other type.
III. FURTHER ASSUMPTIONS.
The proposed solution to the problem will be presented in some detail in paragraph 5 below. Since some of
the assumptions underlying this solution may be considered controversial, a preliminary discussion of them
here may help clarify the final proposal.
A. Languages.
1. It is impossible to agree on one universal POL. Since there are many varieties of problems, any
attempt at universality of problem-oriented languages will result either inadequacy, (such as an
attempt to use algebraic language for a logical problem) or such extensiveness as to become useless.
In the latter case, the "universal" POL is really the sum of all possible POL's and is never truly
universal for long, since the language must grow to cope with the new classes of problems that arise.
2. Machine languages will continue to grow in complexity and will become increasingly difficult to
code in. Everyone looks with dread at the possible computers of the next decade which will be
simultaneously executing multiple asynchronous stored programs. There is little reason to expect a
reversal of this trend.
3. The present status of the compiler art requires a rather difficult generative routine to transform each
POL formulated into each ML desired. Moreover, additional routines must be written whenever it is
necessary to produce a different ML from the one belonging to the machine on which the translation
routine is executed. The; number of individual compilers of the current type needed can only increase
as it becomes desirable for POL’s to multiply, for machines to be replaced, and for one organization
to have several types of machines. The time is fast approaching when the need for these routines will
exceed any possible supply.
B. Programming.
1. At the present state of the programming art, a reasonably efficient routine can be written to transform
any one specific language into any other specific language.
2. The complexities of the language transformed determine the size of the machine needed for an
acceptable degree of efficiency in both the transformation process and the subsequent execution of
the ML routine.
C. Machines. There will be available for the system programmers a machine at least as complex as the
IBM 709 and machine language programming tools at least as versatile as the SHARE 709
programming system.
IV. SOLUTION - THE THREE-LEVEL CONCEPT ("UNCOL").
A. History. This concept is not particularly new or original. It has been discussed by many independent
persons as long ago as 1954. It might not be difficult to prove that "this was well-known to Babbage,"
so no effort has been made to give credit to the originator, if indeed there was a unique originator.
B. Outline. The system is composed of three levels of language, as shown in the schematic diagram,
Appendix B.
- 2 -

1. ML Level. The lowest level (closest to the bits in the machine hardware) is composed of all the
current or future ML's.
2. POL Level. The highest level (furthest from the machine) is composed of all the current and future
POL's.
3. UNCOL Level. The center level is a single language "UNCOL," the Universal Computer Oriented
Language.
4. Generators. Generators are those routines which perform the transformation from the POL's to
UNCOL. They are analogous to present generative compilers except that they produce, not a
number of ML's, but only UNCOL. As with present compilers, one of these would be needed for
each POL used with a given machine.
5. Translators. These are routines which perform the transformation from UNCOL to ML, and are
like present compilers in that they are one-time preprocessors before execution of the customer's
program. However, they are not so complex nor so difficult to write as the "generators" described
above, since UNCOL, being computer oriented, has many things in common with each of the
ML's. For each machine only one translator needs ever be produced, regardless of the number of
POL's formulated or used.
V. CONCLUSIONS.
It might seem that the UNCOL three-level system does nothing but complicate the current method,
whereby compilers enable one to proceed with direct simplicity from a chosen POL to a specific ML.
Such is not the case. The versatility of this system is almost unlimited. Because of its complexity, detailed
discussion of UNCOL has been found to require a special flow chart notation (described in Appendix B).
With the addition of this notation, illustrative examples of how this system might function are presented
in Appendix D. Conclusions are summarized below.
A. Definite Immediate Benefits.
1. As each new machine is produced, all that would be necessary in the way of system
programming is a single translator to convert UNCOL into the new ML. The machine
manufacturer would probably write several successive versions for each of his machines in an
attempt to exploit to the fullest the outstanding features of each machine.
2. As each POL is invented, a system programmer must write a generator to translate his POL
into UNCOL. Thereafter, his POL will never become obsolete. Routines written in it can be
executed on any machine at any time in the future.
3. The UNCOL system will be enabled an installation to use its current programs on any machine
without additional programming cost.
4. The UNCOL system can be designed, programmed and installed within three years. The above
advantages can be achieved without requiring a major breakthrough in programming
techniques.
5. System programmers will probably work most of the time in UNCOL with only occasional
descents to the ML level. A large percent of the customer's problems will be coded in one or
another POL. If, however, no POL is suitable, the problem can be coded in UNCOL directly.
B. Growth Potential.
Although the following potentialities exist, they are independent of the advantages of the UNCOL
system listed above. That UNCOL provides for growth in this direction is an important extra dividend.
1. "Boot-strapping" is a distinct possibility. By boot-strapping is meant the ability to adapt the
system to new POL's, machines (or even new versions of UNCOL) with a minimum of human
programming. That is to say, the system can be to a large extent self-renewing, with the system
routines capable of producing newer and better system routines.
2. Simple "'boot-strapping" will probably be available almost immediately. System programmers
writing in UNCOL can use an existing translator to produce their ML system programs.
3. It is quite possible that within five years programming techniques may permit writing a
"general translator" in UNCOL which, given the characteristics of machine "A", would
produce (on other machines) a translator that would convert from UNCOL into the ML of
machine "'A".
4. The last and least probable step would be the development of the "general generator". This
routine, if given the characteristics of the POL and the machine it was to run on, would produce
the generator to translate the POL into UNCOL.
- 3 -

C. UNCOL Itself.
1. The first step must be the development of UNCOL and its acceptance as a universal standard
by some significant part of the computing profession.
2. Since UNCOL would be computer-oriented, any POL could eventually be expressed in it.
3. The effectiveness of UNCOL will depend upon how easy it will be to translate from it into
each ML, while exploiting at the same time the advantages of the new machine concerned.
4. If the scheme is successful, UNCOL I should have a life expectancy of ten to fifteen years
before any large revision is necessary. UNCOL II could be devised with the "general
generator" in mind. Any transition to UNCOL II could be accomplished everywhere by
bootstrapping techniques. Only one routine need be written.
APPENDIX A
APPENDIX B
UNCOL SYSTEM NOTATION
LANGUAGES refer to the symbols and rules for using them as understood by a human being.
This is independent of the particular vehicle (and its local code) used to carry
them (e.g., punched cards, magnetic tape, etc.).
POL: Any Problem-Oriented Language, e.g., FORTRAN.
ML: Basic Machine Language for any particular machine. If accompanied by
appropriate "input translators", ML can be extended to include "machine-like"
languages unique to a particular machine, e.g., SAP symbolic language for the
704.
UNCOL: UNiversal Computer Oriented Language. This is a standard language oriented
to the requirements of general-purpose digital computers. It must have at least
their characteristics of being able to express any computable problem.
- 4 -

(In the general schematic diagram, Appendix B, and there only, languages are
surrounded by a rectangle ▭).
ROUTINES are sets of instructions arranged in proper sequence. They can exist in any
language, and usually are transformed at least once into another language.
They are designated by capital letters, thus:
P: Problems. Those routines which express the solution to a problem. Normally
these are "customer's jobs" (e.g., payroll, aircraft performance, etc.) and can
most easily be written in a POL.
G: Generators. Those routines which operate on routines existing in a P0L and
perform the transformation from one specific POL to UNCOL.
T: Translators. Those routines which operate on a routine existing in UNCOL
and perform the transformation from UNCOL to one specific ML.
SUPERSCRIPTS The symbol for a routine carries a superscript, indicating the specific language
in which the routine exists, e.g., FORTRAN (meaning that particular POL),
UNCOL (which is unique), or 704 (meaning that particular ML).
SUBSCRIPTS Are used to designate the operation the routine performs. Normally there is no
need to use a subscript with P. However, G and T must have a subscript,
denoting the transformation that the routine performs. For example; the
notation:
denotes a translator which transforms a routine in UNCOL into the same
routine in 704 machine language. The translation routine itself is in 704
language.
MACHINES are denoted by a triangle, thus:
The number, preceded by R, at the apex denotes a specific machine run.
FLOW CHARTS indicate a machine run. All necessary routines and data are shown as input.
The output is also defined. Routines are shown inside the oval symbol: ㇣).
For example, a conventional production run, #872, on an ElectroData 205 is
shown as:
- 5 -

The symbol means "operating on". Therefore, the above chart means:
"A Problem routine in 205 language and its CASE DATA go into the 205
and appropriate RESULTS are produced.”
Generators and translators operate on other routines (usually Problem
routines) and produce the routine in another language as output; for example,
a 704 run #892 might be:
This means: "The Generator in 704 language operates (in the 704) on the
Problem in FORTRAN language and produces a Problem routine in UNCOL
language as output."
NOTE several rules which are useful:
a) The routine which is being executed must have a superscript the same
as the machine being used for the run.
b) The routine being operated upon must have a superscript the same as
the first half of the subscript of the G or T which is being executed.
c) Output is the routine that was operated upon with its superscript the
same as the last half of the subscript of the G or T which is being
executed.
- 6 -

APPENDIX C
USE OF THE UNCOL SYSTEM
The three cases described below illustrate the techniques used:
I. To initiate a new POL in the UNCOL system.
II. To convert from one machine to another.
III. To revise the UNCOL language (if required).
It is assumed that the customer organization has available:
1. A report describing UNCOL, which has been agreed upon as standard by a significant proportion of
the computing profession.
2. A machine and its associated language programming system. For this example, let us assume a 704
and SAP.
3. A translator, previously written and tested (on the 704) which translates from UNCOL into (704) ML.
CASE I: Introduction of a new POL
The POL under discussion could be a previously existing one which is new to the customer organization, or a
newly formulated one being used for the first time. For this example, let us assume that the POL is a newly
formulated one called OMNITRAN. To implement OMNITRAN, the customer organization must have
available:
1. A report describing OMNITRAN.
2. A "generator” in UNCOL language (presumably written by the formulator of OMNITRAN) which
translates OMNITRAN into UNCOL.
If the 704 was used to check out this generator, a second generator in 704 language has already been produced
to translate OMNITRAN into UNCOL. This generator could also be made available to the customer
organization, eliminating the need for Machine Run # 1, below. Machine Run # 1 is required to produce an
OMNITRAN generator in 704 ML from the OMNITRAN generator supplied in UNCOL.
The customer's problems are written in OMNITRAN;
- 7 -

therefore, machine runs 2 and 3 must be accomplished once for each new program written. These runs are
analogous to the compiling run on a current compiler. Runs 2 and 3 may be combined if there is no necessity
to preserve the problem routines in their UNCOL statement.
Run #4 becomes the production run of the customer's~ routine. If a "modify and execute" technique is required,
changes can be written in OMNITRAN and runs 2, 3, and 4 can be combined into a single machine run.
CASE II: Conversion to a new machine
Let us assume that the customer organization is planning to replace its 704 with a LARC. Two items must be
available:
1. A manual describing the LARC ML.
2. A translator (presumably supplied by the LARC manufacturer) written in UNCOL which translates
UNCOL into the LARC ML.
- 8 -

If the LARC was used to check out this translator, a version of the translator in LARC ML has already been
produced which could be supplied to the customer or organization, eliminating the need for Run #6, below.
To begin the conversion process, the customer makes Machine Runs # 5 and # 6 on his existing 704. Note that
at the end of Run # 6 a program has been produced in LARC ML without programming effort on the part of
the customer.
The customer must have available an UNCOL version of each OMNITRAN program to be run on the LARC.
If the UNCOL program decks have not been preserved, they may be recreated by performing Run #2, above.
To produce programs in the LARC ML, the customer performs Run # 7 on his existing 704 for each program
desired.
- 9 -

At this point the customer has a file of program decks in LARC ML which permit him to make production
runs on the new machine as soon as it is delivered.
New problems continue to be coded in 0MNITRAN.
After delivery of the new machine, the customer must perform Run #9a once to obtain a generator in LARC
ML which translates OMNITRAN into UNCOL. Actually, the customer need not have waited for the new
machine to produce this generator. Run 9b illustrates the way this generator could have been produced on the
704.
- 10 -

The customer organization is now in routine operation on the LARC. For each new problem coded in
OMNITRAN, runs 10 and 11 are performed once.
Production runs are accomplished as in Run # 8 above.
- 11 -

Any installation can exchange a routine with any other installation, regardless of the machine or POL used, by
submitting an UNCOL deck and listing of the routine. The problem description would probably be enhanced
if the P0L deck and listing were also exchanged.
CASE III. Revision of UNCOL
Revisions of UNCOL are not expected to occur very often, possibly only every ten years or so. However, when
a change is required, UNCOL has the versatility to permit its own revision. Assume that a new standard,
UNCOL II, is to replace the previously used UNCOL I. By considering UNCOL II as an ML, it is possible to
write a "transition translator" in UNCOL I.
The customer organization using the LARC has an UNCOL I-to-LARC-ML translator available.
By performing Run # 12 below, the customer can produce a "transition translator" in LARC ML.
Using the translator thus produced, each generator, translator or routine written in UNCOL I can be
translated into UNCOL II.
FUTURE POSSIBILITIES
1. In CASE III above, one programmer developed a routine in UNCOL I which permitted all customer
organizations to effect a new standard, UNCOL II, without programming effort. This is a higher degree
of "boot-strapping" than hitherto contemplated.
2. Certain areas of programming effort still remain, however.
a) Each time a new machine is developed, a translator must be written to convert UNCOL to the
new ML.
- 12 -

It is altogether possible that a general translator could be written to eliminate the need for
programming in this area.
b) Each time a new POL is developed, a generator must be written to translate the POL into
UNCOL.
It is conceptually possible that a "general generator" can be written to eliminate the need for
programming in this area.
This would appear to be the maximum in "boot-strapping". Any problem could, in effect, have its
own POL tailored to suit its idiosyncrasies, and programming would have advanced to
formulating appropriate POL's.
- 13 -

2. Testo tradotto

IL PROBLEMA DELLA COMUNICAZIONE DELLA PROGRAMMAZIONE TRA MACCHINE
DIVERSE
UNA PROPOSTA DI SOLUZIONE DI:
J. STRONG, North American Aviation; J. OLSZTYN, General Motors Corp.;
J. WEGSTEIN, Bureau of Standards; O. MOCK, North American Aviation;
A. TRITTER, Lincoln Laboratory; T. STEEL, Systems Development Corp.
REPORT DEL COMITATO AD HOC DELLA SHARE PER LO STUDIO DI UN LINGUAGGIO UNIVERSALE
I. ASSUNTI DI BASE
Uno dei problemi fondamentali che oggi deve affrontare la professione informatica è il notevole lasso di tempo
necessario per sviluppare un efficace metodo di comunicazione con la macchina. Inoltre, sembra che non
appena si acquisisca la capacità di comunicare facilmente, il linguaggio cambia e il problema si rinnova,
solitamente a un livello di complessità più elevato.
A. Obsolescenza delle macchine. L'esperienza indicherebbe che sono pochi gli utenti di computer che
non acquistano macchine nuove e diverse ogni tre o cinque anni, un cambiamento generalmente
richiesto dall'obsolescenza tecnica piuttosto che dalla reale decadenza della macchina. Nella maggior
parte dei casi, la comparsa di una nuova macchina coincide con la necessità di espandere la capacità
di calcolo. Sebbene il costo di programmazione richiesto per cambiare le macchine sia elevato, la
pressione per passare a queste nuove macchine è stata sufficientemente grande da giustificarne
l'acquisizione.
B. Crescente sofisticazione dei linguaggi macchina. Finora, ogni progresso nella progettazione delle
macchine è stato accompagnato da una maggiore complessità nella struttura del suo linguaggio,
rendendo la programmazione in un determinato linguaggio macchina progressivamente più costosa sia
in termini di dollari che di tempo trascorso ad impararlo.
C. Compilatori esistenti. Gli attuali compilatori alleviano un po' il problema traducendo un particolare
linguaggio "facile da programmare" in uno specifico codice macchina. Il principale difetto di questo
approccio è il considerevole lasso di tempo tra la concezione iniziale del linguaggio "facile da
codificare" e la sua accettazione generale. Questo tempo è dello stesso ordine di grandezza del ciclo
di sostituzione della macchina, con conseguente pericolo sempre presente di avere a disposizione un
buon compilatore per la vecchia macchina subito dopo la sua sostituzione.
II. APPROCCI PER UNA SOLUZIONE.
Esamineremo ora un ampio ventaglio di caratteristiche che potrebbero descrivere un "sistema" in grado di
risolvere queste problematiche.
A. Specifiche ideali
1. Il metodo di soluzione del quesito di un utente dovrebbe poter esser descritto alla macchina nel
linguaggio che risulta più affine al suo modo di pensare.
2. Una volta che il problema è stato codificato in un determinato linguaggio, la soluzione potrebbe essere
ottenuta elaborando il programma con un'efficienza accettabile su qualsiasi computer presente o
futuro. (L'efficienza operativa nel sistema proposto sarebbe uguale al costo totale più basso possibile,
inclusa la programmazione, diviso il costo totale effettivo.).
3. Dovrebbe essere necessaria una minima "programmazione del sistema" giusto per avviarlo e
mantenerlo in funzione inizialmente. Per la maggior parte delle installazioni non dovrebbe essere
richiesta alcuna programmazione di sistema.
- 17 -

B. Specifiche concrete
Le specifiche ideali riportate sopra necessitano di alcune interpretazioni, poiché nelle loro implicazioni finali,
potrebbero non essere realizzabili in questo secolo. Su di esse facciamo seguire alcune considerazioni.
1. Affermare che un utente descriva un problema ad una macchina nel linguaggio "più naturale" possibile
è fuorviante, poiché la sua lingua madre, l'inglese, è capace di sfumature di significato quasi infinite.
Poche persone sanno usare l'inglese in modo preciso e inequivocabile. Di conseguenza, il metodo di
espressione più naturale dovrà essere necessariamente compromesso nell'interesse della precisione.
Ciò non è un qualcosa di straordinario dal momento che quasi tutte le discipline scientifiche, la
maggior parte delle professioni e dei mestieri hanno un loro linguaggio esclusivo e abbastanza preciso.
2. L'ideale di elaborare ogni problema in ogni lingua su ogni computer e produrre risultati efficienti può
probabilmente essere realisticamente conseguito senza troppi compromessi, a patto che si verifichino
le seguenti condizioni:
a. Il codificatore può ottenere una maggiore efficienza se conosce le specifiche del computer su di
cui verrà elaborata la sua routine.
b. Qualsiasi routine scritta per un computer piccolo può essere elaborata su uno più grande.
Viceversa, una routine scritta per un computer più grande dovrebbe essere in grado di essere
eseguita solo su pochi computer più piccoli di diversi ordini di grandezza e certamente non su
di un solo di essi. empio, le routine concepite per una macchina 709 non verrebbero tradotte
normalmente nel linguaggio E101 poiché potrebbero impegnare per molti anni una macchina
più piccola.
c. Un computer di grandi dimensioni è sempre disponibile all’ampliamento del sistema per tutti
gli eventuali usi successivi rispetto ad un computer di minori dimensioni.
d. Sebbene la progettazione del computer sia influenzata dal sistema operativo, esso non dovrebbe
dipendere da questo fattore e, al contempo, non dovrebbe in alcun modo inibire lo sviluppo di
computer più potenti limitando la complessità dei loro linguaggi di base.
3. Per quel che riguarda il tempo necessario allo sviluppo di un nuovo sistema, sarebbe auspicabile che i
primi risultati utili fossero disponibili in un periodo compreso fra i tre e i cinque anni. La progettazione
di un sistema non dovrebbe basarsi su di una "svolta" importante nell'arte della programmazione. Un
sistema, ad esempio, dovrebbe reggere e non cedere sulla possibilità di migliorare una sua routine così
come più in generale dovrebbe poter trasformare ogni tipo di linguaggio di programmazione in ogni
altro tipo di linguaggio macchina.
III. ULTERIORI ASSUNTI.
La soluzione proposta al problema sarà presentata in dettaglio nel successivo paragrafo 5. Poiché alcuni dei
presupposti alla base di questa soluzione possono essere considerati controversi, una loro discussione
preliminare qui può aiutare a chiarire la proposta finale.
A. Linguaggi.
1. È impossibile concordare un POL (Problem-0riented Language N.d.r.) universale. Poiché ci sono
molte varietà di problemi, qualsiasi tentativo di universalità dei linguaggi orientati ai problemi si
tradurrà in inadeguatezza (come un tentativo di usare il linguaggio algebrico per un problema logico)
o in una tale ampiezza da diventare inutile. In quest'ultimo caso, il POL "universale" è in realtà la
somma di tutti i possibili POL e non è mai veramente universale per molto tempo, poiché il linguaggio
deve crescere per far fronte alle nuove classi di problemi che si presentano.
2. I linguaggi macchina continueranno a crescere in complessità e diventeranno sempre più difficili da
codificare. Tutti guardano con timore ai possibili computer del prossimo decennio, che eseguiranno
contemporaneamente più programmi memorizzati asincroni. Ci sono poche ragioni per aspettarsi
un'inversione di questa tendenza.
3. Lo stato attuale dell'arte del compilatore richiede una routine generativa piuttosto difficile per
trasformare ogni POL formulato in ogni ML (Machine Language N.d.r.) desiderato. Inoltre, routine
aggiuntive devono essere scritte ogni volta che è necessario produrre un ML diverso da quello
appartenente alla macchina su cui viene eseguita la routine di traduzione. Il numero di singoli
compilatori necessari del tipo attuale può solo aumentare quando diventa auspicabile che i POL si
moltiplichino, che le macchine vengano sostituite e che un'organizzazione abbia diversi tipi di
- 18 -

macchine. Si avvicina rapidamente il momento in cui la necessità di queste routine supererà ogni
possibile offerta.
B. Programmazione
1. Allo stato attuale dell'arte della programmazione, una routine ragionevolmente efficiente può essere
scritta per trasformare un qualsiasi linguaggio specifico in un qualsiasi altro linguaggio specifico.
2. Le complessità del linguaggio trasformato determinano la dimensione della macchina necessaria per
un accettabile grado di efficienza sia nel processo di trasformazione che nella successiva esecuzione
della routine ML.
C. Macchine
Sarà disponibile per i programmatori di sistema una macchina complessa almeno quanto l'IBM 709 e
strumenti di programmazione in linguaggio macchina versatili almeno quanto il sistema di
programmazione SHARE 709.
IV. SOLUZIONE - IL CONCETTO A TRE LIVELLI ("UNCOL").
A. Storia.
Questo concetto non è particolarmente nuovo o originale. È stato discusso da molte persone
indipendenti già nel 1954. Potrebbe non essere difficile dimostrare che "questo era ben noto a
Babbage", quindi non è stato fatto alcuno sforzo per dare credito all'origine, ammesso che ci fosse
davvero un’unica origine.
B. Profilo.
Il sistema è composto da tre livelli di linguaggio, come mostrato nel diagramma schematico in
Appendice B.
1. Livello ML. Il livello più basso (il più vicino ai bit nell'hardware della macchina) è composto da tutte
le ML attuali o future.
2. Livello POL. Il livello più alto (il più lontano dalla macchina) è composto da tutti i POL attuali e
futuri.
3. Livello UNCOL. Il livello centrale è un unico linguaggio "UNCOL", l'Universal Computer Oriented
Language.
4. Generatori. I generatori sono quelle routine che eseguono la trasformazione da POL a UNCOL. Sono
analoghi ai presenti compilatori generativi, tranne per il fatto che producono non un certo numero di
ML, ma solo UNCOL. Come con i compilatori attuali, uno di questi sarebbe necessario per ogni POL
utilizzato con una data macchina.
C. Traduttori.
Si tratta di routine che eseguono la trasformazione da UNCOL a ML e sono come i compilatori attuali
in quanto sono preprocessori una tantum prima dell'esecuzione del programma del cliente. Tuttavia,
non sono così complessi né così difficili da scrivere come i "generatori" sopra descritti, poiché
UNCOL, essendo orientato al computer, ha molte cose in comune con ciascuno dei ML. Per ogni
macchina deve essere prodotto un solo traduttore, indipendentemente dal numero di POL formulati o
utilizzati
V. CONCLUSIONI
Potrebbe sembrare che il sistema a tre livelli UNCOL non faccia altro che complicare il metodo attuale, secondo
cui i compilatori consentono di procedere direttamente e con semplicità da un POL prescelto ad una specifica ML.
Non è così. La versatilità di questo sistema è quasi illimitata. A causa della sua complessità, è stato riscontrato
che un confronto dettagliato di UNCOL richiede una speciale notazione del diagramma di flusso (descritto in
Appendice B). Nell'Appendice D sono illustrati alcuni esempi di come questo sistema potrebbe funzionare con
l'aggiunta di questa notazione. Le considerazioni finali sono state riassunte di seguito.
- 19 -

A. Benefici immediatamente definiti.
1. Man mano che viene prodotta ogni nuova macchina, tutto ciò che sarebbe necessario in termini di
programmazione del sistema è un singolo traduttore per convertire UNCOL nel nuovo ML. Il
produttore della macchina probabilmente scriverà diverse versioni successive per ciascuna delle sue
macchine nel tentativo di sfruttare al meglio le caratteristiche eccezionali di ciascuna di esse.
2. Man mano che ogni POL viene concepito, un programmatore di sistema dovrà scrivere un generatore
per tradurre il suo POL in UNCOL. Così Così facendo il suo POL non diventerà mai obsoleto. Le
routine scritte in UNCOL potranno essere eseguite su qualsiasi macchina in qualsiasi momento futuro.
3. Il sistema UNCOL consentirà con un'installazione di utilizzare i suoi programmi correnti su qualsiasi
macchina senza costi di programmazione aggiuntivi.
4. Il sistema UNCOL potrà essere progettato, programmato e installato entro tre anni. I vantaggi di cui
sopra potranno essere raggiunti senza richiedere grandi sforzi nelle tecniche di programmazione.
5. I programmatori di sistema probabilmente lavoreranno la maggior parte del tempo in UNCOL con
discese, solo occasionali, al livello del ML. Una grande percentuale dei problemi del cliente sarà
codificata in uno o nell'altro POL. Se, tuttavia, nessun POL è adatto, il problema potrà essere codificato
direttamente in UNCOL.
B. Potenziale di crescita.
Sebbene esistano le seguenti potenzialità, esse sono indipendenti dai vantaggi del sistema UNCOL sopra
elencati. Che UNCOL provveda alla crescita in questa direzione è un importante plus valore.
1. Il "boot-strapping" è una possibilità concreta; con questo termine si intende la capacità di adattare il
sistema a nuovi POL, macchine (o anche nuove versioni di UNCOL) con un minimo di
programmazione umana. Vale a dire, il sistema potrà essere auto aggiornato in larga parte, con le
routine di sistema in grado di produrne nuove e migliori.
2. Il "boot-strapping" semplice sarà probabilmente disponibile quasi immediatamente. I programmatori
di sistema che scriveranno in UNCOL potranno utilizzare un traduttore esistente per produrre i loro
programmi di sistema in ML.
3. È del tutto possibile che entro cinque anni le tecniche di programmazione possano consentire di
scrivere un "traduttore generale" in UNCOL che, date le caratteristiche della macchina "A", produca
(su altre macchine) un traduttore che converta da UNCOL in ML della macchina "A".
4. L’ultimo, e meno probabile, passo sarebbe lo sviluppo del "generatore generale". Questa routine, date
le caratteristiche dei POL e della macchina su cui dovrebbe funzionare, produrrebbe il generatore per
tradurre i POL in UNCOL.
APPENDICE A
LINGUAGGI si riferiscono ai simboli e alle regole per usarle come comprese da un essere
umano. Questo è indipendente dal particolare veicolo (e dal suo codice locale)
- 20 -

utilizzato per trasportarli (ad esempio, schede perforate, nastro magnetico,
ecc.).
POL: qualsiasi linguaggio orientato ai problemi, ad esempio FORTRAN.
ML: linguaggio macchina di base per qualsiasi macchina particolare. Se
accompagnato da appropriati “traduttori di input”, ML può essere esteso per
includere linguaggi “simil macchina” unici per una particolare macchina, ad
esempio il linguaggio simbolico SAP per il 704.
UNCOL: linguaggio universale orientato al computer. Questo è un linguaggio standard
orientato ai requisiti dei computer digitali generici. Deve avere almeno le loro
caratteristiche di poter esprimere qualsiasi problema computabile. (Nel
diagramma schematico generale, Appendice B, e solo lì, i linguaggi sono
circondate da un rettangolo ▭).
ROUTINE sono insiemi di istruzioni disposte correttamente in sequenza. Possono esistere
in qualsiasi linguaggio e di solito vengono trasformati almeno una volta in un
altro linguaggio. Sono designati con lettere maiuscole, quindi:
P: Problemi. Quelle routine che esprimono la soluzione di un problema.
Normalmente si tratta di "operazioni del cliente" (ad es.: buste paga, prestazioni
di un aeromobile, ecc.) e possono essere facilmente scritte in un POL.
G: Generatori. Quelle routine che operano su routine esistenti in un POL ed
eseguono la trasformazione da uno specifico POL a UNCOL.
T: Traduttori. Quelle routine che operano su una routine esistente in UNCOL ed
eseguono la trasformazione da UNCOL a una specifica ML.
APICI Il simbolo per una routine è riportato in un apice, indicante il linguaggio
specifico in cui agisce la routine; ad esempio FORTRAN (che significa quel
particolare POL), UNCOL (che è unico) o 704 (che significa quel particolare
ML).
PEDICI vengono utilizzati per designare l'operazione eseguita dalla routine.
Normalmente non è necessario utilizzare un pedice con P. Tuttavia, G e T
devono avere un pedice, che denota la trasformazione eseguita dalla routine.
Per esempio; la notazione:
denota un traduttore che trasforma una routine in UNCOL nella stessa routine
in linguaggio macchina 704. La stessa routine di traduzione è in linguaggio 704.
MACCHINA Si indica con un triangolo, da cui:
FLOWCHART Il numero, preceduto da R, all'apice denota una corsa specifica della macchina.
Il flusso indica un'esecuzione della macchina. Tutte le routine e i dati necessari
vengono mostrati come input. Anche l’output è definito. Le routine sono
mostrate all’interno del simbolo ovale: ㇣. Ad esempio, un ciclo di produzione
convenzionale, #872, su un ElectroData 205 è mostrato come:
- 21 -

Il simbolo significa "in funzione". Pertanto, il grafico di cui sopra si leggerà così:
"Un Problema di routine 872 nel linguaggio 205 e i suoi DATI DEL CASO
confluiscono nel 205 mentre i RISULTATI appropriati vengono prodotti.”.
Generatori e traduttori operano su altre routine (solitamente routine Problem) e
producono la routine in un altro linguaggio come output; ad esempio, una corsa 704
#892 potrebbe essere:
Ciò significa: "Il Generatore in linguaggio 704 opera (nel 704) sul Problema in
linguaggio FORTRAN e produce come output una routine Problema in linguaggio
UNCOL".
NOTE alcune regole che possono tornare utili:
a) La routine che viene eseguita deve avere un apice uguale alla macchina
utilizzata per l'esecuzione.
b) La routine su cui si opera deve avere un apice uguale alla prima metà del
pedice della G o della T che si sta eseguendo.
c) L'output è la routine su cui è stata operata con il suo apice uguale all'ultima
metà del pedice della G o della T che viene eseguita.
APPENDICE C
UTILIZZO DEL SISTEMA UNCOL
I tre casi descritti di seguito illustrano le tecniche utilizzate:
IV. Avviare una nuova POL nel sistema UNCOL.
V. Come convertire da una macchina all'altra.
VI. Come rivedere il linguaggio UNCOL (se necessario).
Si assume che l'organizzazione cliente abbia a disposizione:
4. Un rapporto che descrive UNCOL, che è stato definito come standard da una parte significativa dei
professionisti informatici.
5. Una macchina e il suo sistema di programmazione in linguaggio associato. Per questo esempio,
supponiamo un 704 e SAP.
6. Un traduttore, precedentemente scritto e collaudato (sul 704) che traduce da UNCOL in (704) ML.
CASO I: Introduzione di un nuovo POL
Il POL in discussione potrebbe essere uno già esistente in precedenza, ma che è nuovo per l'organizzazione
del cliente o uno di nuova formulazione utilizzato per la prima volta. Per questo esempio, supponiamo che il
- 22 -

POL sia di nuova formulazione e che sia chiamato OMNITRAN. Per implementare OMNITRAN,
l'organizzazione cliente deve avere a disposizione:
3. Un rapporto che descrive OMNITRAN.
4. Un "generatore" in linguaggio UNCOL (presumibilmente scritto dal formulatore di OMNITRAN) che
traduce OMNITRAN in UNCOL.
Se il 704 è stato utilizzato per controllare questo generatore, è già stato prodotto un secondo generatore in
linguaggio 704 per tradurre OMNITRAN in UNCOL. Questo generatore potrebbe anche essere messo a
disposizione dell'organizzazione del cliente, eliminando la necessità di Machine Run # 1, come di seguito.
Machine Run # 1 è necessario per produrre un generatore OMNITRAN in 704 ML dal generatore OMNITRAN
fornito in UNCOL.
I problemi del cliente sono scritti in OMNITRAN;
pertanto, le esecuzioni 2 e 3 della macchina devono essere eseguite una volta per ogni nuovo programma
scritto. Queste esecuzioni sono analoghe all'esecuzione di compilazione su di un compilatore corrente. Le
esecuzioni 2 e 3 possono essere combinate, se non è necessario, per preservare le routine del problema nella
loro istruzione UNCOL.
- 24 -

Il ciclo n. 4 diventa il ciclo di produzione della routine del cliente. Se è richiesta una tecnica di "modifica ed
esecuzione", le modifiche possono essere scritte in OMNITRAN e le esecuzioni 2, 3 e 4 possono essere
combinate in un'unica esecuzione della macchina.
CASO II: Conversione in una nuova macchina
Supponiamo che l'organizzazione del cliente stia pianificando di sostituire il suo 704 con un LARC. Devono
essere disponibili due prodotti:
3. Un manuale che descrive il LARC ML.
4. Un traduttore (presumibilmente fornito dal produttore di LARC) scritto in UNCOL che traduce
UNCOL in LARC ML.
- 25 -

Se il LARC è stato utilizzato per controllare questo traduttore, è già stata prodotta una versione del traduttore
in LARC ML che potrebbe essere fornita al cliente o all'organizzazione, eliminando la necessità
dell'esecuzione n. 6, di seguito.
Per iniziare il processo di conversione, il cliente esegue i Machine Run # 5 e # 6 sulla sua 704 esistente. Si noti
che alla fine del Run # 6 è stato prodotto un programma in LARC ML senza sforzo di programmazione da
parte del cliente.
Il cliente deve avere a disposizione una versione UNCOL di ogni programma OMNITRAN da eseguire sul
LARC.
Se gli insiemi del programma UNCOL non sono stati conservati, possono essere ricreati eseguendo
l'Esecuzione n. 2, sopra. Per produrre programmi in LARC ML, il cliente esegue Run # 7 sul suo 704 esistente
per ogni programma desiderato.
- 26 -

A questo punto il cliente dispone di un file di insiemi di programma in LARC ML che gli permettono di
effettuare cicli di produzione sulla nuova macchina appena consegnata.
Nuovi problemi continuano ad essere codificati in OMNITRAN.
Dopo la consegna della nuova macchina, il cliente deve eseguire una volta il Run #9a per ottenere un generatore
in LARC ML che traduce OMNITRAN in UNCOL. In realtà, il cliente non ha dovuto aspettare la nuova
macchina per produrre questo generatore. Run # 9b illustra il modo in cui questo generatore avrebbe potuto
essere prodotto sul 704.
- 27 -

L'organizzazione del cliente è ora operativa sul LARC. Per ogni nuovo problema codificato in OMNITRAN,
le esecuzioni 10 e 11 vengono eseguite una volta.
I cicli di produzione vengono eseguiti come nell'Esecuzione n. 8 di cui sopra.
- 28 -

Qualsiasi installazione può scambiare una routine con qualsiasi altra installazione, indipendentemente dalla
macchina o dal POL utilizzato, inviando un insieme UNCOL e un elenco della routine. La descrizione del
problema verrebbe probabilmente migliorata se venissero scambiati anche l’insieme POL e l'elenco.
CASO III. Revisione dell'UNCOL
Non si prevede che le revisioni dell'UNCOL avvengano molto spesso, forse solo ogni dieci anni circa. Tuttavia,
quando è necessario un cambiamento, UNCOL ha la versatilità necessaria per consentire la propria revisione.
Supponiamo che un nuovo standard, UNCOL II, sostituisca l'UNCOL I utilizzato in precedenza. Considerando
UNCOL II come un ML, è possibile scrivere un "traduttore di transizione" in UNCOL I.
L'organizzazione del cliente che utilizza LARC dispone di un traduttore UNCOL I-to-LARC-ML.
Eseguendo l'esecuzione n. 12 di seguito, il cliente può produrre un "traduttore di transizione" in LARC ML.
Utilizzando il traduttore così prodotto, ogni generatore, traduttore o routine scritta in UNCOL I può essere
tradotto in UNCOL II.
POSSIBILITÀ FUTURE
3. Nel CASO III di cui sopra, un programmatore ha sviluppato una routine in UNCOL I che ha permesso
a tutte le organizzazioni clienti di attuare un nuovo standard, UNCOL II, senza sforzo di
programmazione. Questo è un grado più elevato di "boot-strapping" rispetto a quanto contemplato
finora.
4. Tuttavia, rimangono ancora alcune aree di impegno nella programmazione.
c) Ogni volta che viene sviluppata una nuova macchina, è necessario scrivere un traduttore per
convertire UNCOL nel nuovo ML.
- 29 -

È del tutto possibile che si possa scrivere un traduttore generale per eliminare la necessità di
programmare in quest'area.
d) Ogni volta che viene sviluppato un nuovo POL, è necessario scrivere un generatore in cui tradurre
il POL UNCOL.
È concettualmente possibile scrivere un "generatore generale" per eliminare la necessità di
programmazione in quest'area.
Questo sembrerebbe essere il massimo in "boot-strapping". Qualsiasi problema potrebbe, in
effetti, avere il suo proprio POL su misura per soddisfare le sue idiosincrasie, e la
programmazione sarebbe avanzata alla formulazione di POL appropriati.
Traduzione effettuata con Google traduttore e adattamento di Salvatore Giglio
- 30 -

UNCOL traduzione.pdf

Recommended

Recommended

More Related Content

Similar to UNCOL traduzione.pdf

Similar to UNCOL traduzione.pdf (20)

More from CADZINE

More from CADZINE (20)

UNCOL traduzione.pdf