You are right of course: programs that used FLOGR would have to be recoded. I suspect that is the only spot where the hardware uses bit numbers but there might be one or two others. Still, nowhere near as fundamental as endianness, and totally unrelated. IBM could decide to "fix" FLOGR and they would not have to touch the endianness of the architecture. In fact, z/OS C implements the XPG4.2 function int ffs(int i); find first set, that functions more or less analogously to FLOGR but numbers the bits from LSb to MSb, with no conflict with bigendianness.
> Why not stay consistent: groups of bits are numbered the same way no > matter what the size of the group. Even if that size is 1. In this scheme too: the LSb is numbered 0, the next is numbered 1, and so forth, no matter what the size of the group. That is the whole advantage: in the documentation of STORAGE OBTAIN, IBM could say the storage key was in bits 4-7 and the doc would be correct across S/390, zArchitecture, and any future machine with 128-bit GPRs. That's where this discussion started. I think the cultures that read from right to left number the pages that way also. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, July 2, 2019 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc inconsistency? On Tue, 2 Jul 2019 at 17:33, Charles Mills <charl...@mcn.org> wrote: > > I disagree 100%. > > Endianness is a fundamental aspect of the hardware. The Z hardware IS > big-endian. Absent a total re-engineering of > the hardware, that will never change on a Z box. And if it somehow magically > did change, every bit of Z software would > have to be examined and tested and in many cases re-coded. > > Bit numbering on the other hand is just an aspect of the documentation. If > IBM were (by some admittedly extremely > unlikely fluke) to accept the suggestion I made, then nothing would change > except the documentation and peoples' > thinking. The only thing wrong in any existing software would be comments > describing logic and storage layouts in > terms of bit numbers. (I'm not "selling" my idea here; just pointing out the > logic for academic reasons.) I think your argument at first seems plausible, but that's because there have traditionally been very few situations where the actual bit number is used in code. Unlike some older architectures, there is no variable-base addressing of storage (or of bits in a register). So we don't have instructions that address, say, fullword f, byte x, bits b through c. But do look at the "Find Leftmost One" (FLOGR) instruction. It returns the bit position of the leftmost one bit in a register. If you want it to return the number with the bits numbered the other way, then I think you'll need to do more than redocument. You could rename it to "Find Rightmost One", but existing code will be broken. It may be that that's the only such instruction, but there's no reason there couldn't be more. > Further, I would suggest that numbering from LSB to MSB is *more* consistent > with big-endian hardware. > It is the least significant byte of the register and the low order bit of the > register -- why not refer to it with the lowest bit > number, zero? Why not stay consistent: groups of bits are numbered the same way no matter what the size of the group. Even if that size is 1. > I fail to see page numbering as a very relevant analogy. We read from left to > right not everyone does... > and so we number the pages from left to right. In fact, a big-endian machine > does arithmetic other than division > conceptually from right to left -- the way you learned to add big numbers in > elementary school, least significant digit to > most. It's another argument for numbering the bits from right to left. Not everything to do with bits is binary arithmetic. I'd say the times when I want or need to think about bit numbering are mostly not. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
