Re: EQU * considered harmful
Knuth's scheme wasn't relative bytes, nor instructions, nor even source code lines. It was an actual coded label with very local scope. No hazard from inserting instructions. Yes, exactly. That's what made it maintainable and not error-prone. So nothing fancy, it was something like this: JRC xxx,1R <> ...stuff... 1R DS0H ... JRCyyy,1R ...other stuff... 1R DS 0H repeated as often as you want. To be used when there is not a benefit to having a mnemonically-named label, and avoided when there is such benefit.. Peter Relson z/OS Core Technology Design
Local Labels (was: EQU * considered harmful)
On 2018-08-05, at 19:21:04, Robin Vowels wrote: > From: "Seymour J Metz" > Sent: Monday, August 06, 2018 5:52 AM > >> Technical Assembly Systemm (TASS) on the 650 had something called a program >> point. >> A program point was a one digit label, and the references to program points >> were suffixed >> with B for backwards and F for forward. It is perhaps the only thing on the >> 650 that I miss. > > You're still allowed to put 'B' or 'F' as a suffix on any label. > Do you mean TASS (does it still exist?) or HLASM. If HLASM, do 'B' and 'F' have the same semantic as in TASS, operating on the symbol reference, not on a one-digit symbol definition? The existence of multiple disparate approaches in assemblers other than HLASM is evidence of a need. There appears to be no unique best answer, but the worst answer is "none". -- gil
Re: EX
On 2018-08-05, at 19:30:25, Robin Vowels wrote:
>
> Of course. In the context, EX can modify everything.
>
> And anyway, why would you want to EX an EX?
>
Wrong question to ask a programmer. My maxim:
• Unix was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things.
• Doug Gwyn, in Introducing Regular Expressions (2012) by
Michael Fitzgerald
Don't prohibit something just because you can't envision a potential
rationale ("Why would you want ...")
However, if there's a good technical reason to prohibit it in the hardware,
such as the possibility of an uninterruptible loop in microcode, generality
bows to practicality.
-- gil
Re: EX
- Original Message - From: "Steve Thompson" To: Sent: Monday, August 06, 2018 4:21 AM Subject: Re: EX On 08/05/2018 08:13 AM, Robin Vowels wrote: From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 03, 2018 3:09 AM A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) EX can "modify" everything, but it does not modify the subject instruction. Exception, EX. Of course. In the context, EX can modify everything. And anyway, why would you want to EX an EX? That results in S0C3 on MVS or PIC 3 in any other O/S environment (DOS, TOS, VM, CMS, etc.). --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EQU * considered harmful
From: "Seymour J Metz" Sent: Monday, August 06, 2018 6:05 AM We were all very conscious of "economy in all things programming" in those days. We? I've been programming since 1960, and I was never concerned with how much space the source code took. Right, that was unimportant. And at 200 cards per minute, an extra source card or two made no difference whatever. The important things were how quickly the code ran and how easy it was to maintain. There's economy and there's false economy. A label would consume two lines of printout, Not unless you had it on an extraneous DS0H, EQU *, or equivalent, and even then an extra line on the listing was no big deal. BTW, when I started 8-character labels would have sounded like Heaven; I was used to 5-character labels and even the big powerful 7090 only had 6-character labels. Ours were only 4 characters, with one alphabetic character, R000 to R127. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EQU * considered harmful
From: "Seymour J Metz" Sent: Monday, August 06, 2018 5:52 AM Technical Assembly Systemm (TASS) on the 650 had something called a program point. A program point was a one digit label, and the references to program points were suffixed with B for backwards and F for forward. It is perhaps the only thing on the 650 that I miss. You're still allowed to put 'B' or 'F' as a suffix on any label. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EQU * considered harmful
>When labels were limited to 8 characters That was an improvement over the 5 characters that we had on the 650 or the 6 characters that we had on the 7090. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Peter Relson Sent: Friday, August 3, 2018 7:46 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful > B *+12 I have no evidence one way or the other, but I wonder whether the writers of the "old" macros that used this style did so because they liked it (I think we can all agree that we now hate it), or because they wanted to avoid clutter of the listing or clutter of the XREF due to the extra labels (thus increasing the size of the listing at a time when that translated into a real cost of printing), or whether maybe assembler F (that's the earliest IBM assembler I ever worked with) had limits that they were worried about running aground upon, or ... I wonder if it had to do with to label uniqueness. When labels were limited to 8 characters (as they were at that time), even with , maybe there was some concern about interfering with a user-created label. Nowadays, macroname_ is something we probably wouldn't mind creating as a label. Peter Relson z/OS Core Technology Design
Re: EQU * considered harmful
>We were all very conscious of "economy in all things programming" in those days. We? I've been programming since 1960, and I was never concerned with how much space the source code took. The important things were how quickly the code ran and how easy it was to maintain. There's economy and there's false economy. >A label would consume two lines of printout, Not unless you had it on an extraneous DS0H, EQU *, or equivalent, and even then an extra line on the listing was no big deal. BTW, when I started 8-character labels would have sounded like Heaven; I was used to 5-character labels and even the big powerful 7090 only had 6-character labels. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Friday, August 3, 2018 11:12 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful We were all very conscious of "economy in all things programming" in those days. A label occupied a physical punched card or 80 bytes of precious DASD space. Medium-sized (by the standards of those days) assemblies took minutes and produced large paper listings. A label would consume two lines of printout, one for the label and one for the xref (and one more if the macro were local in the source file). I can easily envision someone saying "why did you code that label??? You didn't need to do that! You could have just coded *+12" Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Friday, August 3, 2018 7:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EQU * considered harmful Peter Relson wrote: >I have no evidence one way or the other, but I wonder whether the writers >of the "old" macros that used this style did so because they liked it (I >think we can all agree that we now hate it), or because they wanted to >avoid clutter of the listing or clutter of the XREF due to the extra >labels (thus increasing the size of the listing at a time when that >translated into a real cost of printing), or whether maybe assembler F >(that's the earliest IBM assembler I ever worked with) had limits that >they were worried about running aground upon, or ... >I wonder if it had to do with to label uniqueness. When labels were >limited to 8 characters (as they were at that time), even with , >maybe there was some concern about interfering with a user-created label. >Nowadays, macroname_ is something we probably wouldn't mind >creating as a label. All good points. I think there was an element of keeping things cleaner/not having to scavenge for label uniqueness with 8-character labels. I don't remember who taught me the technique, though it must have been at UofW in the early 80s. I internalized it as "This isn't a 'real' branch-that is, we aren't going very far, just skipping a single instruction". And I would never, ever, ever consider doing it for more than one instruction.
Re: EQU * considered harmful
Technical Assembly Systemm (TASS) on the 650 had something called a program point. A program point was a one digit label, and the references to program points were suffixed with B for backwards and F for forward. It is perhaps the only thing on the 650 that I miss. Somewhat more general was the QUAL statement in IBMAP, which designated a section of code in which labels were implicitly qualified with the section name. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Peter Relson Sent: Saturday, August 4, 2018 10:23 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful >"This isn't a 'real' branch-that is, we aren't going very far..." Donald Knuth's assembler, which we had available in college in the 70's, had the concept of a "relative label". I can't remember if there was one name pattern for "forward" and one for "backward" or whether you couldn't use it for "backward". It avoided unnecessarily unreadable label names, and avoided the uniqueness problem. And when used properly (i.e., well within a "screen" amout) it was perfectly clear. The label name was like "1R" for "first one ahead, relative" or perhaps it was "find the first 1R label ahead", for example J 1R When used appropriately (as a substitue for all of these *+small_number types of cases) it avoided the maintainability problems of having to know how long everything was. By the way, I still remember being amazed at a demonstration of producing "N factorial" using IBM/360 assembler macro language (at least for small enough numbers). Peter Relson z/OS Core Technology Design
Re: EQU * considered harmful
That's better than adding the lengths up yourself, but still not as robust as using labels, either explicit or macro generated. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Friday, August 3, 2018 1:05 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: EQU * considered harmful Those were just made up instructions, not real code. The point was that I was taught that when you branch around multiple instructions, to make it clear to someone else, you can: 1) Write the *+ information so that it was obvious that there were multiple instructions and the length you expected them to be, and, 2) Indent the instructions being branched around so that, again, it is obvious that something needed to be looked at if the code was modified. Personally, adding an extra label when branching around one, or two instructions just makes the program more cluttered. One place I used this a lot is when handling errors. BL *+4+4+4 L R15,ERRNO_30303 B General_error_routine MVCX,Y (Again, just typing some example code, not actual code.) Of course, I also use GOTO in COBOL, so maybe I am just a non-standard person. Tony Thigpen Rob van der Heij wrote on 08/03/2018 12:13 PM: > I’m afraid those sequences only make sense when you wrote them, not much > later. I inherited similar attempts to code the length of data. Just don’t. > > On Fri, 3 Aug 2018 at 18:03, Tony Thigpen wrote: > >> I was taught that to make it easy to read, do the following: >> BL *+4+2 >> LR R1,R2 >> or >> BL *+4+2+4 >> LR R1,R2 >> LA R3,0(,r1) >> It may not look right in your email, but the branched around >> instructions are indented one extra character. >> >> Tony Thigpen >> >> Phil Smith III wrote on 08/03/2018 10:40 AM: >>> Peter Relson wrote: >>> >>> I don't remember who taught me the technique, though it must have been >> at UofW in the early 80s. I internalized it as "This isn't a 'real' >> branch-that is, we aren't going very far, just skipping a single >> instruction". And I would never, ever, ever consider doing it for more than >> one instruction. >>> >>> >> > >
Re: EX
On 08/05/2018 08:13 AM, Robin Vowels wrote: From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 03, 2018 3:09 AM A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) EX can "modify" everything, but it does not modify the subject instruction. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus Exception, EX. That results in S0C3 on MVS or PIC 3 in any other O/S environment (DOS, TOS, VM, CMS, etc.).
Re: EX (was: Instruction/Data Cache Usage)
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, August 03, 2018 3:09 AM A principal use of EX is to be able to use a register mask to modify the target. CDC 3800 had a clever alternative to this, a modify-next-instruction instruction (I forget what it was called). The target was always the following instruction; execution continued after that instruction -- no need to branch around. Its principal use was to enable CDC 3800 extended addressing in old CDC 3600 short-address instructions. Addressing was not otherwise modal. IBM might have done well to provide a modify-next rather than a long-address, pipeline breaking, dreadfully expensive, EX. (They probably had the discussion and had good reasons not to do it.) (Can EX modify the CC mask in a target branch instruction? A sure branch prediction breaker.) EX can "modify" everything, but it does not modify the subject instruction. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
local labels
I believe that some DEC assemblers allow local labels of the form d$ where d is a digit from 0 to 9. Local labels need to be unique between any two normal labels. References to them would, then, only work between those same labels. -- glen
Re: EQU * considered harmful
Knuth's ASSEMLER is called MIXAL, because it was designed for the hypothetical machine MIX. There are some tutorials on the web for MIX and MIXAL. The local symbols of MIXAL are described here: http://www.gnu.org/software/mdk/manual/html_node/Local-symbols.html#Local-symbols Kind regards Bernd Am 04.08.2018 um 16:23 schrieb Peter Relson: "This isn't a 'real' branch-that is, we aren't going very far..." Donald Knuth's assembler, which we had available in college in the 70's, had the concept of a "relative label". I can't remember if there was one name pattern for "forward" and one for "backward" or whether you couldn't use it for "backward". It avoided unnecessarily unreadable label names, and avoided the uniqueness problem. And when used properly (i.e., well within a "screen" amout) it was perfectly clear. The label name was like "1R" for "first one ahead, relative" or perhaps it was "find the first 1R label ahead", for example J 1R When used appropriately (as a substitue for all of these *+small_number types of cases) it avoided the maintainability problems of having to know how long everything was. By the way, I still remember being amazed at a demonstration of producing "N factorial" using IBM/360 assembler macro language (at least for small enough numbers). Peter Relson z/OS Core Technology Design
