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.) 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? I fail to see page numbering as a very relevant analogy. We read from left to right 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. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tony Harminc Sent: Tuesday, July 2, 2019 10:38 AM To: [email protected] Subject: Re: STORAGE OBTAIN doc inconsistency? On Mon, 1 Jul 2019 at 15:06, Charles Mills <[email protected]> wrote: > > You're right, of course. Not to start a religious war, but even on a > big-endian machine, it seems to me to make sense to number > the bits from LSB to MSB. Bit n then represents 2^n -- in an 8-, 16-, 32-, > 64- or 128-bit integer. What could be more logical? I think you're effectively proposing some sort of mixed-endian scheme. With big-endian addressing, no matter the size of the chunks of data, the numbering starts at 0 and increases "left to right". (Obviously you can write these things on paper any way you like - top to bottom or bottom to top, etc., but it's *consistent*.) So the first bit in main storage is numbered 0, the next higher one is 1, and so on. Byte 0 is the first, 1 the next, etc. Same for halfwords, fullwords, doublewords, quad words, pages, and any other grouping you like. Once you introduce bit numbering that goes the other way, is there a consistent reason not to do the same for e.g. page numbers? And page sizes *have* increased over the years, so it's not a hollow argument. > Not going to happen of course. Yeah. It's an annoyance, but better than the alternative... Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
