https://ada83.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=Vmo 2026-07-27T08:48:51Z User contributions MediaWiki 1.43.0 https://ada83.org/wiki/index.php?title=Documentation&diff=203 2025-06-11T08:32:36Z

<p>Vmo: /* The ENST theses and P.Kruchten / J.P.Rosen documents */</p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> [[File:Ada LRM US gov.jpg|thumb|center| An original soft cover Ada 83 LRM distributed circa 1989 with an HP machine]]<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> In the end of 1986, two theses are presented at the ENST (Ecole Nationale Supérieure des Télécommunications) a work done in collaboration with the NYUADA project team where [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar] is then working.<br /> <br /> * Philippe Kruchten : [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> This is a very important reference for understanding Ada/Ed type template mechanism.<br /> <br /> * Jean Pierre Rosen : [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> The DIANA intermediate representation revision 4 of 1986 [[:File:DIANA-Ref-Manual-1986-rev4.pdf | Intermetrics 1986 ]]<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]<br /> <br /> ==== Ada 83 compiler research ====<br /> <br /> The these from J. van Katwijk at Delft university in 1987 describing the &quot;Ada-&quot; (Ada minus) compiler : [[:File:Thesis J Katwijk AdaMinus compiler 1987.pdf|thesis Katwijk]]<br /> <br /> A rare article on the generics implementation in Ada 83 :<br /> [[:File:G Bray Generics.pdf|Implementation Implications of Ada Generics G.Bray sept 1983 ]]</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=202 2025-05-18T13:23:03Z

<p>Vmo: /* Ada 83 compiler research */</p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> [[File:Ada LRM US gov.jpg|thumb|center| An original soft cover Ada 83 LRM distributed circa 1989 with an HP machine]]<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> The DIANA intermediate representation revision 4 of 1986 [[:File:DIANA-Ref-Manual-1986-rev4.pdf | Intermetrics 1986 ]]<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]<br /> <br /> ==== Ada 83 compiler research ====<br /> <br /> The these from J. van Katwijk at Delft university in 1987 describing the &quot;Ada-&quot; (Ada minus) compiler : [[:File:Thesis J Katwijk AdaMinus compiler 1987.pdf|thesis Katwijk]]<br /> <br /> A rare article on the generics implementation in Ada 83 :<br /> [[:File:G Bray Generics.pdf|Implementation Implications of Ada Generics G.Bray sept 1983 ]]</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=200 2025-05-18T08:28:46Z

<p>Vmo: /* Ada 83 compiler research */</p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> [[File:Ada LRM US gov.jpg|thumb|center| An original soft cover Ada 83 LRM distributed circa 1989 with an HP machine]]<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> The DIANA intermediate representation revision 4 of 1986 [[:File:DIANA-Ref-Manual-1986-rev4.pdf | Intermetrics 1986 ]]<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]<br /> <br /> ==== Ada 83 compiler research ====<br /> <br /> The these from J. van Katwijk at Delft university in 1987 describing the &quot;Ada-&quot; (Ada minus) compiler : [[:File:Thesis J Katwijk AdaMinus compiler 1987.pdf|thesis Katwijk]]</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=199 2025-05-18T08:27:56Z

<p>Vmo: /* DIANA Intermediate Representation documents */</p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> [[File:Ada LRM US gov.jpg|thumb|center| An original soft cover Ada 83 LRM distributed circa 1989 with an HP machine]]<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> The DIANA intermediate representation revision 4 of 1986 [[:File:DIANA-Ref-Manual-1986-rev4.pdf | Intermetrics 1986 ]]<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]<br /> <br /> ==== Ada 83 compiler research ====<br /> <br /> The these from J. van Katwijk at Delft university in 1987 describing the &quot;Ada-&quot; (Ada minus) compiler : [[File:Thesis J Katwijk AdaMinus compiler 1987.pdf|thesis Katwijk]]</div>

Vmo https://ada83.org/wiki/index.php?title=File:DIANA-Ref-Manual-1986-rev4.pdf&diff=198 2025-05-18T08:25:09Z

<p>Vmo: Manuel_DIANA_1986 complete specification</p> <hr /> <div>== Summary ==<br /> Manuel_DIANA_1986 complete specification</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=197 2025-05-18T08:22:05Z

<p>Vmo: /* Ada 83 compiler research */</p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> [[File:Ada LRM US gov.jpg|thumb|center| An original soft cover Ada 83 LRM distributed circa 1989 with an HP machine]]<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]<br /> <br /> ==== Ada 83 compiler research ====<br /> <br /> The these from J. van Katwijk at Delft university in 1987 describing the &quot;Ada-&quot; (Ada minus) compiler : [[File:Thesis J Katwijk AdaMinus compiler 1987.pdf|thesis Katwijk]]</div>

Vmo https://ada83.org/wiki/index.php?title=File:G_Bray_Generics.pdf&diff=196 2025-05-18T08:21:38Z

<p>Vmo: One rare article on generics implementation problems in Ada 83</p> <hr /> <div>== Summary ==<br /> One rare article on generics implementation problems in Ada 83</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=195 2025-05-18T08:19:06Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> [[File:Ada LRM US gov.jpg|thumb|center| An original soft cover Ada 83 LRM distributed circa 1989 with an HP machine]]<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]<br /> <br /> ==== Ada 83 compiler research ====<br /> <br /> The these from J. van Katwijk at Delft university in 1987 describing the &quot;Ada-&quot; (Ada minus) compiler : [[Thesis J Katwijk AdaMinus compiler 1987.pdf|thesis Katwijk]]</div>

Vmo https://ada83.org/wiki/index.php?title=File:Thesis_J_Katwijk_AdaMinus_compiler_1987.pdf&diff=194 2025-05-18T08:17:57Z

<p>Vmo: J.van Katwijk thesis on &quot;Ada minus&quot; compiler with reviews of Ada 83 technical information available at the time.</p> <hr /> <div>== Summary ==<br /> J.van Katwijk thesis on &quot;Ada minus&quot; compiler with reviews of Ada 83 technical information available at the time.</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=181 2025-05-16T07:48:25Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> [[File:Ada LRM US gov.jpg|thumb|center| An original soft cover Ada 83 LRM distributed circa 1989 with an HP machine]]<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]</div>

Vmo https://ada83.org/wiki/index.php?title=File:Ada_LRM_US_gov.jpg&diff=180 2025-05-16T07:42:42Z

<p>Vmo: An original soft cover LRM</p> <hr /> <div>== Summary ==<br /> An original soft cover LRM</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_history&diff=179 2025-05-13T21:22:49Z

<p>Vmo: </p> <hr /> <div>

<br /> == Brief historical context ==<br /> <br /> In the history of the development of modern computing, there is a particular and rich period that extends from the early 1980s to the mid-1990s.<br /> This period corresponds to the appearance and maturation of personal computing (IBM PC in 1981, Apple Macintosh in 1984) and the birth of the<br /> Internet. <br /> <br /> The previous period, which could be situated in the 1970s, saw the beginning of microprocessor technology (Intel 4004 in 1971) which would lead<br /> to the gradual disappearance of large “mainframe” computers in favor of mini-computers and then micro-computers and compact personal<br /> workstations with increasing power. <br /> Computer programming languages ​​follow the evolution of increasingly capable hardware in terms of speed and memory, and one of them in<br /> particular, the Pascal language, which appeared in 1970, will exert a particular influence. <br /> Following Pascal, a reflection on the homogenization of software systems of the American Department of Defense (DoD) began in 1974 and led in<br /> 1983 to the definition of a highly advanced language: Ada, now known as Ada 83 to distinguish it from its evolutionary versions Ada 95 and later,<br /> 2005, 2012, 2022.<br /> 

<br /> == Ada 83 in its time ==<br /> <br /> Here is a timeline of salient events relating to the period that interests us (preparatory from 1970 to 1983, standardized life of the Ada 83<br /> language from 1983 to 1994).<br /> <br /> '''1971''' the Intel 4004 microprocessor is produced.<br /> <br /> '''1974''' independent proposals for a common language from the US defense services: US-ARMY, US-AIR FORCE, US-NAVY.<br /> <br /> '''1975''' Creation of the High Order Language Working Group (HOLWG), beginning of the Strawman language specifications, then Wooden man.<br /> <br /> '''1976''' (January) Tinman specifications, parallel evaluation of 23 existing languages. Derivatives of the Algol-68, Pascal, PL-1 languages ​​are<br /> recognized as possible bases.<br /> <br /> '''1977''' (January) Ironman specifications. <br /> (August) four competitors emerge among 15 proposals mainly based on Pascal: CII-Honeywell Bull, Intermetrics, Softech, SRI International.<br /> <br /> '''1978''' 2 competitors continue: Steelman specifications. Digital Equipment Corporation (DEC) releases the VAX 11/780 <br /> <br /> '''1979''' (April) The “Green” project led by Jean Ichbiah (CII-Honeywell team) is selected. In May the name of the language is chosen, it will be “Ada”, in<br /> homage to Augusta Ada Lovelace (1815-1852), daughter of the poet Byron and collaborator of Charles Babbage in his work on the “Analytical<br /> Machine”. New York University (NYU) with Robert Dewar examines the Ada specification and develops a partial executable model in SETL<br /> language. Launch of the Stoneman project for a programming environment for the common Ada language. Appearance of the Motorola 68000<br /> microprocessor. It will be discontinued in 1996, the succession being taken over by its successors 68010 to 68060. <br /> <br /> '''1980''' intermediate standard, NYU Ada/Ed is adapted. In December HOLWG becomes Ada Joint Program Office (AJPO). J. Ichbiah founds Alsys. <br /> 1981 IBM introduces the first PC. <br /> 1982 new Ada reference manual, adapted from NYU Ada/Ed1983 release of the ANSI-MIL-STD-1815 standard defining Ada 83, in April Ada/Ed is validated on the ACVC (Ada Compiler Validation Capability)<br /> tests. <br /> <br /> [[File:Diploma of first validated compiler.jpg|center|frame|caption|300px|alt=Presentation of diploma for first validated Ada compiler|Presentation of diploma for first validated Ada compiler to the Ada/Ed team, Robert Dewar (right) and Ed Schonberg (left)]]<br /> <br /> The C language becomes popular, between 1985 and 1992 Ada/Ed will be translated into C. <br /> <br /> '''1984''' Apple presents the Macintosh, DEC releases the Microvax I. The DEC Ada compiler is available. <br /> 1985 release of the IBM OS-2 operating system. Workstation for Ada programming Rational R1000. <br /> <br /> '''1986''' Collaboration of the National Center for the Study of Telecommunications (CNET) with NYU on the C version of Ada/Ed.<br /> <br /> '''1987''' ISO standard, revision in preparation for Ada 95. DEC microvax 3000. <br /> 1989 C language is standardized: ANSI C. <br /> 1990 Intermetrics is chosen for the Ada 9X revision <br /> <br /> '''1992''' DEC Alpha AXP processor. Minicomputers give way to microcomputers. DEC, not having taken the turn well, will disappear in 1998. <br /> <br /> '''1994''' November Ada 95 revision accepted. Now the transition out of Ada 83 begins, although compatible with Ada 83, Ada 95 is in many aspects,<br /> including object programming, a language with a very different flavor.</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_history&diff=178 2025-05-13T21:20:13Z

<p>Vmo: </p> <hr /> <div>

<br /> == Brief historical context ==<br /> <br /> In the history of the development of modern computing, there is a particular and rich period that extends from the early 1980s to the mid-1990s.<br /> This period corresponds to the appearance and maturation of personal computing (IBM PC in 1981, Apple Macintosh in 1984) and the birth of the<br /> Internet. <br /> <br /> The previous period, which could be situated in the 1970s, saw the beginning of microprocessor technology (Intel 4004 in 1971) which would lead<br /> to the gradual disappearance of large “mainframe” computers in favor of mini-computers and then micro-computers and compact personal<br /> workstations with increasing power. <br /> Computer programming languages ​​follow the evolution of increasingly capable hardware in terms of speed and memory, and one of them in<br /> particular, the Pascal language, which appeared in 1970, will exert a particular influence. <br /> Following Pascal, a reflection on the homogenization of software systems of the American Department of Defense (DoD) began in 1974 and led in<br /> 1983 to the definition of a highly advanced language: Ada, now known as Ada 83 to distinguish it from its evolutionary versions Ada 95 and later,<br /> 2005, 2012, 2022.<br /> 

<br /> == Ada 83 in its time ==<br /> <br /> Here is a timeline of salient events relating to the period that interests us (preparatory from 1970 to 1983, standardized life of the Ada 83<br /> language from 1983 to 1994).<br /> <br /> '''1971''' the Intel 4004 microprocessor is produced.<br /> <br /> '''1974''' independent proposals for a common language from the US defense services: US-ARMY, US-AIR FORCE, US-NAVY.<br /> <br /> '''1975''' Creation of the High Order Language Working Group (HOLWG), beginning of the Strawman language specifications, then Wooden man.<br /> <br /> '''1976''' (January) Tinman specifications, parallel evaluation of 23 existing languages. Derivatives of the Algol-68, Pascal, PL-1 languages ​​are<br /> recognized as possible bases.<br /> <br /> '''1977''' (January) Ironman specifications. <br /> (August) four competitors emerge among 15 proposals mainly based on Pascal: CII-Honeywell Bull, Intermetrics, Softech, SRI International.<br /> <br /> '''1978''' 2 competitors continue: Steelman specifications. Digital Equipment Corporation (DEC) releases the VAX 11/780 <br /> <br /> '''1979''' (April) The “Green” project led by Jean Ichbiah (CII-Honeywell team) is selected. In May the name of the language is chosen, it will be “Ada”, in<br /> homage to Augusta Ada Lovelace (1815-1852), daughter of the poet Byron and collaborator of Charles Babbage in his work on the “Analytical<br /> Machine”. New York University (NYU) with Robert Dewar examines the Ada specification and develops a partial executable model in SETL<br /> language. Launch of the Stoneman project for a programming environment for the common Ada language. Appearance of the Motorola 68000<br /> microprocessor. It will be discontinued in 1996, the succession being taken over by its successors 68010 to 68060. <br /> <br /> '''1980''' intermediate standard, NYU Ada/Ed is adapted. In December HOLWG becomes Ada Joint Program Office (AJPO). J. Ichbiah founds Alsys. <br /> 1981 IBM introduces the first PC. <br /> 1982 new Ada reference manual, adapted from NYU Ada/Ed1983 release of the ANSI-MIL-STD-1815 standard defining Ada 83, in April Ada/Ed is validated on the ACVC (Ada Compiler Validation Capability)<br /> tests. <br /> <br /> [[File:Diploma of first validated compiler.jpg|center|frame|caption|400px|alt=Presentation of diploma for first validated Ada compiler|Presentation of diploma for first validated Ada compiler to the Ada/Ed team, Robert Dewar (right) and Ed Schonberg (left)]]<br /> <br /> The C language becomes popular, between 1985 and 1992 Ada/Ed will be translated into C. <br /> <br /> '''1984''' Apple presents the Macintosh, DEC releases the Microvax I. The DEC Ada compiler is available. <br /> 1985 release of the IBM OS-2 operating system. Workstation for Ada programming Rational R1000. <br /> <br /> '''1986''' Collaboration of the National Center for the Study of Telecommunications (CNET) with NYU on the C version of Ada/Ed.<br /> <br /> '''1987''' ISO standard, revision in preparation for Ada 95. DEC microvax 3000. <br /> 1989 C language is standardized: ANSI C. <br /> 1990 Intermetrics is chosen for the Ada 9X revision <br /> <br /> '''1992''' DEC Alpha AXP processor. Minicomputers give way to microcomputers. DEC, not having taken the turn well, will disappear in 1998. <br /> <br /> '''1994''' November Ada 95 revision accepted. Now the transition out of Ada 83 begins, although compatible with Ada 83, Ada 95 is in many aspects,<br /> including object programming, a language with a very different flavor.</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=177 2025-05-13T11:26:29Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> Experiences with Ada code generation [[ :File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf | B.Zorn Berkeley 1984 ]]</div>

Vmo https://ada83.org/wiki/index.php?title=File:Exp_ada_codegen-BG-Zorn-UC-Berkeley-1984.pdf&diff=176 2025-05-13T11:26:02Z

<p>Vmo: Article about using DIANA for code generation</p> <hr /> <div>== Summary ==<br /> Article about using DIANA for code generation</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=175 2025-05-13T11:24:57Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]<br /> <br /> ==== DIANA Intermediate Representation documents ====<br /> <br /> Experiences with Ada code generation [[ :File:B_Zorn_Exp_Berkeley.pdf | B.Zorn Berkeley 1984 ]]</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_history&diff=174 2025-05-13T09:28:01Z

<p>Vmo: </p> <hr /> <div>

<br /> == Brief historical context ==<br /> <br /> In the history of the development of modern computing, there is a particular and rich period that extends from the early 1980s to the mid-1990s.<br /> This period corresponds to the appearance and maturation of personal computing (IBM PC in 1981, Apple Macintosh in 1984) and the birth of the<br /> Internet. <br /> <br /> The previous period, which could be situated in the 1970s, saw the beginning of microprocessor technology (Intel 4004 in 1971) which would lead<br /> to the gradual disappearance of large “mainframe” computers in favor of mini-computers and then micro-computers and compact personal<br /> workstations with increasing power. <br /> Computer programming languages ​​follow the evolution of increasingly capable hardware in terms of speed and memory, and one of them in<br /> particular, the Pascal language, which appeared in 1970, will exert a particular influence. <br /> Following Pascal, a reflection on the homogenization of software systems of the American Department of Defense (DoD) began in 1974 and led in<br /> 1983 to the definition of a highly advanced language: Ada, now known as Ada 83 to distinguish it from its evolutionary versions Ada 95 and later,<br /> 2005, 2012, 2022.<br /> 

