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. Tony H. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Harminc > Sent: Tuesday, July 2, 2019 10:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: STORAGE OBTAIN doc inconsistency? > > On Mon, 1 Jul 2019 at 15:06, Charles Mills <charl...@mcn.org> 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 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
