Why is Ada considered "too specialized" for scientific use
in [ADA]
|
Prev: Request for parallel computing books in comp.parallel
Next: Press Release - Reliable Software Technologies, Ada-Europe 2010
From: Peter Flass on 7 Jun 2010 17:56 J. Clarke wrote: > 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. > > That's it. I believe it was an IBM 704, although probably other old computers used them also. Drums were popular as storage on systems, even with disks, because, being head per track, they were much faster. They were often used as a swap medium. This is a little far afield for these three NGs.
From: Peter Flass on 7 Jun 2010 18:03 Fritz Wuehler wrote: >> Of course that's effectively two programs - a macro processor and an >> assembler. The PL/I preprocessor isn't tied to the language and can be >> used as a general-purpose macro processor. > > The IBM assembler macro processor *is* part of the assembler and *is* > tightly bound to the language. > Sort of. OS/360 SYSGEN used the assembler as part of its process, but it didn't really assemble anything. The sysprog coded assembler macros to specify the options he wanted included in the system, the macros were processed by the assembler, which punched a "stage 2" deck of JCL and utility control cards. The PL/I preprocessor is part of the compiler, but I have used it for macro processing completely unrelated to PL/I.
From: glen herrmannsfeldt on 7 Jun 2010 18:00 In comp.lang.fortran Peter Flass <Peter_Flass(a)yahoo.com> wrote: > Fritz Wuehler wrote: (snip) >> The IBM assembler macro processor *is* part of the assembler and *is* >> tightly bound to the language. > Sort of. OS/360 SYSGEN used the assembler as part of its process, but > it didn't really assemble anything. The sysprog coded assembler macros > to specify the options he wanted included in the system, the macros were > processed by the assembler, which punched a "stage 2" deck of JCL and > utility control cards. Yes. With the assembler PUNCH opcode you can send any string that you can create using the assembler's string processing out SYSPUNCH. (Where object code normally goes.) Also, in the early microprocessor days it was often used to assemble code for other processors. With a macro for each opcode in the target assembly laanguage, it wasn't hard to do. The assembler arithmetic operations were used to generate the little-endian absolute addresses needed. There was a program to convert the object deck output to the formats needed, such as motorola hex format (often used to write EPROMS), and another to make the listing file look like one would expect. > The PL/I preprocessor is part of the compiler, but I have used it for > macro processing completely unrelated to PL/I. It is more powerful, but less general than the C preprocessor. The input has to make some sense in terms of the PL/I syntax, where the C preprocessor will do substitutions even in what doesn't look much like C. -- glen
From: glen herrmannsfeldt on 7 Jun 2010 18:06 In comp.lang.fortran Peter Flass <Peter_Flass(a)yahoo.com> wrote: (snip) > That's it. I believe it was an IBM 704, although probably other old > computers used them also. Well, Fortran I on the 704 has the READ DRUM and WRITE DRUM statements. (That should get it back to Fortran, anyway.) > Drums were popular as storage on systems, > even with disks, because, being head per track, they were much faster. > They were often used as a swap medium. The IBM 2301 and 2303 were around for the S/370 days, but the popular swap device for S/370 was the 2305 fixed head disk. The 2xxx devices are from the S/360 generation, where 3xxx numbering was used with S/370. > This is a little far afield for these three NGs. -- glen
From: James J. Weinkam on 8 Jun 2010 02:27
J. Clarke wrote: > > The main distinction for me was that dumps don't come out in assembler. > But I never thought of machine code and assembler being distinct as a > result--just two ways to write the same thing. Your point is well taken for machines of the 60's and 70's, at least for the IBM ones with which I am most familiar. For example in 360 assembler, if you wanted to add two numbers you had your choice of A, AR, AH, AP, AL, ALR, AE, AER, AD, ADR, AXR, AU, AUR, AW, AWR and maybe a few more that I have forgotten. There was a one-to-one correspondence between each of these mnemonics and their corresponding numerical op codes.The assembly language programmer had to choose the correct mnemonic instruction to suit the circumstances. Moreover, while the assembler may have issued a warning in some cases, there was nothing to stop the programmer from using, for example, a half word op code to operate on a variable that had been defined as a full word point value or vice versa. I think the reason that many people want to make a distinction nowadays is that with processors such as the Intel 80xxx family, exactly what part of the instruction constitutes the op code is a little harder to pin down, and with an instruction such as add x,y the mnemonic op code add can generate any one of several dozen bit patterns spread varying parts of the first two bytes depending on how x and y are defined. There is definitely no one-to-one correspondence between mnemonic op codes and the bit pattern in any specific part of the machine instruction. Nevertheless, it remains true that the assembly language programmer who knows what he is about has complete control over the binary code generated, although I would venture to say that few, if any, assembly language programmers think of what they are doing in those terms most of the time. |