Shmuel Another exhausting post from what can only be deliberate misunderstandings. The nursery rhyme "Mary, Mary, quite contrary" comes to mind every time I see one of those characteristic stand-alone "No"s. But this time the boot is most definitely on the other foot - see later - and you can have all your red herrings back.
Comments are embedded. Chris Mason ----- Original Message ----- From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 03 November, 2006 3:42 AM Subject: Re: Assembler question > In <[EMAIL PROTECTED]>, on 11/02/2006 > at 03:39 AM, Chris Mason <[EMAIL PROTECTED]> said: > > >It seems reasonable that the field M1CC is defined as having length > >5. If not, the programming is a mess. If so, the "L'M1CC+1" > >specification is stupid. > > No. > > >It's stupid because the expression already indicates the length by > >virtue of having included the literal > > The assembler takes the length from the first operand, not from the > second. That's why you'll sometimes see a CLC with a literal as the > first operand. > Again, by not quoting everything, you have rather deceitfully obscured what I was saying. The missing part was "obviously has length 6." You were entitled to skip my pun of course. Some jokes only bear telling once. I was commenting on the following instruction: MVC M1CC-1(L'M1CC+1),=X'402120202020' MOVE IN EDIT MASK I will now make my point "in words of one syllable" so it cannot be misunderstood. Now there's a challenge. The task is to move a 6-character string into a storage area. There needs to be some symbolic reference to the storage area so the M1CC variable is used. Unfortunately the "fill character" needs to be taken account of so the actual starting location is one byte "to the left" of the storage area M1CC. (I would have preferred some symbolic acknowledgement of this in the coding which didn't involve particularly "minus" relative addressing - but we'll let that pass.) What I am taking issue with is going to the trouble of using a symbolic expression for the length. That is, the use of the length attribute - albeit modified because of the fancy footwork with the starting location - when the instruction contains a literal which necessarily indicates the length. And, being a literal, it would be crass stupidity to be relying on data in a following field in the case that the length used by the instruction didn't precisely match the length of the literal. Sure, the Assembler uses the length of the first operand if it is not specified explicitly but that's not what I consider stupid. What I consider stupid is that the number 6, consisting of one simple character, was not specified but something which the Assembler has to work out is 6, consisting of 8 complicated characters. I'm not complaining on behalf of the Assembler, of course, but on behalf of anyone looking at the source coding in times to come who will be slowed down trying to work out what subtle benefit there might be in using "the length attribute of M1CC + 1" rather than simply specifying "6". There is no benefit; it's just stupid. I do hope that's clear. > >In fact the "print hexadecimal" case is even trickier that the > >"print decimal" case since, in the letter case, all the instructions > >were doing precisely what the Principles of Operation says they do > > Likewise in the former case. > > >The "unpack" instruction makes what is, in fact, an incorrect > >assumption. > > Not really; it is doing exactly what PoOps says it does. Of course it should have been "trickier than" rather than "trickier that", a "typo" I'm afraid. We are here talking about the UNPK instruction: UNPK HEXWORK(L'HEXWORK+1),BINWORK(L'BINWORK+1) There may be a difference in philosophy or perspective here. My point is actually made later on where I indicate that the UNPK instruction is obliged to do more work than we actually need done. Of course, the UNPK instruction does what the Principles of Operation says it does - but it's not what we actually need; it's what we need plus a bit more we don't need. Because it necessarily does a bit more than we actually need we have the messy "+1" in the length fields and we have the worry about the byte following the destination field. In the sense that the instruction is not doing precisely the job we need it to do, trying to follow the code as a "newbie", which I take the OP to be, the use of the UNPK instruction looks odd - or if it doesn't it should do to any person who still has any sense of what is straightforward from what is not straightforward. Once again the too restricted quotation distorts my point. Is this deliberate point-scoring or a genuine blind spot? Of course, if it's a blind spot, you won't know so I mustn't expect an answer. Read this again: <quote> The "unpack" instruction makes what is, in fact, an incorrect assumption. It, poor thing, *thinks* it is working on a packed decimal number - having the format I explained above. In fact the "unpack" instruction is being used in a clandestine way to "unwrap" the 8 half-bytes of the BINWORD field into the 8 bytes of the HEXWORK field, each in turn being taken a half-byte at a time, prepended with X'F' and stored a byte at a time. </quote> Now isn't it blindingly obvious that there's a bit of anthropomorphising going on here, a familiar dodge for someone attempting to teach in a picturesque way? It should be. > > >[1] In fact the "packed decimal standard", as it were, allows some > >flexibility in the hexadecimal digit which forms the, so-called, > >"sign half-byte". > > Not very much. > > >I forget every last detail but it may be as simple as only the > >lowest bit being significant > > It isn't. Only specific values are allowed as a sign. > > >Suffice to say that it was once proposed that the "Add Register" > >instruction code, X'1A', could be used as a positive packed > >decimal "1" > > Perhaps in ASCII mode, which no longer exists. Certainly not in EBCDIC > mode. And it's three out of three for misleading selective quotation. You had the temerity some time ago when commenting on my posts to imply that they quoted too much. It's better than quoting too little and just confusing everybody. The reference is to your post of Wed, Sep 6 2006 3:21 am (Google Groups format) on the thread ">27x132?". Let's recall the whole again: <quote> [1] In fact the "packed decimal standard", as it were, allows some flexibility in the hexadecimal digit which forms the, so-called, "sign half-byte". I forget every last detail but it may be as simple as only the lowest bit being significant and the rest ignored so that a positive number is one which has B'0' as this lowest bit and a negative number is one which has B'1' as this lowest bit - except that X'F' has to indicate a positive number - so maybe it's not quite so simple. Suffice to say that it was once proposed that the "Add Register" instruction X'1A' could be used as a packed decimal "1" when a package for some basic "spooling" in under 4K for DOS (now VSE) was being discussed (in the days before POWER obviously) and the author/presenter was canvassing for space-saving ideas. </quote> You'll note that I already realised my oversimplification since X'F', a positive value broke the supposed bit rule. Since you seem to be aware of the limited number of sign half-bytes ("Not very much"), it would have been really useful actually to list them. I had a faint memory probably dating from my Assembler class in November/December 1967 (teacher Pete Sadler who some may know since he was still active not so long ago - in IMS) that all the non-digit half-byte values could be used as sign half-bytes and that, the "even" ones were "positive" and the "odd" ones negative - except that didn't work for X'F' which was "positive". but my memories were too faint to rely on. Naturally I don't carry all the details of the Principles of Operation manual around in my head and it seemed too much fuss actually to look it up. However, your post obliges me to do just that and I now turn the tables and create the following text: > Perhaps in ASCII mode, which no longer exists. Certainly not in EBCDIC mode. No! And, when I am "contrary" I like to quote the proof so that a. I don't make mistakes b. List readers can see that I haven't made a mistake Here is some text and a table from the z/Architecture Principles of Operation, Chapter 8. Decimal Instructions, Decimal-Number Formats, Decimal Codes: <quote> Alternate sign codes are also recognized as valid in the sign position: 1010, 1110, and 1111 are alternate codes for plus, and 1011 is an alternate code for minus. Alternate sign codes are accepted for any decimal source operand, but are not generated in the completed result of a decimal-arithmetic instruction or CONVERT TO DECIMAL. This is true even when an operand remains otherwise unchanged, such as when adding zero to a number. An alternate sign code is, however, left unchanged by MOVE NUMERICS, MOVE WITH OFFSET, MOVE ZONES, PACK, and UNPACK. Code (Binary Hexadecimal) Recognized As Digit Sign 0000 0 0 Invalid 0001 1 1 Invalid 0010 2 2 Invalid 0011 3 3 Invalid 0100 4 4 Invalid 0101 5 5 Invalid 0110 6 6 Invalid 0111 7 7 Invalid 1000 8 8 Invalid 1001 9 9 Invalid 1010 A Invalid Plus 1011 B Invalid Minus 1100 C Invalid Plus (preferred) 1101 D Invalid Minus (preferred) 1110 E Invalid Plus 1111 F Invalid Plus (zone) </quote> I took the trouble to add an extra column, the hexadecimal values. Naturally the so carefully crafted table works only when viewed with a non-proportional font. I appreciate that other posters have pointed out the "X'1A' has a valid positive sign half-byte mistake" already, for example Steve Myers, Glen Herrmannsfeldt and Tom Marchant, but I took my time ... > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