<br /> == Ada 83 in its time ==<br /> <br /> Here is a timeline of salient events relating to the period that interests us (preparatory from 1970 to 1983, standardized life of the Ada 83<br /> language from 1983 to 1994).<br /> <br /> '''1971''' the Intel 4004 microprocessor is produced.<br /> <br /> '''1974''' independent proposals for a common language from the US defense services: US-ARMY, US-AIR FORCE, US-NAVY.<br /> <br /> '''1975''' Creation of the High Order Language Working Group (HOLWG), beginning of the Strawman language specifications, then Wooden man.<br /> <br /> '''1976''' (January) Tinman specifications, parallel evaluation of 23 existing languages. Derivatives of the Algol-68, Pascal, PL-1 languages ​​are<br /> recognized as possible bases.<br /> <br /> '''1977''' (January) Ironman specifications. <br /> (August) four competitors emerge among 15 proposals mainly based on Pascal: CII-Honeywell Bull, Intermetrics, Softech, SRI International.<br /> <br /> '''1978''' 2 competitors continue: Steelman specifications. Digital Equipment Corporation (DEC) releases the VAX 11/780 <br /> <br /> '''1979''' (April) The “Green” project led by Jean Ichbiah (CII-Honeywell team) is selected. In May the name of the language is chosen, it will be “Ada”, in<br /> homage to Augusta Ada Lovelace (1815-1852), daughter of the poet Byron and collaborator of Charles Babbage in his work on the “Analytical<br /> Machine”. New York University (NYU) with Robert Dewar examines the Ada specification and develops a partial executable model in SETL<br /> language. Launch of the Stoneman project for a programming environment for the common Ada language. Appearance of the Motorola 68000<br /> microprocessor. It will be discontinued in 1996, the succession being taken over by its successors 68010 to 68060. <br /> <br /> '''1980''' intermediate standard, NYU Ada/Ed is adapted. In December HOLWG becomes Ada Joint Program Office (AJPO). J. Ichbiah founds Alsys. <br /> 1981 IBM introduces the first PC. <br /> 1982 new Ada reference manual, adapted from NYU Ada/Ed1983 release of the ANSI-MIL-STD-1815 standard defining Ada 83, in April Ada/Ed is validated on the ACVC (Ada Compiler Validation Capability)<br /> tests. <br /> <br /> [[File:Diploma of first validated compiler.jpg|frame|caption|400px|alt=Presentation of diploma for first validated Ada compiler|Presentation of diploma for first validated Ada compiler to the Ada/Ed team, Robert Dewar (right) and Ed Schonberg (left)]]<br /> <br /> The C language becomes popular, between 1985 and 1992 Ada/Ed will be translated into C. <br /> <br /> '''1984''' Apple presents the Macintosh, DEC releases the Microvax I. The DEC Ada compiler is available. <br /> 1985 release of the IBM OS-2 operating system. Workstation for Ada programming Rational R1000. <br /> <br /> '''1986''' Collaboration of the National Center for the Study of Telecommunications (CNET) with NYU on the C version of Ada/Ed.<br /> <br /> '''1987''' ISO standard, revision in preparation for Ada 95. DEC microvax 3000. <br /> 1989 C language is standardized: ANSI C. <br /> 1990 Intermetrics is chosen for the Ada 9X revision <br /> <br /> '''1992''' DEC Alpha AXP processor. Minicomputers give way to microcomputers. DEC, not having taken the turn well, will disappear in 1998. <br /> <br /> '''1994''' November Ada 95 revision accepted. Now the transition out of Ada 83 begins, although compatible with Ada 83, Ada 95 is in many aspects,<br /> including object programming, a language with a very different flavor.</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_history&diff=173 2025-05-13T09:22:27Z

<p>Vmo: </p> <hr /> <div>

<br /> == Brief historical context ==<br /> <br /> In the history of the development of modern computing, there is a particular and rich period that extends from the early 1980s to the mid-1990s.<br /> This period corresponds to the appearance and maturation of personal computing (IBM PC in 1981, Apple Macintosh in 1984) and the birth of the<br /> Internet. <br /> <br /> The previous period, which could be situated in the 1970s, saw the beginning of microprocessor technology (Intel 4004 in 1971) which would lead<br /> to the gradual disappearance of large “mainframe” computers in favor of mini-computers and then micro-computers and compact personal<br /> workstations with increasing power. <br /> Computer programming languages ​​follow the evolution of increasingly capable hardware in terms of speed and memory, and one of them in<br /> particular, the Pascal language, which appeared in 1970, will exert a particular influence. <br /> Following Pascal, a reflection on the homogenization of software systems of the American Department of Defense (DoD) began in 1974 and led in<br /> 1983 to the definition of a highly advanced language: Ada, now known as Ada 83 to distinguish it from its evolutionary versions Ada 95 and later,<br /> 2005, 2012, 2022.<br /> 

<br /> == Ada 83 in its time ==<br /> <br /> Here is a timeline of salient events relating to the period that interests us (preparatory from 1970 to 1983, standardized life of the Ada 83<br /> language from 1983 to 1994).<br /> <br /> '''1971''' the Intel 4004 microprocessor is produced.<br /> <br /> '''1974''' independent proposals for a common language from the US defense services: US-ARMY, US-AIR FORCE, US-NAVY.<br /> <br /> '''1975''' Creation of the High Order Language Working Group (HOLWG), beginning of the Strawman language specifications, then Wooden man.<br /> <br /> '''1976''' (January) Tinman specifications, parallel evaluation of 23 existing languages. Derivatives of the Algol-68, Pascal, PL-1 languages ​​are<br /> recognized as possible bases.<br /> <br /> '''1977''' (January) Ironman specifications. <br /> (August) four competitors emerge among 15 proposals mainly based on Pascal: CII-Honeywell Bull, Intermetrics, Softech, SRI International.<br /> <br /> '''1978''' 2 competitors continue: Steelman specifications. Digital Equipment Corporation (DEC) releases the VAX 11/780 <br /> <br /> '''1979''' (April) The “Green” project led by Jean Ichbiah (CII-Honeywell team) is selected. In May the name of the language is chosen, it will be “Ada”, in<br /> homage to Augusta Ada Lovelace (1815-1852), daughter of the poet Byron and collaborator of Charles Babbage in his work on the “Analytical<br /> Machine”. New York University (NYU) with Robert Dewar examines the Ada specification and develops a partial executable model in SETL<br /> language. Launch of the Stoneman project for a programming environment for the common Ada language. Appearance of the Motorola 68000<br /> microprocessor. It will be discontinued in 1996, the succession being taken over by its successors 68010 to 68060. <br /> <br /> '''1980''' intermediate standard, NYU Ada/Ed is adapted. In December HOLWG becomes Ada Joint Program Office (AJPO). J. Ichbiah founds Alsys. <br /> 1981 IBM introduces the first PC. <br /> 1982 new Ada reference manual, adapted from NYU Ada/Ed1983 release of the ANSI-MIL-STD-1815 standard defining Ada 83, in April Ada/Ed is validated on the ACVC (Ada Compiler Validation Capability)<br /> tests. <br /> <br /> [[File:Diploma of first validated compiler.jpg|frame|alt=Presentation of diploma for first validated Ada compiler|Presentation of diploma for first validated Ada compiler to the Ada/Ed team, Robert Dewar (right) and Ed Schonberg (left)]]<br /> <br /> The C language becomes popular, between 1985 and 1992 Ada/Ed will be translated into C. <br /> <br /> '''1984''' Apple presents the Macintosh, DEC releases the Microvax I. The DEC Ada compiler is available. <br /> 1985 release of the IBM OS-2 operating system. Workstation for Ada programming Rational R1000. <br /> <br /> '''1986''' Collaboration of the National Center for the Study of Telecommunications (CNET) with NYU on the C version of Ada/Ed.<br /> <br /> '''1987''' ISO standard, revision in preparation for Ada 95. DEC microvax 3000. <br /> 1989 C language is standardized: ANSI C. <br /> 1990 Intermetrics is chosen for the Ada 9X revision <br /> <br /> '''1992''' DEC Alpha AXP processor. Minicomputers give way to microcomputers. DEC, not having taken the turn well, will disappear in 1998. <br /> <br /> '''1994''' November Ada 95 revision accepted. Now the transition out of Ada 83 begins, although compatible with Ada 83, Ada 95 is in many aspects,<br /> including object programming, a language with a very different flavor.</div>

Vmo https://ada83.org/wiki/index.php?title=Rational_R1000_Ada83_machine&diff=170 2025-05-12T09:13:20Z

