Re: Displaying port nr in decimal
From: "Robert Ngan" Sent: Wednesday, October 28, 2015 8:38 AM LH will give incorrect results for values greater than 32768. 32767. That is the largest positive value, as for LH, the most-significant bit is extended through the high-order positions. The grestest negative value is -32768. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Re: Moves and others
From: "Steve Smith" Sent: Thursday, October 29, 2015 2:28 AM I sometimes use MVCK for variable-length moves (in the same key). Usually, a preceding IPK is needed, but EXed MVCs usually require a BCTR or something. It's very convenient (especially when I don't want to decrement the length register), but has the performance warning too. It baffles me that we don't have an instruction like MVCK without the key specification. MVCL isn't good enough (not that it isn't useful in many cases) for a typical, relatively short, variable-length move. Not only do you need to set up 3 or 4 registers, it destroys them all. In the email to which you have replied, the author tells of the MVCOS instruction that seems to do what you want. On Tue, Oct 27, 2015 at 6:17 PM, Blaicher, Christopher Y. < cblaic...@syncsort.com> wrote: I did some experiments on a z196 and a z10 to determine that until you get close to several pages an MVC loop with a final executed MVC is faster. On those machines the breakeven point was 32K. The cost is because MVCL and the like are millicode instructions and there is a fair overhead to starting and ending the millicode environment. MVCL will kick into a move page shortcut when things line up on a page boundary, both source and destination, but how often does that happen? Chris Blaicher Technical Architect Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert Ngan Sent: Tuesday, October 27, 2015 5:27 PM To: MVS List Server 2 Subject: Re: Moves and others There's also MVCOS (with zero in R00 for problem state code). It also uses 2 extra registers (R00, plus a length register). I heard it was also quite slow compared to MVC, but not sure how it's performance compares to an executed MVC (or a MVC loop, plus a final executed MVC). Excluding setup, it's only a single instruction for variable length moves up to 4K. Robert Ngan CSC Financial Services Group IBM Mainframe Assembler List wrote on 2015/10/15 18:29:36: > From: Robin Vowels > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 2015/10/15 18:31 > Subject: Re: Moves and others > Sent by: IBM Mainframe Assembler List > > > - Original Message - > From: "Paul Gilmartin" > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > To: > Sent: Friday, October 16, 2015 3:16 AM > Subject: Re: Moves and others > > > On 2015-10-15, at 08:48, Robin Vowels wrote: > > > > IBM should have produced a special EXC instruction for characters, > > that did what EX does, but accepts k, the number of bytes to move > (or compare, etc), > > tests for zero (and performs a no-op if it is), subtracts 1, and > then executes MVC. > > MVCL? > > Kind of overkill for small moves. > 4 registers! --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Re: Review My Program
From: "David S." Sent: Tuesday, December 15, 2015 5:42 AM Why do you use LM and STM to load the fields in to registers and then out to memory again, rather than just using MVC for a “memory to memory” move? ... [eg] MVC ARG1(ARG1_L),CONSTS MVC will work. And all else being equal, fewer instructions usually are better. And what's more, they don't modify registers. But! In performance discussions on LinkeIn's "Mainframe Assembler Professionals" group, like this one: http://www.linkedin.com/groups/1462937/1462937-91082881 ... ...I've learned that LOAD/STORE sequences (IC/STC, L/ST, LM/STM) are much faster than an equivalent length MVC. See comments in the above discussion such as: "CLC (like MVC) is very fast - but only after a start-up penalty. In the MVC case using two LG/STG is much faster than a 16 byte MVC..." and "There is a good reason why small MVCs run slower than LG/STG pairs. There is a bunch of overhead at the beginning of a MVC. Just one example: you have to check if the operands are on "good" boundaries. If not, you tiptoe your way to a good boundary. Then you can rip. Have to check for operand overlap conditions. There is a length check involved. During this time the LG/STG is far on its way. Some IBM machines (if I remember correctly) also had a bigger fetch/store path for MVC. Again, once it got going. I can assure you that a LG/STG pair is faster than a 16 byte MVC. Anyone writing a length-1 MVC instead of an IC/STC would be laughed out of their code review. Rubbish. KISS. A move of length 1 is clear and unequivocal. And it's only one line. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Review My Program
From: "Elardus Engelbrecht" Sent: Wednesday, December 16, 2015 8:16 PM Robin Vowels wrote: But! In performance discussions on LinkeIn's "Mainframe Assembler Professionals" group, like this one: http://www.linkedin.com/groups/1462937/1462937-91082881 ... ...I've learned that LOAD/STORE sequences (IC/STC, L/ST, LM/STM) are much faster than an equivalent length MVC. See comments in the above discussion such as: "CLC (like MVC) is very fast - but only after a start-up penalty. In the MVC case using two LG/STG is much faster than a 16 byte MVC..." and "There is a good reason why small MVCs run slower than LG/STG pairs. There is a bunch of overhead at the beginning of a MVC. Just one example: you have to check if the operands are on "good" boundaries. If not, you tiptoe your way to a good boundary. Then you can rip. Have to check for operand overlap conditions. There is a length check involved. During this time the LG/STG is far on its way. Some IBM machines (if I remember correctly) also had a bigger fetch/store path for MVC. Again, once it got going. I can assure you that a LG/STG pair is faster than a 16 byte MVC. Anyone writing a length-1 MVC instead of an IC/STC would be laughed out of their code review. Rubbish. What part of above paragraph you're referring to is rubbish? The final sentence. That should have been clear from my lines that followed. >For my part, I'm also struggling to swallow that paragraph. I would rather read formal bookies confirming those statements. KISS. A move of length 1 is clear and unequivocal. And it's only one line. Indeed, if you're thinking of MVI instead of MVC. MVI is irrelevant to the discussion. In the context of the post and in particular the long paragraph, I was referring to MVC to move one byte. BTW, one common use of MVC is to propagate a byte (or two or three or four) through an area :- MVC A+1(5),A MVC B+2(10),B --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: One Byte MVC Versus IC/STC
From: "David S."
Sent: Thursday, December 17, 2015 6:10 AM
> "... a good reason why small MVCs run slower than LG/STG pairs ...
> overhead at the beginning of an MVC ... check if the operands are on 'good'
> boundaries ... check for operand overlap ... length check ...
[meanwhile] the
> LG/STG is far on its way. Anyone writing a length-1 MVC instead of an
> IC/STC would be laughed out of their code review.
Rubbish.
KISS.
A move of length 1 is clear and unequivocal.
And it's only one line.
Nevertheless, IC/STC is what the newer mainframe compilers generate for a
one-byte move. For the reasons given, it's less work for the system than
an MVC.
If that was the only criterion ("less work for the system") we'd never
use any of the more complex instructions that were designed to
simplify the task of the programmer and which help him/her to
write and maintain programs easily.
Most of the time, you wouldn't notice any time difference.
But using two instructions (where one would suffice) increases
memory traffic and increases program bulk.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: load logical halfword immediate
From: "Swarbrick, Frank" Sent: Friday, January 22, 2016 8:08 AM IILF is not a "problem". I was simply wondering if there was something similar where the immediate value stored in the instruction was only a halfword instead of a fullword. As for LAY, I'm not a particular fan of using an instruction named after one particular function (load address) to be used for a less obvious function (loading an "immediate" value). In LA, the address field IS an immedate value. Of course it's well-known that LA is used for this; but it still strikes me as being non-obvious. If you don't like it, write your own macro. Or use one of the suggestions. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: load logical halfword immediate
From: "Swarbrick, Frank" Sent: Thursday, January 21, 2016 6:21 AM Is there any such instruction? This would be an instruction that would: - Be a register-and-immediate instruction, with a halfword immediate value as the source. - Load the halfword in bytes 48-63. bits? - Load zeroes in bytes 32-47. - Leave bytes 1-31 unchanged. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: LA
From: "Swarbrick, Frank" Sent: Friday, January 22, 2016 8:08 AM As for LAY, I'm not a particular fan of using an instruction named after one particular function (load address) to be used for a less obvious function (loading an "immediate" value). LA is commonly used to increment the content of a register by 1, 2, or 4, which s handy when the register has a value used for indexing. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Microprocessor Optimization Primer
From: "Gary Weinhold" Sent: Tuesday, April 05, 2016 12:24 AM Even if there's no actual performance difference for these instructions, wouldn't the "not setting the CC" possibly improve the pipeline, since the hardware knows the next conditional branch does not have to wait for this instruction to be evaluated for affecting the CC? Usually a register is cleared because you are going to add or subtract something to/from it, most times pretty soon after. As adding/subtracting something is going to set the CC, the pipeline isn't going to be held up in any significant way. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Microprocessor Optimization Primer
- Original Message - From: "Ed Jaffe" Sent: Tuesday, April 05, 2016 12:50 AM On 4/4/2016 7:24 AM, Gary Weinhold wrote: Even if there's no actual performance difference for these instructions, wouldn't the "not setting the CC" possibly improve the pipeline, since the hardware knows the next conditional branch does not have to wait for this instruction to be evaluated for affecting the CC? Indeed! Avoiding CC "interlock" is exactly why an entire suite of "compare and branch" instructions were created! :-) However, that should not apply in this situation since SLR sets the CC in exactly the same way as all other logical subtract instructions. Both SR and SLR set the CC. Only the meaning of the bits is different. Um, the bits are all zero after clearing the register with SR and SLR --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: My assembler text v2.00
From: "Jeremy Stone" Sent: Friday, April 15, 2016 10:51 PM To address previous thoughts, the Assembler Language textbook is copyright IBM property. That is so; it says so in the document. The current plan is assign a SRL to it and add it to the High Level Assembler library once it has been converted from Bookmaster format. Bookmaster format? It's in PDF format. We will also look at the various samples and see how best to ship them as samples in the Assembler library. Jeremy Stone HLASM Development and Support IBM Hursley --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Friday puzzle: CNOP 1,2
From: "Ngan, Robert" Sent: Saturday, August 20, 2016 4:47 AM I'm writing a macro to build length prefixed character strings. The length is one byte, and the actual string is referenced by LARL so it needs to be halfword aligned. So I coded (what would be a CNOP 1,2 - if it was valid): DC(1-(*-&SYSECT)/2)X'00' Simulate a CNOP 1,2 However, this generates ASMA067S Illegal duplication factor. what's wrong with DS 0H followed by DC X'00' or some such? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: MVHI vs XC to "zero" a halfword.
When all else fails, there is always SR 0,0 and STH 0,X Or even 2 MVIs. - Original Message - From: "John McKown" To: Sent: Friday, January 13, 2017 1:42 AM Why am I asking this? Because I just installed a product on our, very old, z9BC. Said product's documentation said it was supported on a Z9. But it abended S0C1 on the instruction: E54C 1000 (MVHI 0(1),0). I looked this up and it appears to be part of the "general instructions extension facility", which came in on the z10 class. Now, I know this code was likely generated by the C compiler (given the, unnamed by me, vendor). But this seems to be what I would expect to be from something like the C code: short int somevar=0; So I guess that is the reason: a general template which uses MVHI to set a halfword integer to a constant value. But, in the case of hand crafted assembler, would an MVHI be "better" than an "old style" XC for some reason? I am thinking speed, having the operand in the i-cache, and so forth. Or is an XC of a region with itself "optimized" in the hardware to not actually fetch the data and do an XC operation because the result is always b'000...' regardless of the operand? Maranatha! <>< John McKown --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: HLASM anomaly
From: "Steve Thompson" Sent: Thursday, February 23, 2017 11:55 PM What does "immediate" mean to you? In this case, it means immediately available within the instruction itself. Replication would then expand outside of the instruction Why? It is an Immediate instruction. and into the instruction stream. That would then cause the next byte, beyond the instruction, to be an OPCODE by instruction fetch (IF) using the PSW's Instruction counter (IC). When an instruction is fetched, the IC is advanced by the length of the instruction -- which is based on the OP code (it defines the length of the instruction). Accordingly, there is nothing in the instruction to tell IF that this instruction has a different length for updating the IC. It would help to read the Principles of Operations manual for more than just the instructions that you want to use. Understanding how the machine actually works can keep you out of trouble and make use of nuances at the same time. Regards, Steve Thompson --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: 50 year old assembler code still running.
- Original Message - From: "Tony Thigpen" Sent: Saturday, March 11, 2017 11:52 PM I am working on some REALLY old code. Some of the code has dates back in 1967! The oldest date found is 5/9/67. This code is still running daily. That's as good as 50 years later. The only reason we are touching the code is because we are migrating this application from z/VSE to z/OS. I don't know the original operating system, but I expect it was DOS/360. But, it could have been an early OS/360. Looks like DOS-style code. Anyway, I am seeing some code that am interested to know about, historically. For instance, it appears that USING could not support multiple registers. I see this code sequence in the 'start' macro: USING *,3 ESTABLISH REG 3 USING *+4095,4AND REG 4 USING *+2*4095,5 AND REG 5 AS BASE REGS Also, it appears that R15 was not standardized to have the programs entry address because they used: &NAMEBALR 3,0 INITALIZE REG 3 LA3,0(3) BCTR 3,0 BCTR 3,0 DOS machines did not usually have heaps of memory, so it is surprising to see wasted bytes like the above. LA4,4095(3) AND REG 4 LA5,4095(4) AND REG 5 (FYI: The above code snippets were contiguous.) Also, when they needed to call a subroutine, it appears they did not yet have =A(xxx) constants, because they had to manually adjust the address: L 15,=V(UPSI) LOAD REG 15 WITH UPSI ROUTINE ADDRESS AR15,3 ADD RELOCATION FACTIR FROM REG 3 BAL 14,4(15) BRANCH TO UPSI RETURN IN REG 14 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Structured programminng macros
From: "Pieter Wiid" Sent: Monday, May 15, 2017 6:36 PM Branch to iterate is what I would LIKE. You could try a BCT, or BXLE etc instruction. There is not such structure as the moment. If nobody else wants to play with it, I will try to work on it when done with my current upgrade cycle. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: random quest
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Thursday, May 18, 2017 8:02 AM On 2017-05-17, at 12:59, Martin Ward wrote: On 16/05/17 23:46, Richard Kuebbing wrote: This takes O(n) time, as opposed to O(n log n) for Peter's "generate and sort" method. With only 99,999 numbers the extra CPU time may not be significant, depending on how often you need to generate a sequence. Presuming that the table fits in main memory. On the first mainframes I used, 99,999 wouldn't have fit. You don't need to store all the numbers. One buit for each number was sufficient. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Question about CPUs
From: "Robert Netzlof" Sent: Monday, July 31, 2017 11:07 AM On 7/30/17, Phil Smith wrote: Charles Mills wrote, in part: The effect of multiple CPUs on a multi-task program is even worse than the load, add, store example above. With two CPUs, it is possible for even single machine instructions to interleave. So if one task executes MVC FOO,=C'Now is the time for all good men to come to the aid of the party' and another CPU executes MVC FOO,=C'The quick brown fox jumps over the lazy dog' it is at least in theory* possible for FOO to end up containing 'Now is the time fox jumps over the lazy dog the aid of the party'. Mmm...I'm pretty sure a single instruction is still atomic. I'm sure Peter Relson or one of the other IBMers will chime in, but it there has to be some sort of interlock at some level. And I've debugged plenty of concurrency problems, never seen a mixture from a single instruction! ...phsiii Not sure, but is not MVCL interruptible? MVCL, CLCL etc are interruptible. They have to be. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Question about CPUs
From: "Charles Mills" Sent: Monday, July 31, 2017 2:57 PM Nay. Many, many instructions are not atomic. On a single CPU, yes. For multiple CPUs, not atomic. Until the z13 (?), for example, NI, OI and XI were interruptible within a reference to a single byte. NI is actually fetch, AND, store. It could be interrupted between the fetch and the store. What about the decimal instructions? such as AP, SP, MP, DP, and others such as NC, OC ? So two processors doing NI or OI on the same byte could get "logically impossible" results. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Question about CPUs
From: "Gary Weinhold" Sent: Tuesday, August 01, 2017 12:16 AM I think (TS) Test and Set was/is atomic and AFAIK was the earliest implemented atomic instruction. I think that the entire /360 user instruction set would have been of that kind. AFIK there was no provision to suspend any instrction and to resume it after an interrupt. The instruction had to be allowed to complete, and the IAR saved, so that when control was passed back to the interrupted program, the next instruction was executed. I think it addressed the requirement to allow interruptible code to fetch, test, and modify a single byte on a single CPU machine with integrity. An external or I/O interrupt could undermine the integrity of a TM, Bx, OI/NI instruction sequence in that environment. Gary Weinhold Senior Application Architect --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: converting character to packed
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, October 24, 2016 5:49 AM On 2016-10-23, at 06:05, robi...@dodo.com.au wrote: Monetary fields tend to have the finny characters in known positions, commas (or periods)every third position. The decimal point (period or comma) also is in a fixed position.All these are in fixed positions relative to the least significant digit of the amount. But the currency symbol floats unless you have leading zeroes for a fixed width. A drifting currency symbol, if it exists, can be dealt with trivially with TRT. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Source address significance for clearing MVCL
From: "Charles Mills" Sent: Thursday, August 17, 2017 11:00 PM I don't see this explicitly in the PoOp. Is my recollection correct? That for a "pure clearing" MVCL (source length zero, destination length non-zero) the contents of source address register R2 are not significant, and a specification or access exception on the source address is not possible? Kacmar (Assembly Language with Assist) gives a specific example for this case. The source addres is set to zero, the source length is set to zero; only the fill character is required. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Source address significance for clearing MVCL
From: "Charles Mills" Sent: Friday, August 18, 2017 12:33 AM Address 0 is a legal fetch address. The question is can I get away with not worrying about what is in the source address register? What, for example, if it points to a non-address or to something that happens to be fetch-protected. (Code is 64-bit FWIW, but I doubt that matters, other than increasing the number of potential invalid addresses.) Obviously not the world's biggest deal, of course. One LHI R2,0 every now and then is not going to kill me. Try SR R2,0 You will probably need two. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Source address significance for clearing MVCL
From: "Charles Mills" Sent: Friday, August 18, 2017 12:33 AM Address 0 is a legal fetch address. The question is can I get away with not worrying about what is in the source address register? What, for example, if it points to a non-address or to something that happens to be fetch-protected. (Code is 64-bit FWIW, but I doubt that matters, other than increasing the number of potential invalid addresses.) The example and explanation on page A-25 makes it clear that the content of the even register (source address) are irrelevant when the source length is zero. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Source address significance for clearing MVCL
From: "Charles Mills" Sent: Friday, August 18, 2017 1:04 AM I'd need a whole lot more than two SR R2,0's. Obviously I meant SR R2,R2. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Source address significance for clearing MVCL
From: "Steve Smith" Sent: Friday, August 18, 2017 2:04 AM HLASM doesn't do "obviously I meant" (aka DWIM). So, you are an HLASM, not a real person. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z14 PoO Available
From: "Abe Kornelis" Sent: Sunday, September 24, 2017 12:25 AM In the new PoO (Publication SA22-7832-11) I noticed that opcode B93C has changed it's mnemonic from PPNO to PRNO - probably to reflect it's new ability to perform True Random-Number Generation. For compatibility the PPNO mnemonic is still mentioned in the instruction's description. Nevertheless, the PPNO mnemonic has disappeared from the appendix B. This holds for figures B-1, B-2, and B-3. Isn't it strange that a supported mnemonic is omitted from the appendix? Or was the PPNO mnemonic inadvertently maintained in the instruction description? It seems likely that PRNO is a better mnemonic, and that the old one PPNO is being phased out. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z14 PoO
From: "Abe Kornelis" Sent: Saturday, September 23, 2017 11:56 PM In the new PoO (Publication SA22-7832-11) I noticed something peculiar. On page 7-308, in the left-hand column (relating to Multiply Single), second bullet, last sentence but one it is stated: For MSG and MSGC, the multiplier is a 64-bit signed binary integer, respectively, at the second-operand location in storage. Knowing that it takes extreme precision to read the PoO correctly, I am wondering about the meaning of the word "respectively" in this sentence. It seems superfluous. Am I mistaken? If so, then what is its significance? It seems to be superfluous, and its presence only confuses. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Hex dump (was Detection of Compile-Time Self-Modifying Code)
From: "Ed Jaffe" To: Sent: Wednesday, October 11, 2017 1:49 AM On 10/10/2017 2:49 AM, retired mainframer wrote: Has your legal team considered the possibility of industrial sabotage? It would be pretty hard to argue that this defective code was accidental. It's funny. Someone joked about that just yesterday, wondering if this person was collecting two salaries! LOL I know he felt "shackled" by OPTABLE(YOP) and was always pushing for me to raise our hardware support minimums. I wouldn't do so for the reasons I have already explained. Honestly, I think he just really, Really, REALLY wanted to use TROT to generate a hex dump of bytes instead of the "tried and true" UNPK/TR we use everywhere else throughout our code. UNPK might ne OK for small areas, but TR without UNPK is far better. I suspect he rationalized his subversion by saying to himself, "Oh, Ed's just being silly. Nobody runs hardware like that anymore..." and, in doing so, once again raised his defiant insubordination to the level of potentially jeopardizing our customers' businesses (and OURS!). [Aside: You'd be surprised how old some hardware is in DR sites, even in very, very large companies with massive budgets! And, nothing is worse than having mission critical software fail in DR!] --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: One Byte MVC Versus IC/STC
From: "David S." Sent: Thursday, December 17, 2015 6:10 AM > "... a good reason why small MVCs run slower than LG/STG pairs ... > overhead at the beginning of an MVC ... check if the operands are on 'good' > boundaries ... check for operand overlap ... length check ... [meanwhile] the > LG/STG is far on its way. Anyone writing a length-1 MVC instead of an > IC/STC would be laughed out of their code review. Rubbish. KISS. A move of length 1 is clear and unequivocal. And it's only one line. Nevertheless, IC/STC is what the newer mainframe compilers generate for a one-byte move. For the reasons given, it's less work for the system than an MVC. It's a question of what is easiest and simplest for the programmer. Machines are supposed to do the work for us, not the other way around. Why write two lines when one will do the job? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Using the High Halfs of registers
From: "Tony Harminc" Sent: Saturday, October 28, 2017 11:13 AM On 27 October 2017 at 19:31, Wendell Lovewell wrote: ... Sorry for all the background. What I'm looking for are "high-half" versions of LA and BCTR commands, so that the incrementing and decrementing could be done with 2 statements per CSECT--without affecting the low halves of the register. For example in 31-bit land if R2 was always available, I could say "LA R2,1(R2)" at the start of the modules, and "BCTR R2,0" at the end. In this case reg 2 would always be the stack level. Add Immediate High (AIH). But when was it introduced...? There are no change bars in the -10 edition of the PofO, so before then. Wouldn't it be necessary to clear the high half first? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: edmk instruction
From: "Gray Gregory" Sent: Thursday, November 02, 2017 11:44 PM True and this way is simpler to bad there isn't a fill character for padding with zeros The fill character to pad with zeros was given to you: "F0" --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: edmk instruction
From: "Gray Gregory" Sent: Thursday, November 02, 2017 11:44 PM True and this way is simpler to bad there isn't a fill character for padding with zeros P.S. The fill character must be the first in the pattern. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EDMK instruction
From: "Gray Gregory" Sent: Friday, November 03, 2017 2:22 AM What does your edit pattern looks like, I tried it with the X'F0' but the job abend with a S0C7 You were given several EDMK patterns. It's time you showed your code including the pattern. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EDMK instruction
From: "Charles Mills" Sent: Friday, November 03, 2017 1:03 AM I believe the fill character may be any character whatsoever. It can be any character. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: edmk instruction
From: "Gray Gregory" Sent: Thursday, November 02, 2017 11:44 PM True and this way is simpler to bad there isn't a fill character for padding with zeros The fill character for padding with zeros is 'F0', that is, zero. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: edmk instruction
From: "Gray Gregory" Sent: Thursday, November 02, 2017 4:56 PM Great link, thanks but my question is, is there a fill character that will pad the pattern with zeros. I've even tried X'F0', and X'00' as the first character in the pattern. '00' can't do it because it is not a printable character. 'F0' as a fill character (the first in the pattern) will do it. You need to have the digit force character '21' as the second character in the pattern. To make this go, you will need a receiving field of length 2 more bytes than you want, and then ignore the first two bytes. from Greg Gray gregory.g...@irs.gov 2406131660 -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@listserv.uga.edu] On Behalf Of David Woolbright Sent: Wednesday, November 01, 2017 4:57 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: edmk instruction Check out this link for general info about EDMK with examples: http://csc.columbusstate.edu/woolbright/Instructions/EDMK.pdf On Wed, Nov 1, 2017 at 4:24 PM, Steve Smith wrote: Maybe for you, but not in general. On Wed, Nov 1, 2017 at 4:05 PM, Pieter Wiid wrote: > If you have a x'21' in the edit pattern, you may as well use ED instead of EDMK. -- Dr.David E. Woolbright Professor of Computer Science TSYS School of Computer Science Columbus State University 4225 University Avenue Columbus, Georgia 31907-5645 (706) 580-9863 woolbright_da...@columbusstate.edu --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EDMK instruction
From: "Steve Smith" Sent: Thursday, November 02, 2017 7:24 AM Maybe for you, but not in general. For the OP's purpose, ED is sufficient. On Wed, Nov 1, 2017 at 4:05 PM, Pieter Wiid wrote: If you have a x'21' in the edit pattern, you may as well use ED instead of EDMK. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: EDMK instruction
From: "Steve Smith" Sent: Thursday, November 02, 2017 6:30 AM Yes, probably thousands have. "No success" is rather vague. MVC CL15,x'f0f0202020202020202020202020202020' EDCL15,PL7 Haven't checked, but you might need a X'21' character as well or instead of the second X'F0' UNPK CL15,PL7 would also accomplish this task, as you're not really using any of ED's power. You'll also need to zap the least significant byte to produce a zone code of X'F'. On Wed, Nov 1, 2017 at 3:07 PM, Greg Gray wrote: I have a field PL7 that contains a number (dollar amount) and I have to output that amount into a CL15 output field. The customer would like for the remaining characters other than the digits for the amount to be zeros, i.e., 0012391. I am trying to code a EDMK pattern with no success, has anyone ever completed such a task? -- sas --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: ASSEMBLER-LIST Digest - 8 Nov 2017 to 10 Nov 2017 (#2017-126)
From: "John Ehrman" Sent: Sunday, November 12, 2017 4:34 PM You could take an alternate view: anything with a sign is an expression. So, the decimal value of 2**32-1 could be treated as a self-defining term. The same issue sometimes arises when people discuss the difference between X'' and 65535 -- if System/360 had been a 16-bit machine, would the maximum value of a decimal self-defining term be 32767? Well, there was such a beast, but it wasn't called S/360, but System 4. The model 30 had the 16-bit instruction set, plus a DH (Divide Halfword). The System 4 was built under licence to RCA who built the RCA Spectra, a 360 look-alike. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Load module
From: "Steve Smith"
Sent: Tuesday, November 14, 2017 1:08 AM
PL/I (F) has(had) both static and dynamic ("transient" was the term
used) parts of its library. All the IEM** modules are parts of the
compiler... all those little modules were because it had to run on a
256kb machine (which is what F-level means -- iirc) The library
modules were prefixed with IHE.
No, PL/I (F) ran in 128K, and may have run in lesser storage.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: EBCDIC: was [EXTERNAL] Re: Access registers
- Original Message - From: "Swarbrick, Frank" To: Sent: Tuesday, December 05, 2017 10:17 AM I think someone else said it was choosing EBCDIC over ASCII. Personally I think that one's worth, because apparently it will never be "fixed". EBCDIC was the outcome of using punch cards, and the ease of translating the 4-zone codes to 8 bits. With ASCII and paper tape, it was an entirely different story, with contiguous 8-bit representations for letters of the alphabet, and other convenient groupings. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Access registers
From: "AFG" Sent: Wednesday, December 06, 2017 7:41 AM On 2017-12-05 11:11, Chris Craddock wrote: Ironically, OPEN ends up making a copy of the DCB in protected storage anyway, so they didn't save anything by putting it in user key storage. In 1970 "our" S360/50 made no such copies! OS/MFT gobbeled up 28 of the 256K, leaving 14K for the printer partition, 54K for the reader/interpreter partition and two 80K partitions for production, compiles and tests. What luxury! Our 360/50 had only 128K for all those things plus programs. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Address of a =LITERAL
From: "Charles Mills" Sent: Sunday, December 10, 2017 5:15 PM Yeah. Also LARL only works for even addresses. What happens (too lazy to test) if I code LARL R1,=X'012345' and the literal would fall on an odd address? Use ORG appropriately. Is the assembler smart enough to bump it to an even address? Or do I get an assembly error on the LARL? Seems odd to me that they limited LARL to even addresses. For Branch Relative it makes sense; for Load Address Relative not so much. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Adcon (was: Address of a Literal)
From: "Mike Shaw" Sent: Monday, December 11, 2017 8:31 AM I know adcons are relocatable in the sense that they are resolved to a virtual storage address when the load module is loaded and executed; The value of the actual address is determined at program load time, when the origin of the program has been determined (and not at run time). --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Address of a Literal
From: "Ed Jaffe" Sent: Monday, December 11, 2017 8:47 AM On 12/9/2017 3:38 PM, Phil Smith wrote: Of course, so-called "high-level" languages like C should be so lucky as to have the power of assembler macros! Their idea of a "macro" is really quite primitive. Agreed! HLASM macros might very well be the most powerful pre-processor language in existence... Probably not. The preprocessor in PL/I provides a host of facilities. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Any real need for sequence numbers in 73-80 any more?
From: "John McKown" Sent: Tuesday, December 12, 2017 12:53 AM I know that in the past, they were handy for when you dropped your deck of physical cards. And if guess that they can still be handy if you distribute source modifications in a format suitable for processing by IEBUPDTE, like IBM does at times. But I'm having trouble figuring out why I would want to do this with my own code. The reason I'm even considering stopping is because I really prefer to keep my HLASM code in a UNIX directory rather than a PDS. Are they not useful when you have macro calls in the code? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Paul Raulerson" Sent: Friday, January 26, 2018 6:48 AM On Jan 25, 2018, at 06:53, Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: On Wed, 24 Jan 2018 22:54:49 -0600, Paul Raulerson wrote: On Jan 24, 2018, at 10:14 AM, Seymour J Metz wrote: Like many old sayings, it's worth what you paid for it. The z instruction set includes operations far more powerful than anything in C, and the lack of a Turing complete macro language makes C highly inflexible. I am not sure that really makes sense. What exactly do you feel is “more powerful” about the zArch instruction set than “anything” in the C language? You can't find any of the more than 1100 instructions in the z/Architecture instruction set that are more powerful than any C language constructs? Nope. Care to share your opinion with more specifics? I looked at string manipulation and standard math. Take a look at TRT, TR, ED, EDMK. PACK and UNPK can do useful things too. The 50-60 basic instructions, along with the grande counterparts, all are pretty simple and comparative. The C language was actually modeled on the PDP-11 instruction set A very primitive instruction set compared to the current z/Architecture instruction set. At the time, both instruction sets were roughly equivalent. Of course, PDP-11 development stopped about 30 years ago, while IBM HLASM has continued to develop, expand, and gain new capabilities. As for Macros, well, C macros are generally much simpler than HLASM, though with good reason. Yes, it was easier to code. Um, no. I believe HLASM macros were developed more because the mainframe compilers were originally designed as multi pass compilers because of resource limitations. Compile this phase, load a tape. Compile another phase, load another tape. Not on our system /360. Certainly multi-pass compilers were in use. Magnetic tapes, when used, were for receiving distribition materials, and for sending similar stuff to other sites. And so on... C did not have those same limitations, probably because C is about 10 years younger than IBM 360 assembler. Unix at AT&T Bell Labs was originally billed as a text processing system, which it did very well. But that was kind of a smokescreen to justify the development of Unix and C at Bell because Multics was going away. I think it is plain silly to think HLASM is always superior for development purposes to other languages, including C. In some cases it is superior - such as when bottom up development is called for. It can even fit in well in an Agile/SCRUM environment for goodness sake! And, to top it all off, it is great fun to program in. But in many cases, other languages are far more efficient to use.It is not a good or bad thing, it just is. There are ways to increase the usability of HLASM in those sub-optimal use cases, such as usi structured macros. But you often find a lot of resistance to things line that from the HLASM community, and it takes the focus off accomplishing what has to be done and moves it to how to do it. Square Hole, Round Peg type of thing I think. :) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Tom Marchant" <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> Sent: Saturday, January 27, 2018 4:51 AM On Thu, 25 Jan 2018 13:48:32 -0600, Paul Raulerson wrote: On Jan 25, 2018, at 06:53, Tom Marchant wrote: On Wed, 24 Jan 2018 22:54:49 -0600, Paul Raulerson wrote: You can't find any of the more than 1100 instructions in the z/Architecture instruction set that are more powerful than any C language constructs? Nope. Care to share your opinion with more specifics? Shmuel mentioned CDS. Even System/360 had TS. And MVO and MVN (plus the others that I already mentioned). --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On 31/01/2018 3:27 AM, Jon Perryman wrote: On Tuesday, January 30, 2018 8:05 AM, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > Gil wrote: > Which of the two is to blame for null-terminated strings? > (Or was it BCPL?) Exactly my point. I suspect that the C group considered Null-terminated strings cost exactly the same as fixed length fields. Ask a C program to code MVC (memcpy) and string copy (strcpy) in C (not assembler). MVC is loop thru each byte until length reached. String copy is loop thru each byte until X'00'. As an FYI, MVC could be faster in some situations. But if you just want the length, a fixed-length string wins. In PL/I, a varying-length string also wins, because the current length is kept with descriptor, so it isn't necessary to search through the string in order to find the end. XPL was the same.
Re: Fair comparison C vs HLASM
On 31/01/2018 3:43 AM, Jon Perryman wrote: Tom Marchant wrote: Well, ok, null-terminated strings are a booby-trap included in the C language. But it was poor programming that caused the problems. I'm not sure how strings could be attributed to poor programming. Unix & C were designed and implemented around RISC processors. Instructions are limited to dealing with a single byte. In this situation, strings are far more optimal compared to fix length fields. IBM hardware changed that by implementing instructions like CLC and MVC. The MVC and CLC instructions of the IBM /360 came years before Unix and C. And I understand that RISC processors came long after C.
Re: Fair comparison C vs HLASM
From: "Keith Moe" Sent: Tuesday, January 30, 2018 11:08 AM One of the downsides to such great optimization is the added difficulty in debugging. Such optimisations are rarely requested during debugging, when all the facilities of the compiler - such as subscript bounds checking, check for uninitialized variables, etc, are employed. Programs will often have code that leaves footprints and saves various values in work areas for diagnostic reasons. They might, but at run time, should an error occur in a PL/I program the error-recovery unit can print the values of any requested variables. Also, for diagnostic purposes (either during debugging or during production), values can be written to a file. Many optimization algorithms will detect that these area are "never referenced" after being set and eliminate the code that sets or stores these values. See previous note. Another optimization that makes debugging difficult is the inlining of subroutines that are only called in one place to save the overhead of the linkage. But the generated mapping of the source to the generated machine code/assembler does not match the original source statements to the generated machine code. I suppose it is possible, but the PL/I optimising compilers clearly show where any moved code is placed. This is shown in the assembler listing. Sure, there are various tricks that can be done to prevent such optimization, Such as not requesting optimising. but that partially defeats the value of using a high level language when you have to think about how to defeat it. When you spend a lot of time debugging problems occurring in customer production environments, life can be difficult. See earlier note about printing values from the error-recovery unit. Optimization is great until it isn't! Keith Moe Lead Developer BMC Software, Inc. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
On 31/01/2018 2:53 PM, Paul Gilmartin wrote: On 2018-01-30, at 21:21:49, Robin Vowels wrote: The MVC and CLC instructions of the IBM /360 came years before Unix and C. ... and were available on all but the most primitive S/360 models. The 360 model 30 had MVC and CLC. I believe that nowadays the z has strlen() and strcpy() in microcode. And I understand that RISC processors came long after C. Me, too.
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Wednesday, January 31, 2018 3:19 PM Robin Vowels wrote: And I understand that RISC processors came long after C. C was developed on a PDP-11. I believe that the PDP-11 was a RISC machine. Even so, I think it had byte instructions. The PDP-11 was NOT a RISC computer, it was a CISC (Complex Instruction Set Computer). It had a variety of instruction formats, and various instruction lengths. RISC computers are characterised by instructions of a fixed length, each of which can be executed in a fixed amount of time. The various stages of the instruction fetch and execute cycle can be overlapped with other instructions. This genre (RISC) was not developed until many years later. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, January 31, 2018 3:48 PM On 2018-01-30, at 21:17:05, Robin Vowels wrote: On 31/01/2018 3:27 AM, Jon Perryman wrote: Exactly my point. I suspect that the C group considered Null-terminated strings cost exactly the same as fixed length fields. ... But if you just want the length, a fixed-length string wins. In PL/I, a varying-length string also wins, because the current length is kept with descriptor, so it isn't necessary to search through the string in order to find the end. And strings with descriptors (address, length) make it easy to define substrings. Just create a new descriptor. A C partisan once told me, just save a character, overlay it with a NUL, then put it back when you're done with the substring. I've used a language that defined substrings by creating descriptors, then handled garbage collection properly -- any byte not governed by one or more descriptors was subject to reclaim. That is how strings are implemented in XPL (from c. 1966). A substring was obtained by merely pointing a descriptor at the first character ; the required number of characters being inserted in the descriptor. No characters of the string were moved. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Thursday, February 01, 2018 1:49 AM On Wednesday, January 31, 2018 1:00 AM, Robin Vowels wrote: From: "Keith Moe" Sent: Tuesday, January 30, 2018 11:08 AM Keith Moe wrote: One of the downsides to such great optimization is the added difficulty in debugging. Robin Vowels wrote: Such optimisations are rarely requested during debugging, when all the facilities of the compiler - such as subscript bounds checking,> check for uninitialized variables, etc, are employed. Keith is talking about dump analysis. Perhaps. But even if he was, the link map and assembly listing deals with that issue. However, as I said, optimising is not usually requested during debugging. Think of optimization as a chaotic programmer. The stronger the optimization, the more chaos. The best optimization will often make following the machine logic very difficult. The last time I used a dump to find bugs in a compiled program was about 35 years ago. PL/I provides all the information required because it has debugging facilities built in. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Glen" To: Sent: Thursday, February 01, 2018 3:10 AM Subject: Re: Fair comparison C vs HLASM The 360/20 has MVC and CLC, but, strangely, not LR. The model 20 was not strictly of the 360 family. (You can use SR and AR instead, so no need for LR.) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Paul Raulerson" Sent: Friday, February 02, 2018 12:55 AM And as already been noted, C was first compile on a PDP-7, which had a simple instruction set but was most definitely a CISC machine too. ;) It also explains one of the reasons why strings in C are null terminated. There were two modes of thought back in those days, ‘Pascal’ strings, which have the string size encoded in a single byte at the start of the string, and ‘C’ strings, which terminate a string with a NULL. And PL/I strings, which used a descriptor in which the length up to 32767 was specified. Pascal string length was obviously limited by the max value of a byte - The length was not embedded in the langage; it was an arbitrary limit imposed by the implementer. They could have, for example, used 2 bytes at the start of the string. null terminated strings could be just about any possible size. Yes, but with two disadvantages -- 1. if you wanted to know the length of the string, it was necessaary to search the entire string. 2. A byte of zero could not be part of the string -- completely useless when processing arbitrary data (such as image data, and compressed data). Record eliminators of course, are an entirely different thing, but a C string could easily be a few thousand bytes long. Handy indeed for things like text processing, which is what the AT&T guys were selling Unix and C to their bosses for. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Pascal (was : comparison C vs HLASM)
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, February 02, 2018 2:16 AM On 2018-02-01, at 06:55:29, Paul Raulerson wrote: It also explains one of the reasons why strings in C are null terminated. There were two modes of thought back in those days, ‘Pascal’ strings, which have the string size encoded in a single byte at the start of the string, and ‘C’ strings, which terminate a string with a NULL. Pascal string length was obviously limited by the max value of a byte ... Who made that moronic "single byte" rule!? The implementer. o It should be two pointers, first byte and last byte + 1. The address of the start of the string and the length are probably better. o And having the length contiguous meant that substrings could not be created without copying. Indeed. It's startling how difficult it can be to shift paradigm beyond "two modes of thought" and invent another. BTW, those "'Pascal' strings" were not in Wirth's specification of Pascal; they came later with, e.g. UCSD. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Seymour J Metz" Sent: Saturday, February 03, 2018 4:08 AM That deepends on what you mean by debugging facilities. PL/I has features bthat help in debugging, but a good debugger has a lot more. Such as? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Pascal
From: "Martin Ward" Sent: Saturday, February 03, 2018 6:40 AM On 02/02/18 19:03, Paul Gilmartin wrote: On 2018-02-02, at 06:28:54, Martin Ward wrote: The original Pascal string used a single byte for the length at a time when a $70K machine had a mere 4K words of memory. I don't recall seeing that in Wirth's Pascal User Manual and Report, which I consider to describe the "original Pascal". And: https://en.wikipedia.org/wiki/Pascal_(programming_language)#Early_Pascal_compilers Early Pascal compilers The first Pascal compiler was designed in Zürich for the CDC 6000 series mainframe computer family. Hardly computers of the scale you're considering. "A key platform was the Apple II, where it saw widespread use." (according to the Wikipedia article you quoted). The Apple II had between 4KB and 64KB of RAM, so a modern PC of a similar price does indeed have around a million times as much memory. (The Apple II cost $1,298 which is $5,242 in 2017 dollars). A typical CDC 6500 had 64K of 60 bit words (about 500kB) Not really. A word is a word. So that is 64K words. A relatively small memory. and cost over $60 million in 2017 dollars. I suspect that today $60 million will buy you a machine with over 500GB of RAM, so the million-to-one ratio still holds. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Bernd Oppolzer" Sent: Tuesday, February 06, 2018 1:23 AM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT are all string instructions. Most of these were available in 1965 with the S/360. Long before C. The implementation of strcpy etc. was slow in those early days, but some companies (including the ones I worked for) anyway used C on the mainframe, to take some advantage of the fact that business critical software like (in our case) insurance math had to be developed only once and could be deployed to different platforms (mainframe for back office applications and servers and laptops for the insurance agencies). The strcpy etc. implementation by microcode came later, when customer pressure on IBM to support C better on the mainframe became higher; that at least was my impression of IBM's motivation behind that. More history: Kernighan and Ritchie IMHO had a good knowledge of the IBM platform and PL/1, for example; one of the first implementations of C was on S/360. I agree that it is not nice to search for a string terminator using TRT, for example (given the length limitation of 256), but anyway: it can be done, and there are other languages with similar "unfriendly" concepts or problems that have to solved somehow by the compiler writers ... You should not mix up language and hardware issues in your reasoning ... better to keep the two topics separate. Kind regards Bernd --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Charles Mills" Sent: Tuesday, February 06, 2018 1:51 AM My (long former) product wrote a successful S/390 commercial product in C in the ~1995 timeframe. No problems with S/390 performance. At that time I don't think the x86 architecture had any "string" instructions either -- strcpy() was implemented for PC-DOS as a software loop. The 8088 had a repeat instruction, and when prefixed to another instruction, carried out a loop until a given condition was met. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Tuesday, February 06, 2018 6:27 AM Jon Perryman wrote:>> Keith is talking about dump analysis. Show original message Robin Vowels wrote: Perhaps. But even if he was, the link map and assembly listing deals with that issue. Think of optimization as a chaotic programmer. The last time I used a dump to find bugs in a compiled program was about 35 years ago. PL/I provides all the information required because it has debugging facilities built in. PL/I is an application programming language where the compiler has knows enough to give you everything you need to debug the problem. PL/I is a general-purposed language, and was designed as a system programming language too. The MULTICS operating system was written in PL/I. System level programs are very different and often require a dump. They might, but if in PL/I, the required information would generally be obtained using its own (HLL) facilities. Multi-tasking requires dumps because you need to know about tasks PL/I can't possibly know about. PL/I can multi-task, and can produce information about the tasks. PL/I doesn't know about CB chains so you may need to find out how you arrived at the wrong CB. If there is a storage overlay, then your program may not be the cause. PL/I knows about anything that it is programmed to do. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Tuesday, February 06, 2018 6:50 AM Back then, saving bytes was the norm and would not be considered moronic. 2 bytes could radically increase the size of your programs. No they couldn't. A few extra bytes added to transfer time. A few bytes was significant. It's startling how difficult it can be to shift paradigm beyond "two modes of thought" and invent another. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: comparison C vs HLASM
From: "Jon Perryman" Sent: Tuesday, February 06, 2018 5:54 AM This is too funny. Profess the virtues of C and provide actual examples that look like they prove the point but when scrutinized actually disprove it. When I provided these type of examples, it was considered a gross exaggeration. C is a mindset that is common. Here's the proof I'm not exagerating at all. Kirk Wolf wrote: If you compile this with full optimization and look at the generated assembly, you will find a fancy unrolled loop. Who knows if MVCIN is any faster? It certainly won't handle len>256 cases. This statement would be funny if it weren't so sad. The "fancy" loop would be a simple loop to move each byte where the second operand starts at the end. "optimization" never recognized this as an MVCIN loop but it really optimized the code it produced. MVCIN is obviously many times faster than a single byte loop to move each character (how can this even be a question). Can anyone tell us how many times faster MVC 256 bytes is than 256 MVC 1 byte? To really prove C is superior, MVCIN is limited to 256 byte moves. That's of no consequence, as a number of such instructions can be strung together to deal with strings longer than 256 characters. But wasn't the instruction intended just for printing? In which case, the length of the string will be of the order of 100 or so. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Jon Perryman" Sent: Tuesday, February 06, 2018 12:16 PM Shmuel wrote: While PL/I macros can't extract the attributes of variable > names, they are in most regards as powerful as HLASM macros and syntactically cleaner. I don't know PLI macro's so I did a little research. The deal breaker is that it appears to be a pre-processor language rather than macro language. Is there a way to call the same macro in different locations with parms for tailoring? Yes. It is also called a macro preprocessor. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Paul Raulerson" Sent: Tuesday, February 06, 2018 2:53 PM On Feb 5, 2018, at 7:29 PM, Robin Vowels wrote: From: "Bernd Oppolzer" Sent: Tuesday, February 06, 2018 1:23 AM Am 05.02.2018 um 14:42 schrieb Gord Tomlin: And, BTW, the historic facts are simply wrong: IBM had a C compiler for MVS (and VM, I believe) long before there were string instructions on z/Arch. MVC, CLC, MVCL, CLCL, MVO, MVN, ED, EDMK, TR, TRT are all string instructions. Most of these were available in 1965 with the S/360. Long before C. Oh my - but no. But yes. These instructions process character strings, that is, strings of one or more characters. In the cases of MVCL and CLCL, these also handle zero-length strings. These are >character< operators, not string operators. There are instructions, not operators. Much more akin to C’s memcpy() than anything else. (Yes, memcpy() was built, in part, to emulate them.) CLST, CUSE, MVST, SRTST, and the later generations of these and other instructions work on strings. Albeit, I think the definition of “string” in this case is a little dodgy. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Comparison C vs HLASM
From: "Martin Ward" Sent: Wednesday, February 07, 2018 12:53 AM On 06/02/18 03:53, Paul Raulerson wrote: :-) Here is another gem from Jon: 2. I don't see a difference in using MVC A,B and MEMCPY(A,B,SIZEOF(A)) Just a few of the differences: (1) MVC can only handle sizes of 1 to 256 bytes, memcpy can handle any size from zero upwards; (2) MVC processes overlapping data areas in a specified way: allowing you to fill an area of memory with a single byte. While we're here, let's mention that a 4-byte value can be propagated thru an area (or even a 2-byte value, or 8-byte value, etc). --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Seymour J Metz" Sent: Monday, February 05, 2018 7:21 AM As an example, some debuggers log a trace of the program and allow you to scroll the log back from the point of failure PL/I provides a traceback. Values of variables can be displayed via an ON-unit. A trace is trivial with PROCEDURENAME. in order to track down when, where and how variables acquired unexpected values. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Friday, February 2, 2018 8:07 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Saturday, February 03, 2018 4:08 AM That deepends on what you mean by debugging facilities. PL/I has features bthat help in debugging, but a good debugger has a lot more. Such as? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Strings (was : Fair comparison C vs HLASM)
From: "Paul Raulerson" Sent: Friday, February 09, 2018 9:46 AM Because they don’t have any special knowledge of strings, The only "special knowledge" of strings that is required is that a string is composed of bytes. only untyped data. And the lengths of the data they operate on is fixed and defined at compile time, not at run time. Whether the length of a string is known at compile time or at run time is irrelevant. The data is a string. And the instruction(s) that operate on them are string instructions. How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP? Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted. Just by the way, a NULL as a string terminator seems to make sense. And if the string _contains_ null characters? MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. Translate Extended is needed to work with Unicode without loosing one’s mind… --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Strings (was : Fair comparison C vs HLASM)
From: "Paul Raulerson" Sent: Friday, February 09, 2018 1:03 PM On Feb 8, 2018, at 7:31 PM, Robin Vowels wrote: From: "Paul Raulerson" Sent: Friday, February 09, 2018 9:46 AM Because they don’t have any special knowledge of strings, The only "special knowledge" of strings that is required is that a string is composed of bytes. Seriously? Seriously. Just haven’t to disagree there. From your point of view integers and character data and strings and floating point values are the same thing, right? No they are not. I never said that they were. Because you can move character them all the same way? only untyped data. And the lengths of the data they operate on is fixed and defined at compile time, not at run time. Whether the length of a string is known at compile time or at run time is irrelevant. The data is a string. And the instruction(s) that operate on them are string instructions. Nope, but you are as welcome to your opinion as I am to mine. :) You are being ridiculous. Question - why do you think IBM added string specific instructions if MVC is all one ever really needs? IBM can add any kind of instruction that it likes. It didn't need to add specific instructions to deal with null-terminated strings. MVC, MVCL are prefectly good for for handling strings. IBM used them in all its compilers for handling all kinds of text (i.e., strings). How about taking as a definition of a string any text that SuperC will search for? Or a text string in ISP? Obviously, what a string is and how it is defined varies from language to language. But usually they are not defined as binary data. Unicode excepted. Image data consists of arbitrary characters. It may contain null characters, and plenty of them. Just by the way, a NULL as a string terminator seems to make sense. And if the string _contains_ null characters? Then it isn’t a string - unless of course, the null marks the end of the string. I just said that it didn't. MVST (Move String), CLST (Compare String), SRST (Search String) are all instructs and all work with null terminated strings. So? Also will MVC, MVCL, MVI, CLC, TRT, etc Translate Extended is needed to work with Unicode without loosing one’s mind… And TRT will handle null-terminated strings, as well as other kinds. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Strings (was : Fair comparison C vs HLASM)
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, February 09, 2018 2:54 PM Too much sarcasm. It's analogous to the ASCII-EBCDIC confrontation. I prefer ASCII, but EBCDIC, with no intrinsic superiority, It was superior for 80-column punch card input and output, and for the tabulators that were used to print the input cards and output cards containing the results. The internal codings derived naturally from weights associated with rows on the cards. Of course, once the card image was stored in memory, the values could have been converted to ASCII (and the reverse on output) possibly using a TR instruction. And then the problem of ASCII and EBCDIC would not still be with us. has its proponents and is entrenched in its own dusty corner. I don't expect IBM to abandon it soon. Likewise, I believe that null terminated strings are an inferior technology, but they'll long be with us. Definitely inferior, as Clem Clarke pointed out. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Fair comparison C vs HLASM
From: "Seymour J Metz" Sent: Friday, February 09, 2018 6:41 AM A traceback is not a trace. An ON unit can display *current* values of a variable, It can do whatever you want. For example, you could stack the values of any given variable in the current procedure, and use the ON-unit to print some or all generations. Stacking can also be done for any variables in procedures called earlier, and their values displayed through an ON-unit in those procedures (use RESIGNAL). not past values. I have no idea what you mean by "A trace is trivial with PROCEDURENAME." PROCNAME returns the name of the current procedure. You can either write that out to a file, or stack it, to be retrieved later, along with values of any relevant variables. or how it provides a complete history of the program's execution, much less an interface for viewing it selectively. Use it in each procedure, on entry. From: IBM Mainframe Assembler List on behalf of Robin Vowels Sent: Tuesday, February 6, 2018 7:30 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Fair comparison C vs HLASM From: "Seymour J Metz" Sent: Monday, February 05, 2018 7:21 AM As an example, some debuggers log a trace of the program and allow you to scroll the log back from the point of failure PL/I provides a traceback. Values of variables can be displayed via an ON-unit. A trace is trivial with PROCEDURENAME. in order to track down when, where and how variables acquired unexpected values. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Call by name
From: "Seymour J Metz" Sent: Friday, February 16, 2018 3:58 AM Numeric labels are okay for write-only code. They are very bad in code that has to be maintained. Eh? Labels are labels. It doesn't matter whether they are alphabetic, alphanumeric, or numeric. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Labels
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Saturday, February 17, 2018 6:18 AM On 2018-02-16, at 11:33:05, Bernd Oppolzer wrote: IMO, Niklaus Wirth ... came to this decision, to allow numbers as labels only, and to force them to be declared before using them. The prior declaration is (almost) necessary for single-pass compilation. No it isn't. XPL is a single-pass compiler, and declaration of identifiers is not required. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Labels
From: "Jon Perryman" Sent: Friday, February 16, 2018 4:44 PM Seymour is talking about maintainable large amounts of code should have at least alphanumeric labels. Numeric labels can be confusing unless you have a really good numbering scheme. It still doesn't matter whether labels are numeric or alphanumeric, nor whether programs are large or small. I suspect most programmers would not use numeric labels unless forced. FORTRAN has numeric labels. Large or small programs. On Thursday, February 15, 2018 7:47 PM, Robin Vowels wrote: From: "Seymour J Metz" Sent: Friday, February 16, 2018 3:58 AM Numeric labels are okay for write-only code. They are very bad in code that has to be maintained. Eh? Labels are labels. It doesn't matter whether they are alphabetic, alphanumeric, or numeric. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Labels
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Saturday, February 17, 2018 1:27 PM On 2018-02-16, at 18:45:04, Robin Vowels wrote: From: "Paul Gilmartin" Sent: Saturday, February 17, 2018 6:18 AM On 2018-02-16, at 11:33:05, Bernd Oppolzer wrote: IMO, Niklaus Wirth ... came to this decision, to allow numbers as labels only, and to force them to be declared before using them. The prior declaration is (almost) necessary for single-pass compilation. No it isn't. XPL is a single-pass compiler, and declaration of identifiers is not required. I said "almost". "Almost" was in parentheses. Whether almost necessary or necessary, it is not true. Declarations of labels are not required. You can keep a lookback list of addresses to be plugged when they can be resolved. At some point this becomes tantamount to a second pass, over internal text. It isn't tantamount to a second pass. Does XPL have nested procedure declarations, which complicate the chore? Yes, it has nested procedures. XPL is a small dialect of PL/I. C function prototypes, not required by K&R, embody some of the prior declaration facility. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Labels
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Saturday, February 17, 2018 2:15 PM On 2018-02-16, at 20:03:57, Robin Vowels wrote: From: "Jon Perryman" Sent: Friday, February 16, 2018 4:44 PM Seymour is talking about maintainable large amounts of code should have at least alphanumeric labels. Numeric labels can be confusing unless you have a really good numbering scheme. It still doesn't matter whether labels are numeric or alphanumeric, nor whether programs are large or small. With suitably unrestricted identifier length, alphanumeric labels have more evocative value than numbers. With names, you don't know where to look (up or down). With integers, provided that they are arranged in increasing order, you know where to look. I suspect most programmers would not use numeric labels unless forced. FORTRAN has numeric labels. Large or small programs. And I would use FORTRAN if forced. Perhaps it's better than a half-century ago. Do you collect your FORMAT statements and situate them at the end of the program, or code them proximate to the WRITEs? (Not relevant to the numeric vs. alphanumeric choice) Rarely do I use FORMAT statements in any language. If I do use them, I put them adjacent to the statement that requires it. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: FIND or INDEX builtin function
TRT will do it.
On 1/03/2018 2:32 AM, Andre Schoeman wrote:
Is there a way to use the inverse of either the FIND or INDEX functions ??
For example, a string of characters contains leading blanks and I want to find
the 1st non-blank character in that string.
Trying "INDEX('string',NOT ' ')" or "INDEX(NOT 'string',' ')" yields assembly
errors.
(I've tried both the logical-expression and function-invocation formats of the
INDEX and FIND functions)
Has anyone else successfully used such inverse formats of any of these
functions,
or is there another function (that I can't see) that can yield the results I'm
after.
Best regards, Andre
Re: Two string instruction questions
From: "Charles Mills" Sent: Thursday, March 15, 2018 2:51 AM 1. Is there a machine instruction that will find one string within another? That given "Now is the time" and "is" would find the "is" and return a pointer to it? A machine instruction analog of Rexx POS? 2. Searching the PoOp for such an instruction led me to CUSE. It does not seem that CUSE could be used for this - is that correct? If I am reading CUSE correctly, then given "Now is the time", "All is well" and 2 or 3 would return the position of "is". Is my reading correct? What would that be good for? What would be a reasonable real-world use? The traditional TRT to search for the first letter, followed by CLC for the word (for which the search can commence at the second letter, because the first letter has already been found), will likely be the quickest. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: SDWA - SDWACMPC conversion
From: "Martin Ward" Sent: Saturday, April 14, 2018 12:13 AM On 13/04/18 15:02, Seymour J Metz wrote: Unpacking x'0123' gives you x'F0F132'; the OI then gives you x'F0F1F2'; what you want is x'F0F1F2F3'. Or with an UNNPK length of 4 you get x'F0F0F1F2'; still not what you want. Suppose the byte after the X'0123' is X'xy' (where x and y are any hex digits). Unpacking X'0123xy' (with a source length of 3 and a destination length of 5) gives you X'F0F1F2F3yx' which, when you drop the last byte, gives you what you want. I was wondering when someone would come up with this. This assumes that there is an addressable byte immediately after X'0123' For a general solution, copy the source field to a sufficiently large work area before unpacking. For a general solution, just use UNPK as above, and define a byte following the source. If this is not possible, then move the 2 bytes. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: SDWA - SDWACMPC conversion
From: "Seymour J Metz" Sent: Saturday, April 14, 2018 12:17 AM Of course; the standard way to convert binary to hex is the UNPK/TR with a one byte pad. There is no such "standard" way. The usual way is to use CVD. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: SDWA - SDWACMPC conversion
From: "Donald Blake" Sent: Friday, April 13, 2018 7:00 AM Let me try that again ... WORK DS CL6 DS X , Slack byte UNPK WORK(7),SDWACMPC(4) NC WORK,=X'0F0F0F0F0F0F' TR WORK,=C'0123456789ABCDEF' If you're going to do it that way, try OCWORK,'F0F0F0F0F0F0' instead of NC. No TR required. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: SDWA - SDWACMPC conversion
From: "Robin Vowels" Sent: Saturday, April 14, 2018 2:35 PM Should be OCWORK,='F0F0F0F0F0F0' --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Dependent USING Does Not Work as Documented
From: "Jonathan Scott" Sent: Thursday, April 26, 2018 2:29 AM Ref: Your note of Wed, 25 Apr 2018 10:12:08 -0600 Paul Gilmartin wrote: On 2018-04-25, at 09:51:06, Jonathan Scott wrote: > > ... As valid addresses cannot be negative, ... > Then HLASM should report an error on the case I posted: USING x'7F00',R2 LAR3,-256 ... rather than generating a mathematically incorrect base-displacement. I guess that is supposed to be LA R3,-x'7F00' or x'8100' or similar, as the example as written is rejected with an error message, but there is a range of negative values which give a valid positive offset when the base is subtracted without checking for overflow. I agree that HLASM is failing to diagnose an error, and we have that recorded as a known defect, with reference to previous postings on this mailing list, although no priority was assigned for fixing it as the defect item does not mention any justification, just that it is wrong. That it is wrong is sufficient justification for fixing it. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
- Original Message - From: "Ed Jaffe" Sent: Friday, June 15, 2018 5:34 AM BY FAR the fastest way HANDS DOWN -- if you're looking for 16 or fewer characters -- is with the vector instructions... How many words can you fit into 16 characters? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
Why is everyone afraid to use TRT? It is designed for just such a task. There are multiple characters that can terminate a word. (terminators can be determined dynamically, if required, but since the English alphabet has not changed much lately ... ) Using the simplest instructions suitable for the job [such as TRT] makes it easier to write and debug. - Original Message - From: "Charles Mills" To: Sent: Friday, June 15, 2018 5:40 AM Subject: Re: Count Words? Not the answer to your question but I don't think "TRT performs badly." It is just that people sometimes assume that because it is a single instruction in the Pop it must execute roughly as fast as many simple instructions. I think it is fast for what it does. Picture "writing TRT in assembler" -- implementing it as a subroutine as if the opcode magically vanished. Now picture a version of that only somewhat faster because millicode has some special tricks up its sleeve -- that's TRT. If I had to count words in a string in assembler I would probably just use a loop of CLI's and such -- unless there was some incredible need for optimization. The big cost these days is getting the data into cache, and that is all the same whether CLI, TRT, SRST, etc. TRT is perhaps a little worse because you need to get two things into cache, the string and the table. I might look first at SRST. Charles --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Friday, June 15, 2018 5:18 AM Is there a modern, clever, efficient way to count words in a string where: o A separator is or (+ others ad lib.) o A word is a maximal non-empty sequence of consecutive non-separator characters. (Whew!) Do TRT and CLI remain the best primitives? (TRT is reported to perform badly, perhaps model-dependent.) Possible non-alphabetic characters number around 200. One way to simplify seaching (if not using TRT for the search) is to use TRT to replace all non-alphabetic charaters with a blank (say), prior to searching. Still, TRT remains the simplest way to address counting words. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
GH's contribution seems to be not particularly relevant. However, I may add that in PL/I one trivial statement will count the number of words when any particular character (such as blank) is the delimiter. To permit bunches of other characters to be delimiters, a prior call to the TRANSLATE built-in would be required to convert those to a single charcter (such as blank). - Original Message - From: "glen herrmannsfeldt" To: Sent: Friday, June 15, 2018 1:33 PM Nothing against discussions on how to write fast code, but I don’t believe that this is normally necessary. About 20 years ago, I was counting words, not just how many, but how many of each word, on gigabytes of text. (Full text US patents for two years.) I did it in Java (with JIT compiler on), and it was plenty fast enough. I did it using the Java StringTokenizer: https://docs.oracle.com/javase/7/docs/api/java/util/StringTokenizer.html which takes a regular expression for the delimiter. Then each word found was either added to a HashTable, or the count for it was incremented. As computers are much faster now, it should be able to do terabytes of text, today. There was one non-obvious thing about the Java code, though. It seems that the way Java normally does substrings is with a reference to the whole character array, which in my case was a line of text. That filled up memory faster than it should have. Using new String() on each word, fixed that problem. (It only does that for the actual entry in the hash table.) But if you do have exabytes of text, then there might be need for assembly speed-up. Well, OK, petabytes are enough. Oh, you might also look at the unix wc command, which counts words. (More specifically, the GNU utilities version, with source available.) About 25 years ago, I compiled the GNU utilities (as they then existed) to run on my OS/2 system. (That is before Linux, and such, that are so convenient today.) --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
How is ths useful? What does it mean? - Original Message - From: "Keven" Sent: Friday, June 15, 2018 12:32 PM I think the technical answer in this context is:1 x 16-letter word2 x 8-letter words 4 x 4-letter words8 x 2-letter words16 x 1-letter words This assumes single-byte character encoding. Sorry if this sounds facile; I found myself compelled to post a response and this is it. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
- Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: Sent: Friday, June 15, 2018 11:18 AM On 2018-06-14, at 18:50:01, Robin Vowels wrote: Why is everyone afraid to use TRT? It is designed for just such a task. - Original Message - From: "Charles Mills" Sent: Friday, June 15, 2018 5:40 AM Not the answer to your question but I don't think "TRT performs badly." Probably good points. And any empirical comparison would probably be model-sensitive. On 2018-06-14, at 18:44:06, Robin Vowels wrote: How many words can you fit into 16 characters? I Understand Ed's suggestion involves repeating after 16 characters, akin to using TRT in a loop. It's worse than that. There might be as little as one word, or it might be that the word is longer than 16 characters. On 2018-06-14, at 16:05:54, Ed Jaffe wrote: Use VL to load 16 one-byte search arguments into (for example) V0 Use VLL to load 16 bytes (or how ever many remain if <16) of the string into (for example) V1 Use VFAEB to find the first matching byte e.g., VFAEB V1,V1,V0,1 If CC=not found, adjust string pointer up by 16 and remaining length down by 16 and loop back to the VLL (or exit if none left) Otherwise, use VLGVG to get the matching ELE index from V1 into (for example) R15 Point to matching byte in the string by adding index value to the current string pointer e.g., LA R1,0(R15,1R1) I fear my assimilation of PoOps stalled around XA. So probably ignorant questions: Suppose words are separated by an arbitrary mixture of an arbitrary number of and , e.g. "chicken Flamingo Ostrich Sparrow Turkey Wren" Is there a way to skip over the terminators to the first non-terminator, i.e. "c"? Perhaps a "don't find" option for VFAEB? (Something like the (No)Match option to Rexx VERIFY()?) Oops! From PoOps: Proceeding from left to right, the elements of the second operand are compared with the corresponding elements of the third operand and optionally with zero. "Corresponding element" is the problem. If the second operand is and the third operand is I believe I'll never get the desired match. TRT seems to remain the winner. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
From: "Ed Jaffe" Sent: Friday, June 15, 2018 11:14 AM On 6/14/2018 5:44 PM, Robin Vowels wrote: - Original Message - From: "Ed Jaffe" Sent: Friday, June 15, 2018 5:34 AM BY FAR the fastest way HANDS DOWN -- if you're looking for 16 or fewer characters -- is with the vector instructions... How many words can you fit into 16 characters? Haha! I assume that's a joke, but this is no laughing matter. SIMD is a "game changer" for this platform. Not a joke. 16 characters will not hold much, possible only one word (or less of the word is longer than 16 characters). --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
From: "Tony Harminc" Sent: Saturday, June 16, 2018 3:03 AM On 14 June 2018 at 15:40, Charles Mills wrote: Not the answer to your question but I don't think "TRT performs badly." It is just that people sometimes assume that because it is a single instruction in the Pop it must execute roughly as fast as many simple instructions. I think it is fast for what it does. Picture "writing TRT in assembler" -- implementing it as a subroutine as if the opcode magically vanished. Now picture a version of that only somewhat faster because millicode has some special tricks up its sleeve -- that's TRT. Yup. A byte-at-a-time subroutine. It's not a subroutine. The original (on S/360) was about ten times faster than the equivalent in ordinary character-manipulating instructions. Ignoring for the moment what Dan says about offloading TRT to special hardware, there is still a small but fundamental problem with TRT and TR, as architected in the early 1960s. That is that access failures *for the table* (operand 2) are dependent on the actual data in operand 1. If your table straddles a page boundary, it is entirely ordinary for your access to those two pages to be different, whether due to key protection, page protection, or just that one is paged in and the other isn't. The programmer can usually manage to avoid that. TRT and TR are defined so as to program check only if the data requires it, so if no data byte causes a given function byte to be referenced, there will be no program checks related to the address of that function byte. A similar problem arises with the data (operand 1) of TRT: program checks are recognized only if strictly necessary. If the instruction ends early because of the value of the function byte addressed by a data byte, then there's no program check even if unexamined parts of operand 1 are inaccessible. This is a more common situation not unique to TRT (presumably SRST and friends would also have it), but still it must surely be checked for, essentially one byte at a time. The newer variants TRTE and the many TR variants like TROO, TROT, etc. are defined so as to allow the program check even if the data doesn't require looking at one or the other page. Well obviously don't put your table across a page boundary, and presumably the hardware/millicode will detect this and be able to run faster. But is this a reasonable requirement for an application program to have to pay attention to? It the programmer who pays attention to such. It's very easy to have your table in a good place, insert some data above it that pushes it over a boundary, Again, the programmer can handle it. and suddenly things slow down. Maybe on modern machines all this state can be cached, but if the data is different each time as it would be in a list of words, then I can't see a general way of speeding up the checking. Maybe Dan knows the answer... --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
From: "Charles Mills" Sent: Friday, June 15, 2018 10:43 PM Possible non-alphabetic characters number around 200 FSVO "alphabet" For all values of alphabet. English hasn't changed much lately, as I said. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
From: "Walt Farrell" Sent: Saturday, June 16, 2018 11:25 PM On Sat, 16 Jun 2018 13:17:52 +1000, Robin Vowels wrote: From: "Charles Mills" Sent: Friday, June 15, 2018 10:43 PM Possible non-alphabetic characters number around 200 FSVO "alphabet" For all values of alphabet. English hasn't changed much lately, as I said. Did the OP specify he was interested only in English? OP can put in any language alphabet that he likes. Still won;t have changed much lately. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Count Words?
From: "Charles Mills" Sent: Saturday, June 16, 2018 11:27 PM Is it worth pointing out that English is not an alphabet? The context was English alphabet. That English changes all the time? The alphabet doesn't. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: New Metal C standalone product for z/OS
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Thursday, July 19, 2018 8:00 AM Generally. Of course HLASM is all but untyped. A might mean an integer constant, especially since A supports expressions while F somewhat inexplicably does not. You can code A(BUFF_LEN+7) but not F'BUFF_LEN+7'. OTOH, DC F'-2147483648' assembles successfully, while DC A(-2147483648) gets a syntax error. Well, it should get some kind of error. A designer's perverse notion of completeness? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Inconsistency with NILL vs. NILF
From: "Steve Smith" Sent: Friday, July 20, 2018 2:26 AM An issue I raised on IBM-MAIN led to discussing how to round an address to a 16-byte (quad-word) boundary. The C example included the expression p &= -16;. Won't this truncate, not round? You'd need to add 15 and then "and". I suggested that the NILL & NILF instructions could handle this, but probably wouldn't. So... --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Instruction/Data Cache Usage (was EQU *)
From: "Christopher Y. Blaicher" Sent: Thursday, August 02, 2018 11:17 AM Inline data is no more expensive than data in another page. In either case, the reference to the data requires a cache line load to the D-cache, but does not invalidate/disturb the I-cache. A comment on the original EQU * part of this thread. I prefer the DS 0H to hold a label because you can't get burned on someone putting something in front of it that isn't halfword aligned. I personally HATE it when people put a label on an instruction, especially if they are using long names in the label. All the other op codes are in column 10 and then you have one out in right field. Your eye can't just flow down the screen, now you have to go searching for the op code. Also putting a label on an instruction makes it harder to move the instruction. And with good reason. A labelled instruction usually means that it is the head of a loop or the object of a branch. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
