Yeah, I have to agree with "liability" except in the cases where valid values 
above 32K or 64K are impossible. (The length of a command entered on a single 
"punched card" for example.)

And no, @Gil, that is not your cue for a rant on long LRECL SYSIN datasets! <g>

> allow per-page choice of endianness

Sure, CPU silicon is so cheap and trivial now. Back when Intel did 
little-endian (despite surely being aware of the S/360 big-endian precedent) I 
suspect it was to save silicon: an 8-bit processor could do 32-bit arithmetic 
by nibbling off one byte of it at a time.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith
Sent: Wednesday, March 8, 2017 8:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: curious: why S/360 & decendants are "big endian".

Charles Mills wrote:
>One thing about little-endian I have observed of relevance to software 
>writers: if I expect you to pass me a halfword and instead you pass me a 
>fullword, then the code will probably work most of the time. Whether that is a 
>benefit or a liability depends upon one's point of view.
I come down strongly on the “Liability” side: “It works until you enter a 
really big number” sounds like just asking for obscure failures. Obviously with 
big-endian, the opposite is also true: if I expect a fullword and you pass a 
halfword, it’ll sort of work with big numbers, fail with smaller. But that’s an 
easier to detect failure passed 100000 and it said I passed 34 thousand and 
change”), plus testing will start with small values and thus it’ll show up 
immediately; the little-endian case will work fine until the numbers get big 
and it doesn’t.

But, like you, I grew up with big-endian, wasn’t even aware of little-endian 
until well into my career. Reading the Wikipedia page makes my head hurt:
Some CPUs, such as many PowerPC processors intended for embedded use and almost 
all SPARC processors, allow per-page choice of endianness.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to