From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6609c40f81b32989 X-Google-NewGroupId: yes X-Google-Thread: 1094ba,9bdec20bcc7f3687 X-Google-NewGroupId: yes X-Google-Thread: 101deb,e67cdb1dcad3c668 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,gid8d3408f8c3,gidbda4de328f,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.93.MISMATCH!xlned.com!feeder7.xlned.com!news2.euro.net!news.mixmin.net!aioe.org!not-for-mail From: glen herrmannsfeldt Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 Subject: Re: Why is Ada considered "too specialized" for scientific use Date: Mon, 7 Jun 2010 22:00:35 +0000 (UTC) Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: iv0FLp+Uhvv05NzXKWDP0Q.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: tin/1.9.3-20080506 ("Dalintober") (UNIX) (Linux/2.6.26-2-686 (i686)) X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news2.google.com comp.lang.ada:12425 comp.lang.fortran:26494 comp.lang.pl1:1528 Date: 2010-06-07T22:00:35+00:00 List-Id: In comp.lang.fortran Peter Flass 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