Why is Ada considered "too specialized" for scientific use
in [Fortran]
|
From: Yannick Duchêne (Hibou57) on 7 Jun 2010 08:35 Le Mon, 07 Jun 2010 12:40:07 +0200, Peter Flass <Peter_Flass(a)yahoo.com> a écrit: > If you want to talk *really* old assemblers, look at SOAP. The hardware > had no core, only drum memory, What is a âdrum memoryâ ? -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: J. Clarke on 7 Jun 2010 09:23 On 6/7/2010 5:29 AM, Shmuel (Seymour J.) Metz wrote: > In<hugevn02qfa(a)news5.newsguy.com>, on 06/06/2010 > at 11:15 AM, "J. Clarke"<jclarke.usenet(a)cox.net> said: > >> I never understood this business of making a distinction between >> machine language and assembler > > The language level. In the case of my first assembler, the > optimization. If it "optimizes" then it's not an assembler, no matter what it might be called. >> maybe they changed things after I stopped >> working with assembler but in my day it was a 1:1 correspondence > > Not by 1960. Even before the macro era you had pseudo-ops that emitted > no code and pseudo-ops that generated multiple words. So? Shortcuts to keep from having to repeatedly type a bunch of code. Don't do anything you couldn't do by hand and you are not compelled to use them. >> and the only practical difference was that someone who didn't have >> an idiot-savant ability to remember numerical codes could learn to >> work in assembler in a reasonable time. > > Maintaining your own symbol table would be labor intensive unless > you're JvN; I vaguely recall that he refused to use assemblers. He came down with cancer around the time that assemblers started to become common, too, and died shortly after, so one has to question the relevance of such an observation. > >> Perhaps he's looking for programs in microcode or something. > > ? > > FWIW, IBM used assemblers for the ROS on the S/360 and S/370; I don't > know about other vendors.
From: J. Clarke on 7 Jun 2010 09:29 On 6/7/2010 8:35 AM, Yannick Duchêne (Hibou57) wrote: > Le Mon, 07 Jun 2010 12:40:07 +0200, Peter Flass <Peter_Flass(a)yahoo.com> > a écrit: >> If you want to talk *really* old assemblers, look at SOAP. The >> hardware had no core, only drum memory, > What is a “drum memory” ? Are you serious? You remember those old Edison phonographs that used a wax cylinder? Well imagine that concept only with the cylinder coated with magnetic material instead of wax, and with a row (or several rows) of heads along its length. Has most of the properties of a fixed-head disk except the unequal track lengths.
From: Arthur Evans Jr on 7 Jun 2010 10:22 In article <huiia5$2k1$1(a)news.eternal-september.org>, Peter Flass <Peter_Flass(a)Yahoo.com> wrote: > If you want to talk *really* old assemblers, look at SOAP. The hardware > had no core, only drum memory, and each H/W instruction contained the > drum address of the next instruction to be executed. A big function of > the assembler was figuring out where to store the instructions on the > drum so that the next instruction was under the R/W head just as the > previous finished executing -- based on the instruction timings. Try > doing that by hand for a large program! SOAP was an assembler for the IBM 650, a drum machine that had 200 (NOT 2048) words on a rotating drum in 40 tracks of 50 words each. It was a one-plus-one address machine, each instruction including the address of its successor. As Mt Flass has said, SOAP (Symbolic Optimal Assembler Program) did its best to place each instruction so that it was coming under the read heads when the previous instruction finished executing. But, it did that when first the instruction was encountered in the input. If the instruction was the successor of another instruction, it wasn't likely to be optimized for this one. Thus it was in fact sometimes (rarely) worth doing that optimization by hand for frequently used pieces of code. The 650 initially had no floating point instructions, so the run time support library for IT included code to simulate floating point arithmetic. Since this package had heavy use, my colleague Joe Smith optimized it by hand, resulting in a noticeable performance increase. Yes, I know, this discussion really belongs on alt.folklore.computers, but I couldn't resist. BTW -- Don Knuth, who like me cut his programming teeth on the 650, once designed an integer-programming application to truly optimize instruction placement. I don't know if he ever actually programmed it, as he was sure it would take vastly more time to execute than it could ever save. I may misremember some of the details. Art Evans Old Codger
From: robin on 7 Jun 2010 10:30
"Peter Flass" <Peter_Flass(a)Yahoo.com> wrote in message news:huiia5$2k1$1(a)news.eternal-september.org... | If you want to talk *really* old assemblers, look at SOAP. The hardware | had no core, only drum memory, and each H/W instruction contained the | drum address of the next instruction to be executed. A big function of | the assembler was figuring out where to store the instructions on the | drum so that the next instruction was under the R/W head just as the | previous finished executing -- based on the instruction timings. Try | doing that by hand for a large program! That was done by hand for many early machines that relied on mercury delay line (or nickel) memories. Some of those progrems were gigantic. Nevertheless, done in stages (building blocks) it was managable. |