> I can't count the number of well-coded bubble sorts I have replaced. My favourite sentence of the day.
Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of David Bond Sent: 08 October 2010 17:37 To: [email protected] Subject: Re: levels of abstraction (was: 16-bytes the same) In general I am sympathetic to these musings. I also believe clarity is very important. But I am compelled to add a few observations. First, my experience has been that the maintenance of hand-coded finite state machines is difficult. There are wonderful tools for building (and rebuilding) FSMs but I don't know of any that are available for HLASM. So while FSMs are wonderful for purposes of tokenizing and parsing, I have abandoned using FSMs when coding in HLASM. Maybe you have (macro based?) techniques for building HLASM FSMs or have other experience with them that I don't have. Second, I believe there are only two valid reasons to write production code in HLASM. One is performance. The other is access to OS or hardware services that cannot be easily done in a higher level language. This is especially true for z/OS. Otherwise HLLs have an advantage in maintainability and portability. A tokenizer/parser generally does not need access to low-level services. So if performance is not an issue, I would rather write a tokenizer/parser in C. I might even use lex and yacc to build the FSMs. Or I might write an easily understood recursive descent parser. And using METAL-C (or an equivalent), I can integrate it into a larger mostly-HLASM code base. But if performance is an issue, then I do need to pay attention to the instructions that I use. Fixed-length TRT performs well over the range of about 8-256 characters. But as has been discussed ad-nauseam, EX of TRT is an extremely slow combination on the z10, especially for the short variable-length searches typically encountered in tokenizing. The newer variable-length TR* instructions are not always available or perform well. Being aware of the cache on the TRT table can be critical. SRST is easy to use and fast for finding a specific character (such as the next blank) in a variable length string but has limited usefulness in tokenizers. Performance issues may dictate that the code needs to be written using more complex constructs than EX+TRT - otherwise HLLs should be considered. Related to the above is my observation that because coding HLASM is so low-level, it seems to cause the coder to think at the same level. Often the easier-to-code algorithm is chosen instead of a more efficient one. Choosing a more efficient algorithm will almost always yield better performance than micro-optimizing a poor algorithm. Yet it seems many HLASM programmers focus on the second. I can't count the number of well-coded bubble sorts I have replaced. David On Wed, 6 Oct 2010 12:02:56 +0000, john gilmore wrote: >This is one of my ruminations, and if you find them boring you may safely skip the rest of this post. > >The subject of this thread in all of its particularity is not of much interest, but it is of great interest if it is viewed more abstractly. This time, moreover, it is easy to generalize. > >Most of the posts dealt with blanks, x'40' in EBCDIC and x'20' in ASCII, but repetitions of nuls, x'00' in both, are more important in some few contexts. > >The limitation to 16 characters, one instance and 15 repetitions of it, is artificial. > >Finally, the limitation to a single character is stultifying: many apparently different but in fact conceptually identical problems require that repetitions of any of a subset of characters be identified. > >Consider the two PL/I statements, useful because they are cointext-sensitive: > >declare transac3 file record sequential buffered ; > >open file(transac3) input ; > >In both we want to break out the tokens, 'declare', 'transac3', 'file', 'record', 'sequential', 'buffered', ';' in the first and 'open', 'file', '(', 'transac3', ')', 'input', ';' in the second. Here, as Robin has already pointed out, a TRT is better than a CLC[L]. > >Indeed, well-written texical breakout routines consist of little more than a small finite-state-machine and a set of TRT tables. In particular, they do not process inputs one character at a time (as the computer science 101 illustrations always do). > >There is a sense in which this is well known. The current PROP in its discussion of the TRT instruction says > >TRANSLATE AND TEST may be used to scan the first operand for characters with special meaning. The second operand, or list, is set up with all-zero function bytes for those characters to be skipped over and with nonzero function bytes for the characters to be detected. > >For my example it is thus possible to both stop on [any of] a blank, a left parenthesis, a right parenthesis, or a semicolon and to distinguish them (without further testing) after stopping. > >Why use a TRT, which requires a table of, usually, 256 bytes, when something more compact can be put together for the special case of 16 blanks (or nuls)? The answer can be boiled down to a single word, reusability. > >Efficiency is a vexed question, and I cannot consider it here in any really satisfactory way. No one wants to write inefficient or inelegant code, but preoccupation with the relative efficiencies of alternative single instructions, both of which consume only nanoseconds, is a mug's game. Worse, the avoidance of single millicode-based instructions, their replacement by a notionally and temporarily more efficient sequence of hardware-based ones, is, I think, perverse. > >Enough! I have already offended just about everyone. > >John Gilmore Ashland, MA 01721-1817 USA