<p>Vmo: </p> <hr /> <div>== DataMuseum.Dk revives a Rational R1000s400 ==<br /> <br /> The Rational R1000 was an Ada 83 machine. The Data Museum of Denmark had a hand on one of those machines in 2009 and succeeded in making it work again ! Some documentation about this enterprise is available here : [https://github.com/Datamuseum-DK/R1000.HwDoc R1000 Documentation]<br /> <br /> Last year they released an emulator which can be accessed through this link [https://datamuseum.dk/wiki/Rational/R1000s400 R1000s400 revival]</div>

Vmo https://ada83.org/wiki/index.php?title=Rational_R1000_Ada83_machine&diff=169 2025-05-12T09:12:46Z

<p>Vmo: Created page with &quot;== DataMuseum.Dk revives a Rational R1000s400 == The Rational R1000 was an Ada 83 machine. The Data Museum of Denmark had a hand on one one those machines and succeeded in making it work again ! Some documentation about this enterprise is available here : [https://github.com/Datamuseum-DK/R1000.HwDoc R1000 Documentation] Last year they released an emulator which can be accessed through this link [https://datamuseum.dk/wiki/Rational/R1000s400 R1000s400 revival]&quot;</p> <hr /> <div>== DataMuseum.Dk revives a Rational R1000s400 ==<br /> <br /> The Rational R1000 was an Ada 83 machine. The Data Museum of Denmark had a hand on one one those machines and succeeded in making it work again ! Some documentation about this enterprise is available here : [https://github.com/Datamuseum-DK/R1000.HwDoc R1000 Documentation]<br /> <br /> Last year they released an emulator which can be accessed through this link [https://datamuseum.dk/wiki/Rational/R1000s400 R1000s400 revival]</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=167 2025-04-29T19:54:32Z

<p>Vmo: /* The ENST theses and P.Kruchten / J.P.Rosen documents */</p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ :File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=166 2025-04-29T15:28:37Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|420px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> == '''Motivations''' ==<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is close to 170 paper sheets long (around 270 pages of language definition proper), which makes it integrally accessible to an individual reader.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> =='''Purpose'''==<br /> <br /> This site aims at gathering :<br /> <br /> * '''[[Ada_83_history|history]]''' facts<br /> * '''[[Ada_83_tools|tools]]'''<br /> * '''[[documentation]]'''<br /> * '''[[Ada_83_examples|examples]]''' written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> =='''Participate'''==<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=165 2025-04-29T15:28:17Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|450px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> == '''Motivations''' ==<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is close to 170 paper sheets long (around 270 pages of language definition proper), which makes it integrally accessible to an individual reader.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> =='''Purpose'''==<br /> <br /> This site aims at gathering :<br /> <br /> * '''[[Ada_83_history|history]]''' facts<br /> * '''[[Ada_83_tools|tools]]'''<br /> * '''[[documentation]]'''<br /> * '''[[Ada_83_examples|examples]]''' written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> =='''Participate'''==<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=164 2025-04-29T15:27:54Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|400px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> == '''Motivations''' ==<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is close to 170 paper sheets long (around 270 pages of language definition proper), which makes it integrally accessible to an individual reader.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> =='''Purpose'''==<br /> <br /> This site aims at gathering :<br /> <br /> * '''[[Ada_83_history|history]]''' facts<br /> * '''[[Ada_83_tools|tools]]'''<br /> * '''[[documentation]]'''<br /> * '''[[Ada_83_examples|examples]]''' written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> =='''Participate'''==<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=163 2025-04-29T13:02:39Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|500px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> == '''Motivations''' ==<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is close to 170 paper sheets long (around 270 pages of language definition proper), which makes it integrally accessible to an individual reader.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> =='''Purpose'''==<br /> <br /> This site aims at gathering :<br /> <br /> * '''[[Ada_83_history|history]]''' facts<br /> * '''[[Ada_83_tools|tools]]'''<br /> * '''[[documentation]]'''<br /> * '''[[Ada_83_examples|examples]]''' written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> =='''Participate'''==<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=162 2025-04-29T12:57:22Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|500px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> == '''Motivations''' ==<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is close to 170 paper sheets long (around 270 pages of language definition proper), which makes it integrally accessible to an individual reader.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> =='''Purpose'''==<br /> <br /> This site aims at gathering [[Ada_83_history|history]] facts and [[Ada_83_tools|tools]], [[documentation]] and [[Ada_83_examples|examples]] written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=161 2025-04-29T12:42:05Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|500px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is close to 170 paper sheets long (around 270 pages of language definition proper), which makes it integrally accessible to an individual reader.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> <br /> This site aims at gathering [[Ada_83_history|history]] facts and [[Ada_83_tools|tools]], [[documentation]] and [[Ada_83_examples|examples]] written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=160 2025-04-29T12:34:27Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|500px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is around 175 pages long, which makes it accessible to an individual.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> <br /> This site aims at gathering [[Ada_83_history|history]] facts and [[Ada_83_tools|tools]], [[documentation]] and [[Ada_83_examples|examples]] written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=J_Ichbiah_mail_20_nov_1992&diff=159 2025-04-29T12:28:57Z

<p>Vmo: </p> <hr /> <div>&lt;pre&gt;<br /> <br /> From comp.lang.ada Tue Apr 6 11:03:18 1993<br /> Newsgroups: comp.lang.ada<br /> Path: utcsri!newsflash.concordia.ca!uunet!world!srctran<br /> From: srctran@world.std.com (Gregory Aharonian)<br /> Subject: Ichbiah's letter to Anderson: Here it is<br /> Message-ID: &lt;SRCTRAN.93Apr6103639@world.std.com&gt;<br /> Sender: srctran@world.std.com (Gregory Aharonian)<br /> Organization: The World<br /> Distribution: comp.lang.ada<br /> Date: Tue, 6 Apr 1993 15:36:39 GMT<br /> Lines: 406<br /> <br /> By contacting Dr. Ichbiah, I have received permission to post his letter<br /> to Christine Anderson to comp.lang.ada. Here it is. While I can't comment<br /> on the technical aspects of his letter, from a marketing point of view, Ada9X<br /> sounds like a disaster. It may be a great, fantastic language that is under<br /> development, but if Dr. Ichbiah's concerns are even partially valid, than<br /> Ada9X will win even less market share than Ada83. Upward incompatibility,<br /> complexity of features, usurping of roles provided by third party packages,<br /> and stretched out timetables for approval, development and release of new<br /> compilers? This is every marketing manager's nightmare. And given Jean's<br /> involvement with a commercial product oriented company, I would give much<br /> signifigance to his market impact comments. Forget about windows of<br /> opportunity being shut. They will be shut, boarded up, and wired with<br /> explosives.<br /> <br /> By the way, does anyone know if the Ada9X effort has a marketing<br /> subcommittee, a group to look into how Ada is going to survive in the<br /> non-Mandated world. I would love to serve on such a committee, but have<br /> not noticed anything.<br /> <br /> Greg Aharonian<br /> Source Translation &amp; Optimization<br /> ==============================================================================<br /> <br /> <br /> <br /> ~Subject: A Farewell to Ada with null<br /> ~Date: Fri, 20 Nov 92 00:51:25 EST<br /> ~From: Jean D Ichbiah &lt;ichbiah@ajpo.sei.cmu.edu&gt;<br /> <br /> ~From: Jean D Ichbiah<br /> To: Chris Anderson<br /> cc: DRs, VRs, Iso [other Adaphiles]<br /> <br /> ~subject: A Farewell to Ada with null<br /> <br /> <br /> Dear Chris,<br /> <br /> For now almost one year, I have tried very hard to work for the<br /> simplification of Ada 9X.<br /> <br /> &gt;From the start, I have been very worried by the massive complexity of the<br /> 9X proposals. As you certainly remember, this is a concern that I have<br /> expressed to you in earlier correspondance: I was concerned that the<br /> resulting complexity would lose some users as well as some implementers.<br /> I was also seeing a risk that the Ada community would not follow if the<br /> intellectual &quot;distance&quot; and the upward incompatibility were too high.<br /> <br /> At the same time I was intrigued by the quality of the individual features<br /> that were proposed - you indeed selected one of the best feature designers<br /> and it is unclear that, on a feature-by-feature basis, better could have<br /> been accomplished. And I was hoping that the DRs and Iso processes would<br /> bring a reduction to an acceptable size, to something that is intellectually<br /> manageable. I was also hoping that it would be ultimately possible to dress<br /> the new concepts in a simpler, more regular, more attractive, more beautiful<br /> syntax, which could redeem some of the complexity. And it is fair to say<br /> that I was encouraged in that hope by a very favorable mail response on the<br /> network.<br /> <br /> It is now time for me to acknowledge that my efforts have failed.<br /> <br /> Unfortunately, I have encountered an unusual degree of intolerance to<br /> outside contributions which meant that more time was spent fighting my<br /> attempts to improve than analyzing their merits. This was clearly becoming<br /> counterproductive and at the Iso meeting in Salem, my attempts to simplify,<br /> supported by 2 and opposed by 2, ultimately lost to 6 courageous abstentions.<br /> This happened according to the rules and the outcome is not one that can be<br /> disputed.<br /> <br /> Nevertheless, I do not like the current proposal. (Of course, in all<br /> fairness, I will withhold final judgment until the proposal is final - my<br /> inveterate, irrational optimism again.) More than most people, I am driven<br /> by aesthetic considerations and the strong belief that only beautiful shape<br /> can be correct shape. And for me, a striking symbol of the lack of<br /> aesthetic considerations in the new proposals are contained in the construct<br /> <br /> with null<br /> <br /> coldly logic, ultimately ugly - the engineers had it their way and had Ada<br /> 9X become Ada with null.<br /> <br /> Alltogether, my impression of the present proposal reminds me of my awe when<br /> first crossing this bridge in Boston: the Mystic River Bridge. It certainly<br /> met the requirements but the accumulation and clutter of metal was<br /> oppressive and threatening and ... my preference will always go to the<br /> Golden Gate Bridge. The first had engineered features, the second had an<br /> Architect and a prodigious Architecture with charm.<br /> <br /> But my discomfort with the course in which 9X appears to be irreparably<br /> engaged goes well beyond the aesthetics. I will review the main ones in what<br /> follows.<br /> <br /> THE EXPLOSION OF COMPLEXITY<br /> <br /> A massive increase in complexity, will result from 9X adding one or more<br /> additional possibilities where Ada now offers two. For example, 9X adds:<br /> <br /> * root types, to types and universal types<br /> <br /> * aliased, to constant and variable<br /> <br /> * inherently limited, to limited and not limited<br /> <br /> * protected types, to subprograms, packages, and tasks<br /> <br /> * decimal and unsigned types, to integer and real types<br /> <br /> * access parameters, to in, out, and in out<br /> <br /> * accessibility and dynamic accessibility, to scope and visibility<br /> <br /> * accessibility checks, to constraint checks<br /> <br /> * tagged types, to normal types<br /> <br /> * dispatched subprogram calls, to normal subprogram calls<br /> <br /> * use type clause, to use package clauses<br /> <br /> * barriers, to conditions ...<br /> <br /> Now, if 10 of these interact and with an average 2 possibilities in each<br /> case, we roughly have 1000 possible interactions in current Ada (that is,<br /> 2**10). But with 9X, the number of interactions to consider is close to<br /> 60,000 since we have 3 or more possibilities in each case (that is, 3**10).<br /> As you see, it is very legitimate to talk of an EXPLOSION in complexity if<br /> it has been multiplied by 60! Some will argue that an interaction on 10<br /> planes is unusual. But even with 5 planes, we get a very significant<br /> increase by a factor of 8 (since 2**5 is 32, and 3**5 is 243).<br /> <br /> Clearly, some of the above extensions are desirable. But taken altogether<br /> they result in an undesirable complexity.<br /> <br /> EXTRA COMPLEXITY IS OBJECTIONABLE<br /> <br /> Extra complexity, to this degree, is very objectionable for implementers and<br /> the Ada industry. <br /> <br /> On one hand, it will delay and significantly increase the effort of building<br /> compilers, with the risk that some vendors will drop out of the market.<br /> (I understand that you intend to relax the validation requirements in the<br /> short term. But this abandon of the no-subset rule will have Ada lose one <br /> of its major advantages over competing languages: the high degree of<br /> compatibility between implementations.) For the surviving vendors, the<br /> scale of changes is likely to set them back by several years in terms of<br /> reliability and performance of implementations. (Whatever comfort would<br /> come from the prototype implementations is illusory. They are test-tube<br /> experiments that have concentrated on certain facets; they have not been<br /> able to test the interactions of features.)<br /> <br /> Moreover, the additional effort required by this complexity will compete for<br /> resources and thereby prevent the Ada Industry from investing sufficiently<br /> in interfaces. I have said it several times before, but it is worth<br /> repeating: I consider the lack of interfaces to be the most severe<br /> impediment to increasing usage of Ada - witness the absence of a credible<br /> Ada solution for Windows development - and this diversion of resources from<br /> interfaces severely diminishes the chances for Ada's long term success.<br /> <br /> The extra complexity is equally objectionable from a user's point of view.<br /> <br /> Ada has provided so far an attractive base for software engineering and for<br /> the development of large reliable programs. Ada struck at the right level:<br /> more complex than Pascal - since it offered facilities that the users needed<br /> - - but not as complex as C++. So it meant that average programmers could<br /> develop a level of command of its concepts with which they could develop<br /> programs whose structure, actions, and consequences they understood and<br /> mastered - an absolute requirement for reliability.<br /> <br /> But this simplicity does not appear to be preserved with the 9X current<br /> proposals, whose complexity are likely to be beyond that of C++. And if we<br /> were to lose the simplicity advantage over C++, what would remain of the<br /> advantages of Ada?<br /> <br /> Finally, the extra complexity is very objectionable because the resulting<br /> delays severely endanger the chances of positioning Ada in the main stream<br /> of object-oriented programming. We run the risk of missing the window of<br /> opportunity.<br /> <br /> THE ILS APPROACH AND MORE DELAYS<br /> <br /> The current approach taken for specifying the language is based on the<br /> so-called ILS (the Integrated Language Specification). The sheer size of the<br /> document should be a severe warning about the complexity of the current<br /> proposals: It is larger than the Ada Reference Manual although it purports<br /> to describe the changes with respect to this former manual.<br /> <br /> But the most striking aspect of the ILS (beyond the size) is the<br /> uncontrolled proliferation of new jargon, replacing or adding a large number<br /> of new technical terms. The developers of the ILS have argued that this is<br /> a temporary document whose purpose is to specify the changes and that their<br /> intent is to develop a Revised Reference Manual in the style that has been<br /> so successful for Ada (83).<br /> <br /> On one hand, the level of details covered in the ILS have certainly helped<br /> in revealing the interactions of the new features and, thereby, their<br /> complexity.<br /> <br /> However, the approach is unlikely to work: In refining the language<br /> proposals, the small local decisions are going to be very influenced by the<br /> terms that are used. The words we use influence the concepts: they often<br /> dictate technical choices that keep the description simple and<br /> understandable. This has been my experience with the formulation of the<br /> Green manual, and that of the Ada 80, and Ada 83 reference manuals. The ILS<br /> approach tries to postpone the difficulty but it will mean that these local<br /> trade-offs will be done in terms of the ILS jargon and will have to be<br /> redone when you scale down the terminology to the style of the final<br /> reference manual.<br /> <br /> As this will take a lot of time, the temptation will be to have the<br /> standard be an ILS-style document. If this were to happen, Ada would lose<br /> another of its key advantages - that of having a standard that is readable<br /> by most programmers, to the degree that compilers formulate error messages<br /> in terms of sections of the reference manual. This approach would also lose<br /> the &quot;intellectual capital&quot; invested by the Ada community in the<br /> understanding of the Ada definition.<br /> <br /> &gt;From where we are now, I regard the current goal of having a draft reference<br /> manual in June 1993 as unrealistic by at least six to nine months. (Unlike<br /> Cassandra, I speak here with experience. Like Cassandra, however, I may<br /> share the dual attributes of being right and not believed.) The ILS<br /> approach is actually postponing the moment where the team will be in a<br /> position to understand the complexity of what they are trying to do, as well<br /> as the complexity of describing their proposals. So it is postponing the<br /> time when they will be able to give a reasonable estimate of completion<br /> time.<br /> <br /> UPWARD INCOMPATIBILITY<br /> <br /> I am also worried at the growing level of upward incompatibility of 9X with<br /> Ada. As a measure of this growing divergence, the list published in the<br /> November 92 issue of Ada letters contained 12 categories of upward<br /> incompatibilities. A more recent list, compiled from the ILS now counts<br /> some 30 different categories (and this is not just a different<br /> categorization). While a small number of them are language improvements<br /> (for example, the better enforcement of a contract model for generic units)<br /> many of them reflect an attitude that is too tolerant of upward<br /> incompatibility (for example, the elimination of accuracy constraints in<br /> subtypes and that of named notation for operators).<br /> <br /> Upward compatibility shoud be addressed much more strictly. Success of 9X<br /> will not happen unless it is a superset of current Ada: Existing compilers<br /> will have to be maintained for their current applications and the resources<br /> do not exist to maintain two separate families of compilers. Moreover, very<br /> strict upward compatibility is a prerequisite for the strategy of gradual<br /> introduction of 9X features in existing Ada compilers.<br /> <br /> WHAT WAS AND IS NEEDED<br /> <br /> What we have seen is a reflection of the inherent inability of committees to<br /> make choices. In this respect, it should be no surprise that the decision<br /> process has led to this overweight since historical precedent of efforts to<br /> achieve similar consensus have had similar results for other languages<br /> (PL/I ...). Moreover, we have had to face the unusual situation of a team<br /> who has been pushing for always more features. The combination has produced<br /> the current inflation.<br /> <br /> With the 9X revision process, we were considering a language revision, as<br /> opposed to the design of an entirely new language. It seemed therefore, that<br /> the rules implied that improvements had to be sought within the frame of the<br /> existing language and with a certain modesty that did not exclude an<br /> occasional &quot;cadenza&quot; for the revision team. <br /> <br /> In this spirit, the key decision was the choice of ONE major area where the<br /> revision would decide to concentrate efforts to extend current Ada. The rest<br /> being a collection of smaller scale - and nevertheless important - decisions<br /> such as the international character set and various local improvements<br /> (aggregates, preferences, ...).<br /> <br /> Along with many others, I have argued that this area of focus should be the<br /> Object-Oriented Programming features (including the ability to pass<br /> subprograms as parameters). The semantics developed for these features is<br /> indeed quite attractive (even if the syntax badly needs improvement).<br /> The priority for OOP comes from a real market requirement - these features<br /> will attract new users to Ada - and also from the ability to reuse the<br /> significant work that was done in libraries of classes for C++ and Turbo<br /> Pascal. So it is part of the effort to interface Ada with the outside world<br /> and to reuse software and methods that are developed outside Ada.<br /> <br /> If we limited the revision to this level, we could certainly have something<br /> rather elegant, well in the spirit of Ada, which could be ready within the<br /> original schedule, and for which implementations could be achieved rapidly<br /> and in an upward compatible manner.<br /> <br /> The current trouble comes from having tried to achieve consensus by<br /> satisfying all user communities and - in part - this is what has led to the<br /> proposed plethora of new features and the ensuing complexity. I have argued<br /> in other places that, since we had to choose, we had to be more modest in<br /> the area of real-time, perhaps addressing only improvements in the area of<br /> priority handling. <br /> <br /> The logic behind this choice is that we are dealing with a community that is<br /> already using Ada for moderately time-critical applications. When they are<br /> not using Ada tasking, they are working with some set of packaged real-time<br /> primitives: Cifo, Extra, Posix, or some other proprietary kernel. At the<br /> other end of the spectrum, for extremely time-critical applications, they<br /> are working with packages of even lower-level primitives.<br /> <br /> In most cases, these packaged solutions were adopted because it was<br /> considered that they offered the best combination of advantages: the Ada<br /> modularity and reliability, and the real-time primitives offered by the<br /> package. Moreover, when outside interfacing reasons dictate the choice of<br /> primitives, such as Posix, nothing that we do in Ada is likely to change the<br /> approach. Given the level of consensus achieved for these packaged<br /> approaches in their respective areas, and given the need fore interfacing<br /> with other languages, it is very unlikely that the corresponding user<br /> communities would switch to a different approach - even if they found new<br /> Ada features to meet their requirements. Consequently, the Ada industry<br /> will have to provide support for these packaged approaches regardless of<br /> what is done by the language revision.<br /> <br /> Moreover, the choice of Ada over some competing language such as C or C++<br /> is not going to depend on the presence of tasking features since these<br /> competing alternatives do not have any. On the contrary, the presence in<br /> 9X of features that they do not use could be an argument for not using the<br /> language as people fear the distributed inefficiencies that are commonplace<br /> for implementation of new languages (and with the level of change presently<br /> contemplated, 9X would be a new language to which the fine-tuning that took<br /> place for Ada in the past ten years would not apply).<br /> <br /> So the above considerations show that any effort that we expend on real-time<br /> features has a low return on investment as far as attracting users to Ada.<br /> Hence this is an obvious area for substantial reduction.<br /> <br /> Others depend more on containing the team's natural inclination to add more<br /> features. I will limit myself to two significant examples.<br /> <br /> The first feature is the introduction of discriminant for classes. This is<br /> something that exists in no other language that has OOP features, and<br /> apparently for good reasons when we see the complexity that the interaction<br /> of classes and discriminants has induced in 9X. Besides complexity, the<br /> other reason why other languages have avoided discriminants for classes is<br /> that they are not that useful for the dynamic style of programming that is<br /> customary for the applications contemplated. Discriminants serve for static<br /> parameterization, but the style of programming used for, say windows<br /> applications, liberally uses dynamic creation and quite justifyably so when<br /> you consider the decreasing costs of processors. So this is the domain of<br /> late binding, of dynamic dispatching, and if you need to have a string, you<br /> naturally allocate it dynamically (where a static view would have used<br /> discriminants). So the inability to sort out objectives, and to choose,<br /> results in significant complexity without real gain.<br /> <br /> The second example is in the area of separate compilation. Early Ada<br /> compilers were slow and the need to optimize compilations was very acute.<br /> Fortunately, you can now compile well over 100,000 lines in an hour on a<br /> very low cost machine (a 486) so that this is now a problem of the past.<br /> But this problem of the past has resulted in the 9X feature of hierarchical<br /> libraries.<br /> <br /> I will argue that this is again unneeded complexity. First, we have to<br /> recognize that current Ada already goes much beyond other languages for<br /> separate compilation of interfaces. Other languages such as Turbo Pascal<br /> for Windows do allow a form of package - the Pascal units - but the<br /> interface and the body are one single text. So you would expect Turbo<br /> Pascal compilation to be slow ... except that the compiler is smart enough<br /> to distinguish changes to the interface from changes to the implementation.<br /> This shows the path: if you still think that the kind of compilation<br /> optimization that motivates hierarchical libraries is relevant, you can<br /> achieve it by a more sophisticated compiler without need to increase the<br /> size of the language. The feature may be well-designed, but it is<br /> nevertheless dead weight. In addition, it has been shown to undermine one<br /> of the most valuable conceptual assets of Ada: the safety of packages (with<br /> unwanted self-proclaimed children getting access to the private part).<br /> <br /> The fact that a feature is well designed does not mean that it has to be<br /> part of the language: designing the architecture of a programming language<br /> is about choice and responsible choice is always &quot;either/or&quot;, rarely &quot;all<br /> of&quot;. Failing to choose will mean more to learn, more to implement, less<br /> efficiency, and less chances for Ada to succeed.<br /> <br /> CONCLUSION<br /> <br /> I have certainly hesitated before sending this open letter. Some very good<br /> friends have expressed concerns about possible negative impact on Ada.<br /> Clearly, my present assessment of the situation is quite different and<br /> I think that the 9X program requires a very substantial reorientation to<br /> succeed: I see more risk in continuing in the present course than in<br /> attempting a courageous reorientation.<br /> <br /> Others who share my concerns have reacted on the assumption that, anyway,<br /> it is too late. My hope is that this is not the case, and my belief is that<br /> the current plans and schedules are unrealistic to the degree that a<br /> reorientation is the only way to achieve something in a reasonable time.<br /> In 1981, Larry Druffel sponsored a parallel group - Emilion - to study an<br /> alternative. This could be an example to follow.<br /> <br /> In acknowledgment of the fact that it has not been possible for me to make<br /> an effective contribution, and also in view of my reluctance to be<br /> associated with something whose complexity I disapprove and whose aesthetics<br /> I can neither see nor share, I will no longer participate to Distinguished<br /> Reviewers meetings and would like my name to be removed from the list. <br /> I will see if I can be more effective from outside the group (for that matter,<br /> I would like to be on the list of Volunteer Reviewers).<br /> <br /> I was looking forward to be one of those promoting 9X but this does not<br /> appear to be possible at the present time.<br /> <br /> Sincerely,<br /> <br /> <br /> <br /> Jean D. Ichbiah<br /> Architect of the Ada Language<br /> <br /> <br /> -- <br /> **************************************************************************<br /> Greg Aharonian<br /> Source Translation &amp; Optimiztion<br /> P.O. Box 404, Belmont, MA 02178<br /> <br /> &lt;/pre&gt;</div>

Vmo https://ada83.org/wiki/index.php?title=J_Ichbiah_mail_20_nov_1992&diff=158 2025-04-29T12:28:06Z

<p>Vmo: Created page with &quot;&lt;nowiki&gt; From comp.lang.ada Tue Apr 6 11:03:18 1993 Newsgroups: comp.lang.ada Path: utcsri!newsflash.concordia.ca!uunet!world!srctran From: srctran@world.std.com (Gregory Aharonian) Subject: Ichbiah&#039;s letter to Anderson: Here it is Message-ID: &lt;SRCTRAN.93Apr6103639@world.std.com&gt; Sender: srctran@world.std.com (Gregory Aharonian) Organization: The World Distribution: comp.lang.ada Date: Tue, 6 Apr 1993 15:36:39 GMT Lines: 406 By contacting Dr. Ichbiah, I have recei...&quot;</p> <hr /> <div>&lt;nowiki&gt;<br /> <br /> From comp.lang.ada Tue Apr 6 11:03:18 1993<br /> Newsgroups: comp.lang.ada<br /> Path: utcsri!newsflash.concordia.ca!uunet!world!srctran<br /> From: srctran@world.std.com (Gregory Aharonian)<br /> Subject: Ichbiah's letter to Anderson: Here it is<br /> Message-ID: &lt;SRCTRAN.93Apr6103639@world.std.com&gt;<br /> Sender: srctran@world.std.com (Gregory Aharonian)<br /> Organization: The World<br /> Distribution: comp.lang.ada<br /> Date: Tue, 6 Apr 1993 15:36:39 GMT<br /> Lines: 406<br /> <br /> By contacting Dr. Ichbiah, I have received permission to post his letter<br /> to Christine Anderson to comp.lang.ada. Here it is. While I can't comment<br /> on the technical aspects of his letter, from a marketing point of view, Ada9X<br /> sounds like a disaster. It may be a great, fantastic language that is under<br /> development, but if Dr. Ichbiah's concerns are even partially valid, than<br /> Ada9X will win even less market share than Ada83. Upward incompatibility,<br /> complexity of features, usurping of roles provided by third party packages,<br /> and stretched out timetables for approval, development and release of new<br /> compilers? This is every marketing manager's nightmare. And given Jean's<br /> involvement with a commercial product oriented company, I would give much<br /> signifigance to his market impact comments. Forget about windows of<br /> opportunity being shut. They will be shut, boarded up, and wired with<br /> explosives.<br /> <br /> By the way, does anyone know if the Ada9X effort has a marketing<br /> subcommittee, a group to look into how Ada is going to survive in the<br /> non-Mandated world. I would love to serve on such a committee, but have<br /> not noticed anything.<br /> <br /> Greg Aharonian<br /> Source Translation &amp; Optimization<br /> ==============================================================================<br /> <br /> <br /> <br /> ~Subject: A Farewell to Ada with null<br /> ~Date: Fri, 20 Nov 92 00:51:25 EST<br /> ~From: Jean D Ichbiah &lt;ichbiah@ajpo.sei.cmu.edu&gt;<br /> <br /> ~From: Jean D Ichbiah<br /> To: Chris Anderson<br /> cc: DRs, VRs, Iso [other Adaphiles]<br /> <br /> ~subject: A Farewell to Ada with null<br /> <br /> <br /> Dear Chris,<br /> <br /> For now almost one year, I have tried very hard to work for the<br /> simplification of Ada 9X.<br /> <br /> &gt;From the start, I have been very worried by the massive complexity of the<br /> 9X proposals. As you certainly remember, this is a concern that I have<br /> expressed to you in earlier correspondance: I was concerned that the<br /> resulting complexity would lose some users as well as some implementers.<br /> I was also seeing a risk that the Ada community would not follow if the<br /> intellectual &quot;distance&quot; and the upward incompatibility were too high.<br /> <br /> At the same time I was intrigued by the quality of the individual features<br /> that were proposed - you indeed selected one of the best feature designers<br /> and it is unclear that, on a feature-by-feature basis, better could have<br /> been accomplished. And I was hoping that the DRs and Iso processes would<br /> bring a reduction to an acceptable size, to something that is intellectually<br /> manageable. I was also hoping that it would be ultimately possible to dress<br /> the new concepts in a simpler, more regular, more attractive, more beautiful<br /> syntax, which could redeem some of the complexity. And it is fair to say<br /> that I was encouraged in that hope by a very favorable mail response on the<br /> network.<br /> <br /> It is now time for me to acknowledge that my efforts have failed.<br /> <br /> Unfortunately, I have encountered an unusual degree of intolerance to<br /> outside contributions which meant that more time was spent fighting my<br /> attempts to improve than analyzing their merits. This was clearly becoming<br /> counterproductive and at the Iso meeting in Salem, my attempts to simplify,<br /> supported by 2 and opposed by 2, ultimately lost to 6 courageous abstentions.<br /> This happened according to the rules and the outcome is not one that can be<br /> disputed.<br /> <br /> Nevertheless, I do not like the current proposal. (Of course, in all<br /> fairness, I will withhold final judgment until the proposal is final - my<br /> inveterate, irrational optimism again.) More than most people, I am driven<br /> by aesthetic considerations and the strong belief that only beautiful shape<br /> can be correct shape. And for me, a striking symbol of the lack of<br /> aesthetic considerations in the new proposals are contained in the construct<br /> <br /> with null<br /> <br /> coldly logic, ultimately ugly - the engineers had it their way and had Ada<br /> 9X become Ada with null.<br /> <br /> Alltogether, my impression of the present proposal reminds me of my awe when<br /> first crossing this bridge in Boston: the Mystic River Bridge. It certainly<br /> met the requirements but the accumulation and clutter of metal was<br /> oppressive and threatening and ... my preference will always go to the<br /> Golden Gate Bridge. The first had engineered features, the second had an<br /> Architect and a prodigious Architecture with charm.<br /> <br /> But my discomfort with the course in which 9X appears to be irreparably<br /> engaged goes well beyond the aesthetics. I will review the main ones in what<br /> follows.<br /> <br /> THE EXPLOSION OF COMPLEXITY<br /> <br /> A massive increase in complexity, will result from 9X adding one or more<br /> additional possibilities where Ada now offers two. For example, 9X adds:<br /> <br /> * root types, to types and universal types<br /> <br /> * aliased, to constant and variable<br /> <br /> * inherently limited, to limited and not limited<br /> <br /> * protected types, to subprograms, packages, and tasks<br /> <br /> * decimal and unsigned types, to integer and real types<br /> <br /> * access parameters, to in, out, and in out<br /> <br /> * accessibility and dynamic accessibility, to scope and visibility<br /> <br /> * accessibility checks, to constraint checks<br /> <br /> * tagged types, to normal types<br /> <br /> * dispatched subprogram calls, to normal subprogram calls<br /> <br /> * use type clause, to use package clauses<br /> <br /> * barriers, to conditions ...<br /> <br /> Now, if 10 of these interact and with an average 2 possibilities in each<br /> case, we roughly have 1000 possible interactions in current Ada (that is,<br /> 2**10). But with 9X, the number of interactions to consider is close to<br /> 60,000 since we have 3 or more possibilities in each case (that is, 3**10).<br /> As you see, it is very legitimate to talk of an EXPLOSION in complexity if<br /> it has been multiplied by 60! Some will argue that an interaction on 10<br /> planes is unusual. But even with 5 planes, we get a very significant<br /> increase by a factor of 8 (since 2**5 is 32, and 3**5 is 243).<br /> <br /> Clearly, some of the above extensions are desirable. But taken altogether<br /> they result in an undesirable complexity.<br /> <br /> EXTRA COMPLEXITY IS OBJECTIONABLE<br /> <br /> Extra complexity, to this degree, is very objectionable for implementers and<br /> the Ada industry. <br /> <br /> On one hand, it will delay and significantly increase the effort of building<br /> compilers, with the risk that some vendors will drop out of the market.<br /> (I understand that you intend to relax the validation requirements in the<br /> short term. But this abandon of the no-subset rule will have Ada lose one <br /> of its major advantages over competing languages: the high degree of<br /> compatibility between implementations.) For the surviving vendors, the<br /> scale of changes is likely to set them back by several years in terms of<br /> reliability and performance of implementations. (Whatever comfort would<br /> come from the prototype implementations is illusory. They are test-tube<br /> experiments that have concentrated on certain facets; they have not been<br /> able to test the interactions of features.)<br /> <br /> Moreover, the additional effort required by this complexity will compete for<br /> resources and thereby prevent the Ada Industry from investing sufficiently<br /> in interfaces. I have said it several times before, but it is worth<br /> repeating: I consider the lack of interfaces to be the most severe<br /> impediment to increasing usage of Ada - witness the absence of a credible<br /> Ada solution for Windows development - and this diversion of resources from<br /> interfaces severely diminishes the chances for Ada's long term success.<br /> <br /> The extra complexity is equally objectionable from a user's point of view.<br /> <br /> Ada has provided so far an attractive base for software engineering and for<br /> the development of large reliable programs. Ada struck at the right level:<br /> more complex than Pascal - since it offered facilities that the users needed<br /> - - but not as complex as C++. So it meant that average programmers could<br /> develop a level of command of its concepts with which they could develop<br /> programs whose structure, actions, and consequences they understood and<br /> mastered - an absolute requirement for reliability.<br /> <br /> But this simplicity does not appear to be preserved with the 9X current<br /> proposals, whose complexity are likely to be beyond that of C++. And if we<br /> were to lose the simplicity advantage over C++, what would remain of the<br /> advantages of Ada?<br /> <br /> Finally, the extra complexity is very objectionable because the resulting<br /> delays severely endanger the chances of positioning Ada in the main stream<br /> of object-oriented programming. We run the risk of missing the window of<br /> opportunity.<br /> <br /> THE ILS APPROACH AND MORE DELAYS<br /> <br /> The current approach taken for specifying the language is based on the<br /> so-called ILS (the Integrated Language Specification). The sheer size of the<br /> document should be a severe warning about the complexity of the current<br /> proposals: It is larger than the Ada Reference Manual although it purports<br /> to describe the changes with respect to this former manual.<br /> <br /> But the most striking aspect of the ILS (beyond the size) is the<br /> uncontrolled proliferation of new jargon, replacing or adding a large number<br /> of new technical terms. The developers of the ILS have argued that this is<br /> a temporary document whose purpose is to specify the changes and that their<br /> intent is to develop a Revised Reference Manual in the style that has been<br /> so successful for Ada (83).<br /> <br /> On one hand, the level of details covered in the ILS have certainly helped<br /> in revealing the interactions of the new features and, thereby, their<br /> complexity.<br /> <br /> However, the approach is unlikely to work: In refining the language<br /> proposals, the small local decisions are going to be very influenced by the<br /> terms that are used. The words we use influence the concepts: they often<br /> dictate technical choices that keep the description simple and<br /> understandable. This has been my experience with the formulation of the<br /> Green manual, and that of the Ada 80, and Ada 83 reference manuals. The ILS<br /> approach tries to postpone the difficulty but it will mean that these local<br /> trade-offs will be done in terms of the ILS jargon and will have to be<br /> redone when you scale down the terminology to the style of the final<br /> reference manual.<br /> <br /> As this will take a lot of time, the temptation will be to have the<br /> standard be an ILS-style document. If this were to happen, Ada would lose<br /> another of its key advantages - that of having a standard that is readable<br /> by most programmers, to the degree that compilers formulate error messages<br /> in terms of sections of the reference manual. This approach would also lose<br /> the &quot;intellectual capital&quot; invested by the Ada community in the<br /> understanding of the Ada definition.<br /> <br /> &gt;From where we are now, I regard the current goal of having a draft reference<br /> manual in June 1993 as unrealistic by at least six to nine months. (Unlike<br /> Cassandra, I speak here with experience. Like Cassandra, however, I may<br /> share the dual attributes of being right and not believed.) The ILS<br /> approach is actually postponing the moment where the team will be in a<br /> position to understand the complexity of what they are trying to do, as well<br /> as the complexity of describing their proposals. So it is postponing the<br /> time when they will be able to give a reasonable estimate of completion<br /> time.<br /> <br /> UPWARD INCOMPATIBILITY<br /> <br /> I am also worried at the growing level of upward incompatibility of 9X with<br /> Ada. As a measure of this growing divergence, the list published in the<br /> November 92 issue of Ada letters contained 12 categories of upward<br /> incompatibilities. A more recent list, compiled from the ILS now counts<br /> some 30 different categories (and this is not just a different<br /> categorization). While a small number of them are language improvements<br /> (for example, the better enforcement of a contract model for generic units)<br /> many of them reflect an attitude that is too tolerant of upward<br /> incompatibility (for example, the elimination of accuracy constraints in<br /> subtypes and that of named notation for operators).<br /> <br /> Upward compatibility shoud be addressed much more strictly. Success of 9X<br /> will not happen unless it is a superset of current Ada: Existing compilers<br /> will have to be maintained for their current applications and the resources<br /> do not exist to maintain two separate families of compilers. Moreover, very<br /> strict upward compatibility is a prerequisite for the strategy of gradual<br /> introduction of 9X features in existing Ada compilers.<br /> <br /> WHAT WAS AND IS NEEDED<br /> <br /> What we have seen is a reflection of the inherent inability of committees to<br /> make choices. In this respect, it should be no surprise that the decision<br /> process has led to this overweight since historical precedent of efforts to<br /> achieve similar consensus have had similar results for other languages<br /> (PL/I ...). Moreover, we have had to face the unusual situation of a team<br /> who has been pushing for always more features. The combination has produced<br /> the current inflation.<br /> <br /> With the 9X revision process, we were considering a language revision, as<br /> opposed to the design of an entirely new language. It seemed therefore, that<br /> the rules implied that improvements had to be sought within the frame of the<br /> existing language and with a certain modesty that did not exclude an<br /> occasional &quot;cadenza&quot; for the revision team. <br /> <br /> In this spirit, the key decision was the choice of ONE major area where the<br /> revision would decide to concentrate efforts to extend current Ada. The rest<br /> being a collection of smaller scale - and nevertheless important - decisions<br /> such as the international character set and various local improvements<br /> (aggregates, preferences, ...).<br /> <br /> Along with many others, I have argued that this area of focus should be the<br /> Object-Oriented Programming features (including the ability to pass<br /> subprograms as parameters). The semantics developed for these features is<br /> indeed quite attractive (even if the syntax badly needs improvement).<br /> The priority for OOP comes from a real market requirement - these features<br /> will attract new users to Ada - and also from the ability to reuse the<br /> significant work that was done in libraries of classes for C++ and Turbo<br /> Pascal. So it is part of the effort to interface Ada with the outside world<br /> and to reuse software and methods that are developed outside Ada.<br /> <br /> If we limited the revision to this level, we could certainly have something<br /> rather elegant, well in the spirit of Ada, which could be ready within the<br /> original schedule, and for which implementations could be achieved rapidly<br /> and in an upward compatible manner.<br /> <br /> The current trouble comes from having tried to achieve consensus by<br /> satisfying all user communities and - in part - this is what has led to the<br /> proposed plethora of new features and the ensuing complexity. I have argued<br /> in other places that, since we had to choose, we had to be more modest in<br /> the area of real-time, perhaps addressing only improvements in the area of<br /> priority handling. <br /> <br /> The logic behind this choice is that we are dealing with a community that is<br /> already using Ada for moderately time-critical applications. When they are<br /> not using Ada tasking, they are working with some set of packaged real-time<br /> primitives: Cifo, Extra, Posix, or some other proprietary kernel. At the<br /> other end of the spectrum, for extremely time-critical applications, they<br /> are working with packages of even lower-level primitives.<br /> <br /> In most cases, these packaged solutions were adopted because it was<br /> considered that they offered the best combination of advantages: the Ada<br /> modularity and reliability, and the real-time primitives offered by the<br /> package. Moreover, when outside interfacing reasons dictate the choice of<br /> primitives, such as Posix, nothing that we do in Ada is likely to change the<br /> approach. Given the level of consensus achieved for these packaged<br /> approaches in their respective areas, and given the need fore interfacing<br /> with other languages, it is very unlikely that the corresponding user<br /> communities would switch to a different approach - even if they found new<br /> Ada features to meet their requirements. Consequently, the Ada industry<br /> will have to provide support for these packaged approaches regardless of<br /> what is done by the language revision.<br /> <br /> Moreover, the choice of Ada over some competing language such as C or C++<br /> is not going to depend on the presence of tasking features since these<br /> competing alternatives do not have any. On the contrary, the presence in<br /> 9X of features that they do not use could be an argument for not using the<br /> language as people fear the distributed inefficiencies that are commonplace<br /> for implementation of new languages (and with the level of change presently<br /> contemplated, 9X would be a new language to which the fine-tuning that took<br /> place for Ada in the past ten years would not apply).<br /> <br /> So the above considerations show that any effort that we expend on real-time<br /> features has a low return on investment as far as attracting users to Ada.<br /> Hence this is an obvious area for substantial reduction.<br /> <br /> Others depend more on containing the team's natural inclination to add more<br /> features. I will limit myself to two significant examples.<br /> <br /> The first feature is the introduction of discriminant for classes. This is<br /> something that exists in no other language that has OOP features, and<br /> apparently for good reasons when we see the complexity that the interaction<br /> of classes and discriminants has induced in 9X. Besides complexity, the<br /> other reason why other languages have avoided discriminants for classes is<br /> that they are not that useful for the dynamic style of programming that is<br /> customary for the applications contemplated. Discriminants serve for static<br /> parameterization, but the style of programming used for, say windows<br /> applications, liberally uses dynamic creation and quite justifyably so when<br /> you consider the decreasing costs of processors. So this is the domain of<br /> late binding, of dynamic dispatching, and if you need to have a string, you<br /> naturally allocate it dynamically (where a static view would have used<br /> discriminants). So the inability to sort out objectives, and to choose,<br /> results in significant complexity without real gain.<br /> <br /> The second example is in the area of separate compilation. Early Ada<br /> compilers were slow and the need to optimize compilations was very acute.<br /> Fortunately, you can now compile well over 100,000 lines in an hour on a<br /> very low cost machine (a 486) so that this is now a problem of the past.<br /> But this problem of the past has resulted in the 9X feature of hierarchical<br /> libraries.<br /> <br /> I will argue that this is again unneeded complexity. First, we have to<br /> recognize that current Ada already goes much beyond other languages for<br /> separate compilation of interfaces. Other languages such as Turbo Pascal<br /> for Windows do allow a form of package - the Pascal units - but the<br /> interface and the body are one single text. So you would expect Turbo<br /> Pascal compilation to be slow ... except that the compiler is smart enough<br /> to distinguish changes to the interface from changes to the implementation.<br /> This shows the path: if you still think that the kind of compilation<br /> optimization that motivates hierarchical libraries is relevant, you can<br /> achieve it by a more sophisticated compiler without need to increase the<br /> size of the language. The feature may be well-designed, but it is<br /> nevertheless dead weight. In addition, it has been shown to undermine one<br /> of the most valuable conceptual assets of Ada: the safety of packages (with<br /> unwanted self-proclaimed children getting access to the private part).<br /> <br /> The fact that a feature is well designed does not mean that it has to be<br /> part of the language: designing the architecture of a programming language<br /> is about choice and responsible choice is always &quot;either/or&quot;, rarely &quot;all<br /> of&quot;. Failing to choose will mean more to learn, more to implement, less<br /> efficiency, and less chances for Ada to succeed.<br /> <br /> CONCLUSION<br /> <br /> I have certainly hesitated before sending this open letter. Some very good<br /> friends have expressed concerns about possible negative impact on Ada.<br /> Clearly, my present assessment of the situation is quite different and<br /> I think that the 9X program requires a very substantial reorientation to<br /> succeed: I see more risk in continuing in the present course than in<br /> attempting a courageous reorientation.<br /> <br /> Others who share my concerns have reacted on the assumption that, anyway,<br /> it is too late. My hope is that this is not the case, and my belief is that<br /> the current plans and schedules are unrealistic to the degree that a<br /> reorientation is the only way to achieve something in a reasonable time.<br /> In 1981, Larry Druffel sponsored a parallel group - Emilion - to study an<br /> alternative. This could be an example to follow.<br /> <br /> In acknowledgment of the fact that it has not been possible for me to make<br /> an effective contribution, and also in view of my reluctance to be<br /> associated with something whose complexity I disapprove and whose aesthetics<br /> I can neither see nor share, I will no longer participate to Distinguished<br /> Reviewers meetings and would like my name to be removed from the list. <br /> I will see if I can be more effective from outside the group (for that matter,<br /> I would like to be on the list of Volunteer Reviewers).<br /> <br /> I was looking forward to be one of those promoting 9X but this does not<br /> appear to be possible at the present time.<br /> <br /> Sincerely,<br /> <br /> <br /> <br /> Jean D. Ichbiah<br /> Architect of the Ada Language<br /> <br /> <br /> -- <br /> **************************************************************************<br /> Greg Aharonian<br /> Source Translation &amp; Optimiztion<br /> P.O. Box 404, Belmont, MA 02178<br /> <br /> &lt;/nowiki&gt;</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=157 2025-04-29T12:25:33Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A [[J_Ichbiah_mail_20_nov_1992|mail]] from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=156 2025-04-29T12:22:19Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Some documents from prominent actors''' ===<br /> <br /> The Jean Ichbiah [[ :File:Interview Ichbiah 1984.pdf | ACM interview ]] in 1984 exposes his point of view on Ada 83.<br /> A mail from J.Ichbiah to Christine Anderson in november 1992 is interesting from the point of view of this site, as it shows that preservation of Ada 83 is not only a computing history necessary task, but also the preservation of some qualities that revisions damaged.<br /> J.P.Rosen in his book &quot;Méthodes de génie logiciel avec Ada 95&quot; (préambule section 3.2 p.30) notes that heritage opposes to static type verification.<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]</div>

Vmo https://ada83.org/wiki/index.php?title=File:Interview_Ichbiah_1984.pdf&diff=155 2025-04-29T11:51:23Z

<p>Vmo: Rapport d&#039;interview &quot;ADA: PAST, PRESENT, FUTURE An Interview with JEAN ICHBIAH, the Principal Designer of Ada&quot;, Comm. ACM, Vol 27, n°10, 1984.</p> <hr /> <div>== Summary ==<br /> Rapport d'interview &quot;ADA: PAST, PRESENT, FUTURE<br /> An Interview with JEAN ICHBIAH,<br /> the Principal Designer of Ada&quot;, Comm. ACM, Vol 27, n°10, 1984.</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=154 2025-04-29T11:48:15Z

<p>Vmo: /* The ENST theses and P.Kruchten / J.P.Rosen documents */</p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten [[ :File:Thèse-P-Kruchten-ENST-1986.pdf | &quot;une machine Ada virtuelle : architecture&quot; ]]<br /> <br /> * Thèse de Jean Pierre Rosen [[ :File:Thèse-JP-Rosen-ENST-1986.pdf | &quot;une machine virtuelle pour Ada : le système d'exploitation&quot; ]]<br /> <br /> A short article, 3 pages, from J.P.Rosen on the Ada way of managing numerical computing portability is [[ File:Rosen Ada Numerics Model-AUJ43.pdf | here ]]</div>

Vmo https://ada83.org/wiki/index.php?title=File:Rosen_Ada_Numerics_Model-AUJ43.pdf&diff=153 2025-04-29T11:41:53Z

<p>Vmo: Court article de 3 pages qui apporte un intéressant éclairage sur la façon de gérer le calcul réel avec Ada.</p> <hr /> <div>== Summary ==<br /> Court article de 3 pages qui apporte un intéressant éclairage sur la façon de gérer le calcul réel avec Ada.</div>

Vmo https://ada83.org/wiki/index.php?title=File:Th%C3%A8se-JP-Rosen-ENST-1986.pdf&diff=152 2025-04-29T11:23:32Z

<p>Vmo: Thèse de J.P.Rosen passée en 1986 à l&#039;ENST &quot;une machine virtuelle pour Ada : le système d&#039;exploitation&quot;</p> <hr /> <div>== Summary ==<br /> Thèse de J.P.Rosen passée en 1986 à l'ENST &quot;une machine virtuelle pour Ada : le système d'exploitation&quot;</div>

Vmo https://ada83.org/wiki/index.php?title=File:Th%C3%A8se-P-Kruchten-ENST-1986.pdf&diff=151 2025-04-29T11:21:13Z

<p>Vmo: Thèse de Philippe KRUCHTEN passée en octobre 1986 à l&#039;ENST &quot;une machine Ada virtuelle : architecture&quot;</p> <hr /> <div>== Summary ==<br /> Thèse de Philippe KRUCHTEN passée en octobre 1986 à l'ENST &quot;une machine Ada virtuelle : architecture&quot;</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=150 2025-04-29T11:19:30Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === '''The LRM''' ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].<br /> <br /> === '''Various other documents and studies''' ===<br /> <br /> ==== The ENST theses and P.Kruchten / J.P.Rosen documents ====<br /> <br /> A la fin de 1986, deux thèses sont passée à l'ENST (Ecole Nationale Supérieure des Télécommunications) un travail fait en collaboration avec l'équipe du projet NYUADA auquel travaille alors [https://en.wikipedia.org/wiki/Robert_Dewar Robert Dewar].<br /> <br /> * Thèse de Philippe Kruchten &quot;une machine Ada virtuelle : architecture&quot;<br /> <br /> * Thèse de Jean Pierre Rosen &quot;une machine virtuelle pour Ada : le système d'exploitation&quot;</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=149 2025-04-29T10:57:53Z

<p>Vmo: </p> <hr /> <div>== '''Ada 83 documentation''' ==<br /> === The LRM ===<br /> <br /> The primary source of information is the [[ :File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf | Language Reference Manual ]] (LRM) published by the DoD. This document comprizes 338 pages with annexes and indexes.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is [[ : File:DEC ada lrm.pdf | here ]].</div>

Vmo https://ada83.org/wiki/index.php?title=File:Ada-Ref-Manual-ANSI-MIL-STD-1815A.pdf&diff=148 2025-04-29T10:44:38Z

<p>Vmo: The original Dod Ada Language Reference Manual for Ada 83 scanned.</p> <hr /> <div>== Summary ==<br /> The original Dod Ada Language Reference Manual for Ada 83 scanned.</div>

Vmo https://ada83.org/wiki/index.php?title=File:DEC_ada_lrm.pdf&diff=147 2025-04-29T10:39:06Z

<p>Vmo: Digital Equipment Corporation annotated Ada 83 Language Reference Manual for DEC Ada.</p> <hr /> <div>== Summary ==<br /> Digital Equipment Corporation annotated Ada 83 Language Reference Manual for DEC Ada.</div>

Vmo https://ada83.org/wiki/index.php?title=Documentation&diff=146 2025-04-29T10:36:15Z

<p>Vmo: Created page with &quot;&#039;&#039;&#039;Ada 83 documentation&#039;&#039;&#039; The primary source of information is the Language Reference Manual (LRM) published by the DoD. Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is here.&quot;</p> <hr /> <div>'''Ada 83 documentation'''<br /> <br /> The primary source of information is the Language Reference Manual (LRM) published by the DoD.<br /> <br /> Given the importance of the DEC (Digital Equipment Corporation) in the Ada 83 decade, a lot of people knew or worked with DEC Ada whose commented LRM is here.</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=145 2025-04-29T10:31:27Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|500px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is around 175 pages long, which makes it accessible to an individual.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> <br /> This site aims at gathering [[Ada_83_history|history]] facts and [[Ada_83_tools|tools]] [[documentation]] ans [[Ada_83_examples|examples]] written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_tools&diff=144 2025-04-23T09:58:31Z

<p>Vmo: </p> <hr /> <div>'''Types of Ada 83 tools.'''<br /> <br /> As for any computer language, tools for Ada 83 include [[Editing services|editing services]] and [[Compilers|compilers]] toolchains.<br /> <br /> Other categories of tools are of special usefulness in Ada 83, that is cross referencing tools, and structure analysis tools.<br /> <br /> Ada 83 has been specified for designing and implementing extensive software systems. Tools for displaying high level program structure are very useful, but choosing what aspects of the structure are to be displayed and how has never been very satisfactorily resolved.<br /> <br /> An overview of such problems can be perceived by reading [https://dl.acm.org/doi/pdf/10.1145/71327.71333 &quot;A simplified graphic notation for Ada programs&quot;] by D.Sterne et al. Ada Letters, September/October 1989 Vol.IX N°6.</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_tools&diff=143 2025-04-23T09:44:02Z

<p>Vmo: Created page with &quot;Types of Ada 83 tools. As for any computer language, tools for Ada 83 include editing services and compilers toolchains. Other categories of tools are of special usefulness in Ada 83, that is cross referencing tools, and structure analysis tools. Ada 83 has been specified for designing and implementing extensive software systems. Tools for displaying high level program structure are very useful, but choosing what aspects of the struc...&quot;</p> <hr /> <div>Types of Ada 83 tools.<br /> <br /> As for any computer language, tools for Ada 83 include [[Editing services|editing services]] and [[Compilers|compilers]] toolchains.<br /> <br /> Other categories of tools are of special usefulness in Ada 83, that is cross referencing tools, and structure analysis tools.<br /> <br /> Ada 83 has been specified for designing and implementing extensive software systems. Tools for displaying high level program structure are very useful, but choosing what aspects of the structure are to be displayed and how has never been very satisfactorily resolved.<br /> <br /> An overview of such problems can be perceived by reading &quot;A SIMPLIFIED GRAPHIC NOTATION FOR Ada PROGRAMS&quot; by D.Sterne et al.</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_on_AVR_chips&diff=138 2025-03-29T16:08:55Z

<p>Vmo: </p> <hr /> <div>'''Ada 83 on AVR microcontrollers'''<br /> <br /> The famous Arduino Uno uses an Atmel ATMEGA 328P chip. The base module for 328P register map can be conveniently expressed by a '''record''' type and its representation clause.<br /> &lt;syntaxhighlight lang=&quot;ada&quot;&gt;<br /> -------------------------------------------------------------------------------------------------------------------------<br /> -- CC BY SA ATMEGA_328P.ADS VINCENT MORIN 23/3/2025 UNIVERSITE DE BRETAGNE OCCIDENTALE<br /> -------------------------------------------------------------------------------------------------------------------------<br /> -- 1 2 3 4 5 6 7 8 9 0 1 2<br /> <br /> <br /> with TYPES;<br /> use TYPES;<br /> <br /> -----------<br /> package ATMEGA_328P<br /> -----------<br /> is<br /> <br /> type RAM_MAP is record<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 534 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> PIN_B, DDR_B, PORT_B : BYTE;<br /> PIN_C, DDR_C, PORT_C : BYTE; <br /> PIN_D, DDR_D, PORT_D : BYTE; <br /> TIFR0_OCF0A, TIFR0_OCF0B, TIFR0_TOV0 : BOOLEAN;<br /> <br /> TIFR1_ICF1,<br /> TIFR1_OCF1A, TIFR1_OCF1B, TIFR1_TOV1 : BOOLEAN;<br /> <br /> TIFR2_OCF2A, TIFR2_OCF2B, TIFR2_TOV2 : BOOLEAN;<br /> <br /> PCIFR : U3;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 533 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> EIFR_INTF,<br /> EIMSK_INT : U2;<br /> GPIOR0 : U8;<br /> <br /> EECR_EEPM : U2;<br /> EECR_EERIE, EECR_EEMPE, EECR_EEPE,<br /> EECR_EERE : BOOLEAN;<br /> <br /> EEDR : U8;<br /> EEAR : U16;<br /> <br /> GTCCR_TSM, GTCCR_PSRASY, GTCCR_PSRSYNC : BOOLEAN;<br /> <br /> TCCR0A_COM0A, TCCR0A_COM0B, TCCR0A_WGM : U2;<br /> <br /> TCCR0B_WGM : BOOLEAN;<br /> TCCR0B_CS : U3;<br /> TCCR0B_FOC0A, TCCR0B_FOC0B : BOOLEAN;<br /> <br /> TCNT0,<br /> OCR0A,<br /> OCR0B : U8;<br /> <br /> GPIOR1, GPIOR2 : U8;<br /> SPCR_SPIE, SPCR_SPE, SPCR_DORD,<br /> SPCR_MSTR, SPCR_CPOL, SPCR_CPHA : BOOLEAN;<br /> SPCR_SPR : U2;<br /> <br /> SPSR_SPIF, SPSR_WCOL, SPSR_SPI2X : BOOLEAN;<br /> SPDR : U8;<br /> <br /> ACSR_ACD, ACSR_ACBG, ACSR_ACO, ACSR_ACI,<br /> ACSR_ACIE, ACSR_ACIC : BOOLEAN;<br /> ACSR_ACIS : U2;<br /> <br /> SMCR_SM : U3;<br /> SMCR_SE : BOOLEAN;<br /> <br /> MCUSR_WDRF, MCUSR_BORF, MCUSR_EXTRF,<br /> MCUSR_PORF : BOOLEAN;<br /> <br /> MCUCR_BODS, MCUCR_BODSE, MCUCR_PUD,<br /> MCUCR_IVSEL, MCUCR_IVCE : BOOLEAN;<br /> <br /> SPMCSR_SPMIE, SPMCSR_RWWSB,<br /> SPMCSR_RWWSRE, SPMCSR_BLBSET,<br /> SPMCSR_PGWRT, SPMCSR_PGERS,<br /> SPMCSR_SELFPRGEN : BOOLEAN;<br /> <br /> SP : U11;<br /> <br /> SREG_I, SREG_T, SREG_H, SREG_S,<br /> SREG_V, SREG_N, SREG_Z, SREG_C : BOOLEAN;<br /> <br /> WDTCSR_WDIF, WDTCSR_WDIE, WDTCSR_WDP3,<br /> WDTCSR_WDCE, WDTCSR_WDE : BOOLEAN;<br /> WDTCSR_WDP : U3;<br /> <br /> CLKPR_CLKPCE : BOOLEAN;<br /> CLKPR_CLKPS : U4;<br /> <br /> PRR_PRTWI, PRR_PRTIM2, PRR_PRTIM0,<br /> PRR_PRTIM1, PRR_PRSPI, PRR_PRUSART0,<br /> PRR_PRADC : BOOLEAN;<br /> <br /> OSCCAL : U8;<br /> PCICR_PCIE : U3;<br /> <br /> EICRA_ISC1, EICRA_ISC0 : U2;<br /> <br /> PCMSK0_PCINT, PCMSK1_PCINT, PCMSK2_PCINT : U8;<br /> <br /> TIMSK0_OCIE0B,<br /> TIMSK0_OCIE0A, TIMSK0_TOIE0 : BOOLEAN;<br /> <br /> TIMSK1_ICIE1, TIMSK1_OCIE1B,<br /> TIMSK1_OCIE1A, TIMSK1_TOIE1 : BOOLEAN;<br /> <br /> TIMSK2_OCIE2B,<br /> TIMSK2_OCIE2A, TIMSK2_TOIE2 : BOOLEAN;<br /> <br /> ADC : U16;<br /> ADCSRA_ADEN, ADCSRA_ADSC,<br /> ADCSRA_ADATE, ADCSRA_ADIF,<br /> ADCSRA_ADIE, ADMUX_ADLAR,<br /> ADCSRB_ACME : BOOLEAN;<br /> ADCSRA_ADPS, ADCSRB_ADTS : U3;<br /> ADMUX_REFS : U2;<br /> ADMUX_MUX : U4;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 532 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> DIDR0_ADC5D, DIDR0_ADC4D, DIDR0_ADC3D,<br /> DIDR0_ADC2D, DIDR0_ADC1D, DIDR0_ADC0D : BOOLEAN;<br /> DIDR1_AIN1D, DIDR1_AIN0D : BOOLEAN;<br /> <br /> TCCR1A_COM1A, TCCR1A_COM1B, TCCR1A_WGM : U2;<br /> TCCR1B_ICNC1, TCCR1B_ICES1 : BOOLEAN;<br /> TCCR1B_WGM : U2;<br /> TCCR1B_CS : U3;<br /> TCCR1C_FOC1A, TCCR1C_FOC1B : BOOLEAN;<br /> TCNT1, ICR1, OCR1A, OCR1B : U16;<br /> <br /> TCCR2A_COM2A, TCCR2A_COM2B, TCCR2A_WGM : U2;<br /> TCCR2B_WGM : BOOLEAN;<br /> TCCR2B_CS : U3;<br /> TCCR2B_FOC2A, TCCR2B_FOC2B : BOOLEAN;<br /> TCNT2, OCR2A, OCR2B : U8;<br /> <br /> ASSR_EXCLK, ASSR_AS2, ASSR_TCN2UB,<br /> ASSR_OCR2AUB, ASSR_OCR2BUB,<br /> ASSR_TCR2AUB, ASSR_TCR2BUB : BOOLEAN;<br /> <br /> TWBR : U8;<br /> TWSR_TWS : U5;<br /> TWSR_TWPS : U2;<br /> TWAR_TWA : U7;<br /> TWAR_TWGCE : BOOLEAN;<br /> TWDR : U8;<br /> TWCR_TWINT, TWCR_TWEA, TWCR_TWSTA,<br /> TWCR_TWSTO, TWCR_TWWC, TWCR_TWEN,<br /> TWCR_TWIE : BOOLEAN;<br /> TWAMR_TWAM : U7;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 531 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> UCSR0A_RXC0, UCSR0A_TXC0, UCSR0A_UDRE0,<br /> UCSR0A_FE0, UCSR0A_DOR0, UCSR0A_UPE0,<br /> UCSR0A_U2X0, UCSR0A_MPCM0 : BOOLEAN;<br /> <br /> UCSR0B_RXCIE0, UCSR0B_TXCIE0,<br /> UCSR0B_UDRIE0, UCSR0B_RXEN0,<br /> UCSR0B_TXEN0, UCSR0B_UCSZ02,<br /> UCSR0B_RXB80, UCSR0B_TXB80 : BOOLEAN;<br /> <br /> UCSR0C_UMSEL0, UCSR0C_UPM0,<br /> UCSR0C_UCSZ0 : U2;<br /> UCSR0C_USBS0, UCSR0C_UCPOL0 : BOOLEAN;<br /> UBRR : U12;<br /> UDR0 : U8;<br /> end record;<br /> <br /> <br /> for RAM_MAP use<br /> record at mod 1;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 534 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#23# .. 16#2B#<br /> PIN_B at 16#23# range 0..7;<br /> DDR_B at 16#24# range 0..7;<br /> PORT_B at 16#25# range 0..7;<br /> PIN_C at 16#26# range 0..7;<br /> DDR_C at 16#27# range 0..7;<br /> PORT_C at 16#28# range 0..7;<br /> PIN_D at 16#29# range 0..7;<br /> DDR_D at 16#2A# range 0..7;<br /> PORT_D at 16#2B# range 0..7;<br /> -- 16#35#<br /> TIFR0_OCF0A at 16#35# range 1..1; TIFR0_OCF0B at 16#35# range 2..2;<br /> TIFR0_TOV0 at 16#35# range 0..0;<br /> -- 16#36#<br /> TIFR1_ICF1 at 16#36# range 5..5; TIFR1_OCF1A at 16#36# range 1..1;<br /> TIFR1_OCF1B at 16#36# range 2..2; TIFR1_TOV1 at 16#36# range 0..0;<br /> -- 16#37#<br /> TIFR2_OCF2A at 16#37# range 1..1; TIFR2_OCF2B at 16#37# range 2..2;<br /> TIFR2_TOV2 at 16#37# range 0..0;<br /> -- 16#3B#<br /> PCIFR at 16#3B# range 0..2;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 533 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#3C#<br /> EIFR_INTF at 16#3C# range 0..1;<br /> -- 16#3D#<br /> EIMSK_INT at 16#3D# range 0..1;<br /> -- 16#3E#<br /> GPIOR0 at 16#3E# range 0..7;<br /> -- 16#3F#<br /> EECR_EEPM at 16#3F# range 4..5; EECR_EERIE at 16#3F# range 3..3;<br /> EECR_EEMPE at 16#3F# range 2..2; EECR_EEPE at 16#3F# range 1..1;<br /> EECR_EERE at 16#3F# range 0..0;<br /> -- 16#40#<br /> EEDR at 16#40# range 0..7;<br /> -- 16#41#<br /> EEAR at 16#41# range 0..15;<br /> -- 16#43#<br /> GTCCR_TSM at 16#43# range 7..7; GTCCR_PSRASY at 16#43# range 1..1;<br /> GTCCR_PSRSYNC at 16#43# range 0..0;<br /> -- 16#44#<br /> TCCR0A_COM0A at 16#44# range 6..7; TCCR0A_COM0B at 16#44# range 4..5;<br /> TCCR0A_WGM at 16#44# range 0..1;<br /> -- 16#45#<br /> TCCR0B_FOC0A at 16#45# range 7..7; TCCR0B_FOC0B at 16#45# range 6..6;<br /> TCCR0B_WGM at 16#45# range 3..3; TCCR0B_CS at 16#45# range 0..2;<br /> -- 16#46#<br /> TCNT0 at 16#46# range 0..7;<br /> -- 16#47#<br /> OCR0A at 16#47# range 0..7;<br /> -- 16#48#<br /> OCR0B at 16#48# range 0..7;<br /> -- 16#4A#<br /> GPIOR1 at 16#4A# range 0..7;<br /> -- 16#4B#<br /> GPIOR2 at 16#4B# range 0..7;<br /> -- 16#4C#<br /> SPCR_SPIE at 16#4C# range 7..7; SPCR_SPE at 16#4C# range 6..6;<br /> SPCR_DORD at 16#4C# range 5..5; SPCR_MSTR at 16#4C# range 4..4;<br /> SPCR_CPOL at 16#4C# range 3..3; SPCR_CPHA at 16#4C# range 2..2;<br /> SPCR_SPR at 16#4C# range 0..1;<br /> -- 16#4D#<br /> SPSR_SPIF at 16#4D# range 7..7; SPSR_WCOL at 16#4D# range 6..6;<br /> SPSR_SPI2X at 16#4D# range 0..0;<br /> -- 16#4E#<br /> SPDR at 16#4E# range 0..7;<br /> -- 16#50#<br /> ACSR_ACD at 16#50# range 7..7; ACSR_ACBG at 16#50# range 6..6;<br /> ACSR_ACO at 16#50# range 5..5; ACSR_ACI at 16#50# range 4..4;<br /> ACSR_ACIE at 16#50# range 3..3; ACSR_ACIC at 16#50# range 2..2;<br /> ACSR_ACIS at 16#50# range 0..1;<br /> -- 16#53#<br /> SMCR_SM at 16#53# range 1..3;<br /> SMCR_SE at 16#53# range 0..0;<br /> -- 16#54#<br /> MCUSR_WDRF at 16#54# range 3..3; MCUSR_BORF at 16#54# range 2..2;<br /> MCUSR_EXTRF at 16#54# range 1..1; MCUSR_PORF at 16#54# range 0..0;<br /> -- 16#55#<br /> MCUCR_BODS at 16#55# range 6..6; MCUCR_BODSE at 16#55# range 5..5;<br /> MCUCR_PUD at 16#55# range 4..4; MCUCR_IVSEL at 16#55# range 1..1;<br /> MCUCR_IVCE at 16#55# range 0..0;<br /> -- 16#57#<br /> SPMCSR_SPMIE at 16#57# range 7..7; SPMCSR_RWWSB at 16#57# range 6..6;<br /> SPMCSR_RWWSRE at 16#57# range 4..4; SPMCSR_BLBSET at 16#57# range 3..3;<br /> SPMCSR_PGWRT at 16#57# range 2..2; SPMCSR_PGERS at 16#57# range 1..1;<br /> SPMCSR_SELFPRGEN at 16#57# range 0..0;<br /> -- 16#5D#<br /> SP at 16#5D# range 0..10;<br /> -- 16#5F#<br /> SREG_I at 16#5F# range 7..7; SREG_T at 16#5F# range 6..6;<br /> SREG_H at 16#5F# range 5..5; SREG_S at 16#5F# range 4..4;<br /> SREG_V at 16#5F# range 3..3; SREG_N at 16#5F# range 2..2;<br /> SREG_Z at 16#5F# range 1..1; SREG_C at 16#5F# range 0..0;<br /> -- 16#60#<br /> WDTCSR_WDIF at 16#60# range 7..7; WDTCSR_WDIE at 16#60# range 6..6;<br /> WDTCSR_WDP3 at 16#60# range 5..5; WDTCSR_WDCE at 16#60# range 4..4;<br /> WDTCSR_WDE at 16#60# range 3..3; WDTCSR_WDP at 16#60# range 0..2;<br /> -- 16#61#<br /> CLKPR_CLKPCE at 16#61# range 7..7;<br /> CLKPR_CLKPS at 16#61# range 0..3;<br /> -- 16#64#<br /> PRR_PRTWI at 16#64# range 7..7; PRR_PRTIM2 at 16#64# range 6..6;<br /> PRR_PRTIM0 at 16#64# range 5..5; PRR_PRTIM1 at 16#64# range 3..3;<br /> PRR_PRSPI at 16#64# range 2..2; PRR_PRUSART0 at 16#64# range 1..1;<br /> PRR_PRADC at 16#64# range 0..0;<br /> -- 16#66#<br /> OSCCAL at 16#66# range 0..7;<br /> -- 16#68#<br /> PCICR_PCIE at 16#68# range 0..2;<br /> -- 16#69#<br /> EICRA_ISC1 at 16#69# range 2..3; EICRA_ISC0 at 16#69# range 0..1;<br /> -- 16#6B#<br /> PCMSK0_PCINT at 16#6B# range 0..7;<br /> -- 16#6C#<br /> PCMSK1_PCINT at 16#6C# range 0..7;<br /> -- 16#6D#<br /> PCMSK2_PCINT at 16#6D# range 0..7;<br /> -- 16#6E#<br /> TIMSK0_OCIE0B at 16#6E# range 2..2; TIMSK0_OCIE0A at 16#6E# range 1..1;<br /> TIMSK0_TOIE0 at 16#6E# range 0..0;<br /> -- 16#6F#<br /> TIMSK1_ICIE1 at 16#6F# range 5..5;<br /> TIMSK1_OCIE1B at 16#6F# range 2..2; TIMSK1_OCIE1A at 16#6F# range 1..1;<br /> TIMSK1_TOIE1 at 16#6F# range 0..0;<br /> -- 16#70#<br /> TIMSK2_OCIE2B at 16#70# range 2..2; TIMSK2_OCIE2A at 16#70# range 1..1;<br /> TIMSK2_TOIE2 at 16#70# range 0..0;<br /> -- 16#78#<br /> ADC at 16#78# range 0..15;<br /> -- 16#7A#<br /> ADCSRA_ADEN at 16#7A# range 7..7; ADCSRA_ADSC at 16#7A# range 6..6;<br /> ADCSRA_ADATE at 16#7A# range 5..5; ADCSRA_ADIF at 16#7A# range 4..4;<br /> ADCSRA_ADIE at 16#7A# range 3..3; ADCSRA_ADPS at 16#7A# range 0..2;<br /> -- 16#7B#<br /> ADCSRB_ACME at 16#7B# range 6..6; ADCSRB_ADTS at 16#7B# range 0..2;<br /> -- 16#7C#<br /> ADMUX_REFS at 16#7C# range 6..7; ADMUX_ADLAR at 16#7C# range 5..5;<br /> ADMUX_MUX at 16#7C# range 0..3;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 532 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#7E#<br /> DIDR0_ADC5D at 16#7E# range 5..5; DIDR0_ADC4D at 16#7E# range 4..4;<br /> DIDR0_ADC3D at 16#7E# range 3..3; DIDR0_ADC2D at 16#7E# range 2..2;<br /> DIDR0_ADC1D at 16#7E# range 1..1; DIDR0_ADC0D at 16#7E# range 0..0;<br /> -- 16#7F#<br /> DIDR1_AIN1D at 16#7F# range 1..1; DIDR1_AIN0D at 16#7F# range 0..0;<br /> -- 16#80#<br /> TCCR1A_COM1A at 16#80# range 6..7; TCCR1A_COM1B at 16#80# range 4..5;<br /> TCCR1A_WGM at 16#80# range 0..1;<br /> -- 16#81#<br /> TCCR1B_ICNC1 at 16#81# range 7..7; TCCR1B_ICES1 at 16#81# range 6..6;<br /> TCCR1B_WGM at 16#81# range 3..4; TCCR1B_CS at 16#81# range 0..2;<br /> -- 16#82#<br /> TCCR1C_FOC1A at 16#82# range 7..7; TCCR1C_FOC1B at 16#82# range 6..6;<br /> -- 16#84#<br /> TCNT1 at 16#84# range 0..15;<br /> -- 16#86#<br /> ICR1 at 16#86# range 0..15;<br /> -- 16#88#<br /> OCR1A at 16#88# range 0..15;<br /> -- 16#8A#<br /> OCR1B at 16#8A# range 0..15;<br /> -- 16#B0#<br /> TCCR2A_COM2A at 16#B0# range 6..7; TCCR2A_COM2B at 16#B0# range 4..5;<br /> TCCR2A_WGM at 16#B0# range 0..1;<br /> -- 16#B1#<br /> TCCR2B_FOC2A at 16#B1# range 7..7; TCCR2B_FOC2B at 16#B1# range 6..6;<br /> TCCR2B_WGM at 16#B1# range 3..3; TCCR2B_CS at 16#B1# range 0..2;<br /> -- 16#B2#<br /> TCNT2 at 16#B2# range 0..7;<br /> -- 16#B3#<br /> OCR2A at 16#B3# range 0..7;<br /> -- 16#B4#<br /> OCR2B at 16#B4# range 0..7;<br /> -- 16#B6#<br /> ASSR_EXCLK at 16#B6# range 6..6; ASSR_AS2 at 16#B6# range 5..5;<br /> ASSR_TCN2UB at 16#B6# range 4..4; ASSR_OCR2AUB at 16#B6# range 3..3;<br /> ASSR_OCR2BUB at 16#B6# range 2..2; ASSR_TCR2AUB at 16#B6# range 1..1;<br /> ASSR_TCR2BUB at 16#B6# range 0..0;<br /> -- 16#B8#<br /> TWBR at 16#B8# range 0..7;<br /> -- 16#B9#<br /> TWSR_TWS at 16#B9# range 3..7;<br /> TWSR_TWPS at 16#B9# range 0..1;<br /> -- 16#BA#<br /> TWAR_TWA at 16#BA# range 1..7;<br /> TWAR_TWGCE at 16#BA# range 0..0;<br /> -- 16#BB#<br /> TWDR at 16#BB# range 0..7;<br /> -- 16#BC#<br /> TWCR_TWINT at 16#BC# range 7..7; TWCR_TWEA at 16#BC# range 6..6;<br /> TWCR_TWSTA at 16#BC# range 5..5; TWCR_TWSTO at 16#BC# range 4..4;<br /> TWCR_TWWC at 16#BC# range 3..3; TWCR_TWEN at 16#BC# range 2..2;<br /> TWCR_TWIE at 16#BC# range 0..0;<br /> -- 16#BD#<br /> TWAMR_TWAM at 16#BD# range 1..7;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 531 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#C0#<br /> UCSR0A_RXC0 at 16#C0# range 7..7; UCSR0A_TXC0 at 16#C0# range 6..6;<br /> UCSR0A_UDRE0 at 16#C0# range 5..5; UCSR0A_FE0 at 16#C0# range 4..4;<br /> UCSR0A_DOR0 at 16#C0# range 3..3; UCSR0A_UPE0 at 16#C0# range 2..2;<br /> UCSR0A_U2X0 at 16#C0# range 1..1; UCSR0A_MPCM0 at 16#C0# range 0..0;<br /> -- 16#C1#<br /> UCSR0B_RXCIE0 at 16#C1# range 7..7; UCSR0B_TXCIE0 at 16#C1# range 6..6;<br /> UCSR0B_UDRIE0 at 16#C1# range 5..5; UCSR0B_RXEN0 at 16#C1# range 4..4;<br /> UCSR0B_TXEN0 at 16#C1# range 3..3; UCSR0B_UCSZ02 at 16#C1# range 2..2;<br /> UCSR0B_RXB80 at 16#C1# range 1..1; UCSR0B_TXB80 at 16#C1# range 0..0;<br /> -- 16#C2#<br /> UCSR0C_UMSEL0 at 16#C2# range 6..7; UCSR0C_UPM0 at 16#C2# range 4..5;<br /> UCSR0C_USBS0 at 16#C2# range 3..3; UCSR0C_UCSZ0 at 16#C2# range 1..2;<br /> UCSR0C_UCPOL0 at 16#C2# range 0..0;<br /> -- 16#C4#<br /> UBRR at 16#C4# range 0..11;<br /> -- 16#C6#<br /> UDR0 at 16#C6# range 0..7;<br /> -- OUF !!<br /> end record;<br /> <br /> pragma PACK( RAM_MAP );<br /> <br /> REG : RAM_MAP; for REG'ADDRESS use 0;<br /> <br /> <br /> procedure VECT_1; pragma EXPORT ( C, VECT_1, &quot;__vector_1&quot; );<br /> procedure VECT_2; pragma EXPORT ( C, VECT_2, &quot;__vector_2&quot; );<br /> procedure VECT_3; pragma EXPORT ( C, VECT_3, &quot;__vector_3&quot; );<br /> procedure VECT_4; pragma EXPORT ( C, VECT_4, &quot;__vector_4&quot; );<br /> procedure VECT_5; pragma EXPORT ( C, VECT_5, &quot;__vector_5&quot; );<br /> procedure VECT_6; pragma EXPORT ( C, VECT_6, &quot;__vector_6&quot; );<br /> procedure VECT_7; pragma EXPORT ( C, VECT_7, &quot;__vector_7&quot; );<br /> procedure VECT_8; pragma EXPORT ( C, VECT_8, &quot;__vector_8&quot; );<br /> procedure VECT_9; pragma EXPORT ( C, VECT_9, &quot;__vector_9&quot; );<br /> procedure VECT_10; pragma EXPORT ( C, VECT_10, &quot;__vector_10&quot; );<br /> <br /> procedure VECT_12; pragma EXPORT ( C, VECT_12, &quot;__vector_12&quot; );<br /> procedure VECT_13; pragma EXPORT ( C, VECT_13, &quot;__vector_13&quot; );<br /> procedure VECT_14; pragma EXPORT ( C, VECT_14, &quot;__vector_14&quot; );<br /> procedure VECT_15; pragma EXPORT ( C, VECT_15, &quot;__vector_15&quot; );<br /> procedure VECT_16; pragma EXPORT ( C, VECT_16, &quot;__vector_16&quot; );<br /> procedure VECT_17; pragma EXPORT ( C, VECT_17, &quot;__vector_17&quot; );<br /> procedure VECT_20; pragma EXPORT ( C, VECT_20, &quot;__vector_20&quot; );<br /> procedure VECT_21; pragma EXPORT ( C, VECT_21, &quot;__vector_21&quot; );<br /> procedure VECT_22; pragma EXPORT ( C, VECT_22, &quot;__vector_22&quot; );<br /> procedure VECT_23; pragma EXPORT ( C, VECT_23, &quot;__vector_23&quot; );<br /> <br /> procedure VECT_25; pragma EXPORT ( C, VECT_25, &quot;__vector_25&quot; );<br /> <br /> -----------<br /> end ATMEGA_328P;<br /> -----------<br /> <br /> -- 1 2 3 4 5 6 7 8 9 0 1 2<br /> -------------------------------------------------------------------------------------------------------------------------<br /> &lt;/syntaxhighlight&gt;</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_on_AVR_chips&diff=137 2025-03-29T16:06:05Z

<p>Vmo: </p> <hr /> <div>'''Ada 83 on AVR microcontrollers'''<br /> <br /> The famous Arduino Uno uses an Atmel ATMEGA 328P chip. The base module for 328P register map can be conveniently expressed by a '''record''' type and its representation clause.<br /> &lt;syntaxhighlight lang=&quot;ada&quot;&gt;<br /> -------------------------------------------------------------------------------------------------------------------------<br /> -- CC BY SA ATMEGA_328P.ADS VINCENT MORIN 23/3/2025 UNIVERSITE DE BRETAGNE OCCIDENTALE<br /> -------------------------------------------------------------------------------------------------------------------------<br /> -- 1 2 3 4 5 6 7 8 9 0 1 2<br /> <br /> <br /> with TYPES;<br /> use TYPES;<br /> <br /> -----------<br /> package ATMEGA_328P<br /> -----------<br /> is<br /> <br /> type RAM_MAP is record<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 534 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> PIN_B, DDR_B, PORT_B : BYTE; -- VALEUR SUR BROCHE EXTERNE ENTREE, DIRECTION, VALEUR INTERNE SORTIE<br /> PIN_C, DDR_C, PORT_C : BYTE; -- VALEUR SUR BROCHE EXTERNE ENTREE, DIRECTION, VALEUR INTERNE SORTIE<br /> PIN_D, DDR_D, PORT_D : BYTE; -- VALEUR SUR BROCHE EXTERNE ENTREE, DIRECTION, VALEUR INTERNE SORTIE<br /> <br /> TIFR0_OCF0A, TIFR0_OCF0B, TIFR0_TOV0 : BOOLEAN;<br /> <br /> TIFR1_ICF1,<br /> TIFR1_OCF1A, TIFR1_OCF1B, TIFR1_TOV1 : BOOLEAN;<br /> <br /> TIFR2_OCF2A, TIFR2_OCF2B, TIFR2_TOV2 : BOOLEAN;<br /> <br /> PCIFR : U3;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 533 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> EIFR_INTF,<br /> EIMSK_INT : U2;<br /> GPIOR0 : U8;<br /> <br /> EECR_EEPM : U2;<br /> EECR_EERIE, EECR_EEMPE, EECR_EEPE,<br /> EECR_EERE : BOOLEAN;<br /> <br /> EEDR : U8;<br /> EEAR : U16;<br /> <br /> GTCCR_TSM, GTCCR_PSRASY, GTCCR_PSRSYNC : BOOLEAN;<br /> <br /> TCCR0A_COM0A, TCCR0A_COM0B, TCCR0A_WGM : U2;<br /> <br /> TCCR0B_WGM : BOOLEAN;<br /> TCCR0B_CS : U3;<br /> TCCR0B_FOC0A, TCCR0B_FOC0B : BOOLEAN;<br /> <br /> TCNT0,<br /> OCR0A,<br /> OCR0B : U8;<br /> <br /> GPIOR1, GPIOR2 : U8;<br /> SPCR_SPIE, SPCR_SPE, SPCR_DORD,<br /> SPCR_MSTR, SPCR_CPOL, SPCR_CPHA : BOOLEAN;<br /> SPCR_SPR : U2;<br /> <br /> SPSR_SPIF, SPSR_WCOL, SPSR_SPI2X : BOOLEAN;<br /> SPDR : U8;<br /> <br /> ACSR_ACD, ACSR_ACBG, ACSR_ACO, ACSR_ACI,<br /> ACSR_ACIE, ACSR_ACIC : BOOLEAN;<br /> ACSR_ACIS : U2;<br /> <br /> SMCR_SM : U3;<br /> SMCR_SE : BOOLEAN;<br /> <br /> MCUSR_WDRF, MCUSR_BORF, MCUSR_EXTRF,<br /> MCUSR_PORF : BOOLEAN;<br /> <br /> MCUCR_BODS, MCUCR_BODSE, MCUCR_PUD,<br /> MCUCR_IVSEL, MCUCR_IVCE : BOOLEAN;<br /> <br /> SPMCSR_SPMIE, SPMCSR_RWWSB,<br /> SPMCSR_RWWSRE, SPMCSR_BLBSET,<br /> SPMCSR_PGWRT, SPMCSR_PGERS,<br /> SPMCSR_SELFPRGEN : BOOLEAN;<br /> <br /> SP : U11;<br /> <br /> SREG_I, SREG_T, SREG_H, SREG_S,<br /> SREG_V, SREG_N, SREG_Z, SREG_C : BOOLEAN;<br /> <br /> WDTCSR_WDIF, WDTCSR_WDIE, WDTCSR_WDP3,<br /> WDTCSR_WDCE, WDTCSR_WDE : BOOLEAN;<br /> WDTCSR_WDP : U3;<br /> <br /> CLKPR_CLKPCE : BOOLEAN;<br /> CLKPR_CLKPS : U4;<br /> <br /> PRR_PRTWI, PRR_PRTIM2, PRR_PRTIM0,<br /> PRR_PRTIM1, PRR_PRSPI, PRR_PRUSART0,<br /> PRR_PRADC : BOOLEAN;<br /> <br /> OSCCAL : U8;<br /> PCICR_PCIE : U3;<br /> <br /> EICRA_ISC1, EICRA_ISC0 : U2;<br /> <br /> PCMSK0_PCINT, PCMSK1_PCINT, PCMSK2_PCINT : U8;<br /> <br /> TIMSK0_OCIE0B,<br /> TIMSK0_OCIE0A, TIMSK0_TOIE0 : BOOLEAN;<br /> <br /> TIMSK1_ICIE1, TIMSK1_OCIE1B,<br /> TIMSK1_OCIE1A, TIMSK1_TOIE1 : BOOLEAN;<br /> <br /> TIMSK2_OCIE2B,<br /> TIMSK2_OCIE2A, TIMSK2_TOIE2 : BOOLEAN;<br /> <br /> ADC : U16;<br /> ADCSRA_ADEN, ADCSRA_ADSC,<br /> ADCSRA_ADATE, ADCSRA_ADIF,<br /> ADCSRA_ADIE, ADMUX_ADLAR,<br /> ADCSRB_ACME : BOOLEAN;<br /> ADCSRA_ADPS, ADCSRB_ADTS : U3;<br /> ADMUX_REFS : U2;<br /> ADMUX_MUX : U4;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 532 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> DIDR0_ADC5D, DIDR0_ADC4D, DIDR0_ADC3D,<br /> DIDR0_ADC2D, DIDR0_ADC1D, DIDR0_ADC0D : BOOLEAN;<br /> DIDR1_AIN1D, DIDR1_AIN0D : BOOLEAN;<br /> <br /> TCCR1A_COM1A, TCCR1A_COM1B, TCCR1A_WGM : U2;<br /> TCCR1B_ICNC1, TCCR1B_ICES1 : BOOLEAN;<br /> TCCR1B_WGM : U2;<br /> TCCR1B_CS : U3;<br /> TCCR1C_FOC1A, TCCR1C_FOC1B : BOOLEAN;<br /> TCNT1, ICR1, OCR1A, OCR1B : U16;<br /> <br /> TCCR2A_COM2A, TCCR2A_COM2B, TCCR2A_WGM : U2;<br /> TCCR2B_WGM : BOOLEAN;<br /> TCCR2B_CS : U3;<br /> TCCR2B_FOC2A, TCCR2B_FOC2B : BOOLEAN;<br /> TCNT2, OCR2A, OCR2B : U8;<br /> <br /> ASSR_EXCLK, ASSR_AS2, ASSR_TCN2UB,<br /> ASSR_OCR2AUB, ASSR_OCR2BUB,<br /> ASSR_TCR2AUB, ASSR_TCR2BUB : BOOLEAN;<br /> <br /> TWBR : U8;<br /> TWSR_TWS : U5;<br /> TWSR_TWPS : U2;<br /> TWAR_TWA : U7;<br /> TWAR_TWGCE : BOOLEAN;<br /> TWDR : U8;<br /> TWCR_TWINT, TWCR_TWEA, TWCR_TWSTA,<br /> TWCR_TWSTO, TWCR_TWWC, TWCR_TWEN,<br /> TWCR_TWIE : BOOLEAN;<br /> TWAMR_TWAM : U7;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 531 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> UCSR0A_RXC0, UCSR0A_TXC0, UCSR0A_UDRE0,<br /> UCSR0A_FE0, UCSR0A_DOR0, UCSR0A_UPE0,<br /> UCSR0A_U2X0, UCSR0A_MPCM0 : BOOLEAN;<br /> <br /> UCSR0B_RXCIE0, UCSR0B_TXCIE0,<br /> UCSR0B_UDRIE0, UCSR0B_RXEN0,<br /> UCSR0B_TXEN0, UCSR0B_UCSZ02,<br /> UCSR0B_RXB80, UCSR0B_TXB80 : BOOLEAN;<br /> <br /> UCSR0C_UMSEL0, UCSR0C_UPM0,<br /> UCSR0C_UCSZ0 : U2;<br /> UCSR0C_USBS0, UCSR0C_UCPOL0 : BOOLEAN;<br /> UBRR : U12;<br /> UDR0 : U8;<br /> end record;<br /> <br /> <br /> for RAM_MAP use<br /> record at mod 1;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 534 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#23# .. 16#2B#<br /> PIN_B at 16#23# range 0..7;<br /> DDR_B at 16#24# range 0..7;<br /> PORT_B at 16#25# range 0..7;<br /> PIN_C at 16#26# range 0..7;<br /> DDR_C at 16#27# range 0..7;<br /> PORT_C at 16#28# range 0..7;<br /> PIN_D at 16#29# range 0..7;<br /> DDR_D at 16#2A# range 0..7;<br /> PORT_D at 16#2B# range 0..7;<br /> -- 16#35#<br /> TIFR0_OCF0A at 16#35# range 1..1; TIFR0_OCF0B at 16#35# range 2..2;<br /> TIFR0_TOV0 at 16#35# range 0..0;<br /> -- 16#36#<br /> TIFR1_ICF1 at 16#36# range 5..5; TIFR1_OCF1A at 16#36# range 1..1;<br /> TIFR1_OCF1B at 16#36# range 2..2; TIFR1_TOV1 at 16#36# range 0..0;<br /> -- 16#37#<br /> TIFR2_OCF2A at 16#37# range 1..1; TIFR2_OCF2B at 16#37# range 2..2;<br /> TIFR2_TOV2 at 16#37# range 0..0;<br /> -- 16#3B#<br /> PCIFR at 16#3B# range 0..2;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 533 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#3C#<br /> EIFR_INTF at 16#3C# range 0..1;<br /> -- 16#3D#<br /> EIMSK_INT at 16#3D# range 0..1;<br /> -- 16#3E#<br /> GPIOR0 at 16#3E# range 0..7;<br /> -- 16#3F#<br /> EECR_EEPM at 16#3F# range 4..5; EECR_EERIE at 16#3F# range 3..3;<br /> EECR_EEMPE at 16#3F# range 2..2; EECR_EEPE at 16#3F# range 1..1;<br /> EECR_EERE at 16#3F# range 0..0;<br /> -- 16#40#<br /> EEDR at 16#40# range 0..7;<br /> -- 16#41#<br /> EEAR at 16#41# range 0..15;<br /> -- 16#43#<br /> GTCCR_TSM at 16#43# range 7..7; GTCCR_PSRASY at 16#43# range 1..1;<br /> GTCCR_PSRSYNC at 16#43# range 0..0;<br /> -- 16#44#<br /> TCCR0A_COM0A at 16#44# range 6..7; TCCR0A_COM0B at 16#44# range 4..5;<br /> TCCR0A_WGM at 16#44# range 0..1;<br /> -- 16#45#<br /> TCCR0B_FOC0A at 16#45# range 7..7; TCCR0B_FOC0B at 16#45# range 6..6;<br /> TCCR0B_WGM at 16#45# range 3..3; TCCR0B_CS at 16#45# range 0..2;<br /> -- 16#46#<br /> TCNT0 at 16#46# range 0..7;<br /> -- 16#47#<br /> OCR0A at 16#47# range 0..7;<br /> -- 16#48#<br /> OCR0B at 16#48# range 0..7;<br /> -- 16#4A#<br /> GPIOR1 at 16#4A# range 0..7;<br /> -- 16#4B#<br /> GPIOR2 at 16#4B# range 0..7;<br /> -- 16#4C#<br /> SPCR_SPIE at 16#4C# range 7..7; SPCR_SPE at 16#4C# range 6..6;<br /> SPCR_DORD at 16#4C# range 5..5; SPCR_MSTR at 16#4C# range 4..4;<br /> SPCR_CPOL at 16#4C# range 3..3; SPCR_CPHA at 16#4C# range 2..2;<br /> SPCR_SPR at 16#4C# range 0..1;<br /> -- 16#4D#<br /> SPSR_SPIF at 16#4D# range 7..7; SPSR_WCOL at 16#4D# range 6..6;<br /> SPSR_SPI2X at 16#4D# range 0..0;<br /> -- 16#4E#<br /> SPDR at 16#4E# range 0..7;<br /> -- 16#50#<br /> ACSR_ACD at 16#50# range 7..7; ACSR_ACBG at 16#50# range 6..6;<br /> ACSR_ACO at 16#50# range 5..5; ACSR_ACI at 16#50# range 4..4;<br /> ACSR_ACIE at 16#50# range 3..3; ACSR_ACIC at 16#50# range 2..2;<br /> ACSR_ACIS at 16#50# range 0..1;<br /> -- 16#53#<br /> SMCR_SM at 16#53# range 1..3;<br /> SMCR_SE at 16#53# range 0..0;<br /> -- 16#54#<br /> MCUSR_WDRF at 16#54# range 3..3; MCUSR_BORF at 16#54# range 2..2;<br /> MCUSR_EXTRF at 16#54# range 1..1; MCUSR_PORF at 16#54# range 0..0;<br /> -- 16#55#<br /> MCUCR_BODS at 16#55# range 6..6; MCUCR_BODSE at 16#55# range 5..5;<br /> MCUCR_PUD at 16#55# range 4..4; MCUCR_IVSEL at 16#55# range 1..1;<br /> MCUCR_IVCE at 16#55# range 0..0;<br /> -- 16#57#<br /> SPMCSR_SPMIE at 16#57# range 7..7; SPMCSR_RWWSB at 16#57# range 6..6;<br /> SPMCSR_RWWSRE at 16#57# range 4..4; SPMCSR_BLBSET at 16#57# range 3..3;<br /> SPMCSR_PGWRT at 16#57# range 2..2; SPMCSR_PGERS at 16#57# range 1..1;<br /> SPMCSR_SELFPRGEN at 16#57# range 0..0;<br /> -- 16#5D#<br /> SP at 16#5D# range 0..10;<br /> -- 16#5F#<br /> SREG_I at 16#5F# range 7..7; SREG_T at 16#5F# range 6..6;<br /> SREG_H at 16#5F# range 5..5; SREG_S at 16#5F# range 4..4;<br /> SREG_V at 16#5F# range 3..3; SREG_N at 16#5F# range 2..2;<br /> SREG_Z at 16#5F# range 1..1; SREG_C at 16#5F# range 0..0;<br /> -- 16#60#<br /> WDTCSR_WDIF at 16#60# range 7..7; WDTCSR_WDIE at 16#60# range 6..6;<br /> WDTCSR_WDP3 at 16#60# range 5..5; WDTCSR_WDCE at 16#60# range 4..4;<br /> WDTCSR_WDE at 16#60# range 3..3; WDTCSR_WDP at 16#60# range 0..2;<br /> -- 16#61#<br /> CLKPR_CLKPCE at 16#61# range 7..7;<br /> CLKPR_CLKPS at 16#61# range 0..3;<br /> -- 16#64#<br /> PRR_PRTWI at 16#64# range 7..7; PRR_PRTIM2 at 16#64# range 6..6;<br /> PRR_PRTIM0 at 16#64# range 5..5; PRR_PRTIM1 at 16#64# range 3..3;<br /> PRR_PRSPI at 16#64# range 2..2; PRR_PRUSART0 at 16#64# range 1..1;<br /> PRR_PRADC at 16#64# range 0..0;<br /> -- 16#66#<br /> OSCCAL at 16#66# range 0..7;<br /> -- 16#68#<br /> PCICR_PCIE at 16#68# range 0..2;<br /> -- 16#69#<br /> EICRA_ISC1 at 16#69# range 2..3; EICRA_ISC0 at 16#69# range 0..1;<br /> -- 16#6B#<br /> PCMSK0_PCINT at 16#6B# range 0..7;<br /> -- 16#6C#<br /> PCMSK1_PCINT at 16#6C# range 0..7;<br /> -- 16#6D#<br /> PCMSK2_PCINT at 16#6D# range 0..7;<br /> -- 16#6E#<br /> TIMSK0_OCIE0B at 16#6E# range 2..2; TIMSK0_OCIE0A at 16#6E# range 1..1;<br /> TIMSK0_TOIE0 at 16#6E# range 0..0;<br /> -- 16#6F#<br /> TIMSK1_ICIE1 at 16#6F# range 5..5;<br /> TIMSK1_OCIE1B at 16#6F# range 2..2; TIMSK1_OCIE1A at 16#6F# range 1..1;<br /> TIMSK1_TOIE1 at 16#6F# range 0..0;<br /> -- 16#70#<br /> TIMSK2_OCIE2B at 16#70# range 2..2; TIMSK2_OCIE2A at 16#70# range 1..1;<br /> TIMSK2_TOIE2 at 16#70# range 0..0;<br /> -- 16#78#<br /> ADC at 16#78# range 0..15;<br /> -- 16#7A#<br /> ADCSRA_ADEN at 16#7A# range 7..7; ADCSRA_ADSC at 16#7A# range 6..6;<br /> ADCSRA_ADATE at 16#7A# range 5..5; ADCSRA_ADIF at 16#7A# range 4..4;<br /> ADCSRA_ADIE at 16#7A# range 3..3; ADCSRA_ADPS at 16#7A# range 0..2;<br /> -- 16#7B#<br /> ADCSRB_ACME at 16#7B# range 6..6; ADCSRB_ADTS at 16#7B# range 0..2;<br /> -- 16#7C#<br /> ADMUX_REFS at 16#7C# range 6..7; ADMUX_ADLAR at 16#7C# range 5..5;<br /> ADMUX_MUX at 16#7C# range 0..3;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 532 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#7E#<br /> DIDR0_ADC5D at 16#7E# range 5..5; DIDR0_ADC4D at 16#7E# range 4..4;<br /> DIDR0_ADC3D at 16#7E# range 3..3; DIDR0_ADC2D at 16#7E# range 2..2;<br /> DIDR0_ADC1D at 16#7E# range 1..1; DIDR0_ADC0D at 16#7E# range 0..0;<br /> -- 16#7F#<br /> DIDR1_AIN1D at 16#7F# range 1..1; DIDR1_AIN0D at 16#7F# range 0..0;<br /> -- 16#80#<br /> TCCR1A_COM1A at 16#80# range 6..7; TCCR1A_COM1B at 16#80# range 4..5;<br /> TCCR1A_WGM at 16#80# range 0..1;<br /> -- 16#81#<br /> TCCR1B_ICNC1 at 16#81# range 7..7; TCCR1B_ICES1 at 16#81# range 6..6;<br /> TCCR1B_WGM at 16#81# range 3..4; TCCR1B_CS at 16#81# range 0..2;<br /> -- 16#82#<br /> TCCR1C_FOC1A at 16#82# range 7..7; TCCR1C_FOC1B at 16#82# range 6..6;<br /> -- 16#84#<br /> TCNT1 at 16#84# range 0..15;<br /> -- 16#86#<br /> ICR1 at 16#86# range 0..15;<br /> -- 16#88#<br /> OCR1A at 16#88# range 0..15;<br /> -- 16#8A#<br /> OCR1B at 16#8A# range 0..15;<br /> -- 16#B0#<br /> TCCR2A_COM2A at 16#B0# range 6..7; TCCR2A_COM2B at 16#B0# range 4..5;<br /> TCCR2A_WGM at 16#B0# range 0..1;<br /> -- 16#B1#<br /> TCCR2B_FOC2A at 16#B1# range 7..7; TCCR2B_FOC2B at 16#B1# range 6..6;<br /> TCCR2B_WGM at 16#B1# range 3..3; TCCR2B_CS at 16#B1# range 0..2;<br /> -- 16#B2#<br /> TCNT2 at 16#B2# range 0..7;<br /> -- 16#B3#<br /> OCR2A at 16#B3# range 0..7;<br /> -- 16#B4#<br /> OCR2B at 16#B4# range 0..7;<br /> -- 16#B6#<br /> ASSR_EXCLK at 16#B6# range 6..6; ASSR_AS2 at 16#B6# range 5..5;<br /> ASSR_TCN2UB at 16#B6# range 4..4; ASSR_OCR2AUB at 16#B6# range 3..3;<br /> ASSR_OCR2BUB at 16#B6# range 2..2; ASSR_TCR2AUB at 16#B6# range 1..1;<br /> ASSR_TCR2BUB at 16#B6# range 0..0;<br /> -- 16#B8#<br /> TWBR at 16#B8# range 0..7;<br /> -- 16#B9#<br /> TWSR_TWS at 16#B9# range 3..7;<br /> TWSR_TWPS at 16#B9# range 0..1;<br /> -- 16#BA#<br /> TWAR_TWA at 16#BA# range 1..7;<br /> TWAR_TWGCE at 16#BA# range 0..0;<br /> -- 16#BB#<br /> TWDR at 16#BB# range 0..7;<br /> -- 16#BC#<br /> TWCR_TWINT at 16#BC# range 7..7; TWCR_TWEA at 16#BC# range 6..6;<br /> TWCR_TWSTA at 16#BC# range 5..5; TWCR_TWSTO at 16#BC# range 4..4;<br /> TWCR_TWWC at 16#BC# range 3..3; TWCR_TWEN at 16#BC# range 2..2;<br /> TWCR_TWIE at 16#BC# range 0..0;<br /> -- 16#BD#<br /> TWAMR_TWAM at 16#BD# range 1..7;<br /> -- -----------------------------------------------------------------------------<br /> -- PAGE 531 NOTICE 8271B-AVR<br /> -- -----------------------------------------------------------------------------<br /> -- 16#C0#<br /> UCSR0A_RXC0 at 16#C0# range 7..7; UCSR0A_TXC0 at 16#C0# range 6..6;<br /> UCSR0A_UDRE0 at 16#C0# range 5..5; UCSR0A_FE0 at 16#C0# range 4..4;<br /> UCSR0A_DOR0 at 16#C0# range 3..3; UCSR0A_UPE0 at 16#C0# range 2..2;<br /> UCSR0A_U2X0 at 16#C0# range 1..1; UCSR0A_MPCM0 at 16#C0# range 0..0;<br /> -- 16#C1#<br /> UCSR0B_RXCIE0 at 16#C1# range 7..7; UCSR0B_TXCIE0 at 16#C1# range 6..6;<br /> UCSR0B_UDRIE0 at 16#C1# range 5..5; UCSR0B_RXEN0 at 16#C1# range 4..4;<br /> UCSR0B_TXEN0 at 16#C1# range 3..3; UCSR0B_UCSZ02 at 16#C1# range 2..2;<br /> UCSR0B_RXB80 at 16#C1# range 1..1; UCSR0B_TXB80 at 16#C1# range 0..0;<br /> -- 16#C2#<br /> UCSR0C_UMSEL0 at 16#C2# range 6..7; UCSR0C_UPM0 at 16#C2# range 4..5;<br /> UCSR0C_USBS0 at 16#C2# range 3..3; UCSR0C_UCSZ0 at 16#C2# range 1..2;<br /> UCSR0C_UCPOL0 at 16#C2# range 0..0;<br /> -- 16#C4#<br /> UBRR at 16#C4# range 0..11;<br /> -- 16#C6#<br /> UDR0 at 16#C6# range 0..7;<br /> -- OUF !!<br /> end record;<br /> <br /> pragma PACK( RAM_MAP );<br /> <br /> REG : RAM_MAP; for REG'ADDRESS use 0;<br /> <br /> <br /> procedure VECT_1; pragma EXPORT ( C, VECT_1, &quot;__vector_1&quot; );<br /> procedure VECT_2; pragma EXPORT ( C, VECT_2, &quot;__vector_2&quot; );<br /> procedure VECT_3; pragma EXPORT ( C, VECT_3, &quot;__vector_3&quot; );<br /> procedure VECT_4; pragma EXPORT ( C, VECT_4, &quot;__vector_4&quot; );<br /> procedure VECT_5; pragma EXPORT ( C, VECT_5, &quot;__vector_5&quot; );<br /> procedure VECT_6; pragma EXPORT ( C, VECT_6, &quot;__vector_6&quot; );<br /> procedure VECT_7; pragma EXPORT ( C, VECT_7, &quot;__vector_7&quot; );<br /> procedure VECT_8; pragma EXPORT ( C, VECT_8, &quot;__vector_8&quot; );<br /> procedure VECT_9; pragma EXPORT ( C, VECT_9, &quot;__vector_9&quot; );<br /> procedure VECT_10; pragma EXPORT ( C, VECT_10, &quot;__vector_10&quot; );<br /> <br /> procedure VECT_12; pragma EXPORT ( C, VECT_12, &quot;__vector_12&quot; );<br /> procedure VECT_13; pragma EXPORT ( C, VECT_13, &quot;__vector_13&quot; );<br /> procedure VECT_14; pragma EXPORT ( C, VECT_14, &quot;__vector_14&quot; );<br /> procedure VECT_15; pragma EXPORT ( C, VECT_15, &quot;__vector_15&quot; );<br /> procedure VECT_16; pragma EXPORT ( C, VECT_16, &quot;__vector_16&quot; );<br /> procedure VECT_17; pragma EXPORT ( C, VECT_17, &quot;__vector_17&quot; );<br /> procedure VECT_20; pragma EXPORT ( C, VECT_20, &quot;__vector_20&quot; );<br /> procedure VECT_21; pragma EXPORT ( C, VECT_21, &quot;__vector_21&quot; );<br /> procedure VECT_22; pragma EXPORT ( C, VECT_22, &quot;__vector_22&quot; );<br /> procedure VECT_23; pragma EXPORT ( C, VECT_23, &quot;__vector_23&quot; );<br /> <br /> procedure VECT_25; pragma EXPORT ( C, VECT_25, &quot;__vector_25&quot; );<br /> <br /> -----------<br /> end ATMEGA_328P;<br /> -----------<br /> <br /> -- 1 2 3 4 5 6 7 8 9 0 1 2<br /> -------------------------------------------------------------------------------------------------------------------------<br /> &lt;/syntaxhighlight&gt;</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_on_AVR_chips&diff=136 2025-03-29T16:04:31Z

<p>Vmo: Created page with &quot;&#039;&#039;&#039;Ada 83 on AVR microcontrollers&#039;&#039;&#039; The famous Arduino Uno uses an Atmel ATMEGA 328P chip. The base module for 328P register map can be conveniently expressed by a &#039;&#039;&#039;record&#039;&#039;&#039; type and its representation clause.&quot;</p> <hr /> <div>'''Ada 83 on AVR microcontrollers'''<br /> <br /> The famous Arduino Uno uses an Atmel ATMEGA 328P chip. The base module for 328P register map can be conveniently expressed by a '''record''' type and its representation clause.</div>

Vmo https://ada83.org/wiki/index.php?title=Ada_83_examples&diff=135 2025-03-29T15:57:09Z

<p>Vmo: </p> <hr /> <div>== Examples ==<br /> <br /> The simplest program :<br /> <br /> &lt;syntaxhighlight lang=&quot;ada&quot;&gt;<br /> with TEXT_IO;<br /> -----------<br /> procedure HELLO_WORLD<br /> is -----------<br /> begin<br /> TEXT_IO.PUT_LINE( &quot;Hello_world !&quot; );<br /> end;<br /> &lt;/syntaxhighlight&gt;<br /> <br /> A simple ASCII JSON reader/writer program :<br /> [[JSON package]]<br /> <br /> '''Micro-controller programming'''<br /> <br /> '''Ada 83''' is a very convenient tool for micro-controller programming. The famous Arduino boards equipped with AVR chips can be programmed in '''Ada 83'''. Some examples [[Ada_83_on AVR_chips|here]].</div>

Vmo https://ada83.org/wiki/index.php?title=Welcome_to_Ada_83_Memory&diff=134 2025-03-29T15:21:26Z

<p>Vmo: </p> <hr /> <div>[[File:Ada 83 Memory.png|center|alt=Ada 83 Memory|500px]]<br /> &lt;hr/&gt;<br /> [[File:Ada Lovelace portrait.png|thumb|--- Ada Lovelace by A.E.Chalon (1840) ---]]<br /> <br /> This site aims to preserve heritage elements of the original Ada® language (now called '''Ada 83''').<br /> <br /> '''Ada 83''' is a computer programming language set in its standard in 1983, and for which a fairly formidable design effort was deployed over nearly a decade, following which the language in its original form was used in large-scale projects over the following decade. Then revisions of the language were made which certainly increased its possibilities, but at the heavy cost of rather considerable complications on an originally quite sophisticated base which proved sufficient for many applications. <br /> <br /> At the time of its availability, '''Ada 83''' was considered a “big” language, the compilation of which put contemporary machines to the test. On current systems in these 2020s, the compilation of '''Ada 83''' has become easy. <br /> <br /> The extraordinary qualities of this language are, despite its forty-one-year-old age in 2024, still of particular interest from the point of view of software engineering. Since the operating principles of digital machines have not changed so much, the '''Ada 83''' language is still perfectly usable<br /> and capable of providing services. Pascal, which predates it, is still used (albeit with object extensions), and the C language, whose contribution to<br /> software engineering cannot be considered positively transcendent, is also. <br /> <br /> At the very least, it is essential to preserve '''Ada 83''', its resources, its conceptual atmosphere, these works of human genius in the field of digital<br /> information processing.<br /> <br /> <br /> <br /> This site is thus a place dedicated to the ANSI/MIL-STD-1815A-1983 version of the Ada computer programming language ; version known today as '''Ada 83''' to distinguish it from later versions (Ada 95, Ada 2005, Ada 2012).<br /> <br /> The specification of '''Ada 83''' (the Ada Language Reference Manual) is around 175 pages long, which makes it accessible to an individual.<br /> <br /> The Ada language still exists but evolved so much that we wanted to preserve elements of the original version of the language. '''Ada 83''' is a peculiar programming universe that really deserves preservation, both for computer history purpose and as an example of a specially well designed tool for software reliability, readability, maintenance. We believe that '''Ada 83''' is still useful forty years later.<br /> <br /> <br /> This site aims at gathering [[Ada_83_history|history]] facts and [[Ada_83_tools|tools]] or [[Ada_83_examples|examples]] written in '''Ada 83'''.<br /> <br /> The interest is also about '''Ada 83''' language machines like the [[Rational_R1000_Ada83_machine|Rational R1000]] and the [[iAPX_432_Ada83_machine|iAPX 432]].<br /> <br /> Feel free to participate to the elaboration of Ada 83 Memory if you are a veteran of the 1980ies . Nonetheless be aware that only '''Ada 83''' is of interest here, no Ada 95 or later version will be considered (or only marginally if it serves an analytical purpose).<br /> <br /> [[Special:RequestAccount|You can request your account here]]</div>

Vmo