| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414323 is a reply to message #414292] |
Sat, 30 April 2022 18:21   |
|
|
Originally posted by: Johnny Billquist
On 2022-04-29 18:28, D.J. wrote:
> On Fri, 29 Apr 2022 14:23:55 +0200, Johnny Billquist <bqt@softjar.se>
> wrote:
>> On 2022-04-29 02:46, Peter Flass wrote:
>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>> On 2022-04-21 23:24, Quadibloc wrote:
>>>> > Why do little-endian CPUs even exist?
>>>> >
>>>> > Oh, I know, historically it was more efficient to fetch the least
>>>> > significant part first, and start adding, with the second part
>>>> > fetched by the time the carry was ready. But there's no excuse
>>>> > for that today.
>>>>
>>>> And I don't even get the problem? In what way is either order superior?
>>>> It seems like you (and some others) seem to think that big-endian
>>>> somehow is the only proper choice, and superior in some way.
>>>>
>>>> This seems a very silly, subjective opinion. You are entitled to it, of
>>>> course, but can you make some proper argument why cpus actually should
>>>> be big-endian, that isn't based on "you like it".
>>>>
>>>
>>> If I write one-hundred thousand, I write 100,000, not 000,001. All else
>>> being equal, why shouldn’t computers represent data as much as possible in
>>> the way people think of it?
>>
>> So it's exactly because "you like it"?
>>
>> It's a computer. It can deal with any format just as easily. Just
>> because you can't is hardly an argument. That's why we have computers in
>> the first place. To do all the boring tasks that can easily be described.
>>
>> It's a long time since computers also stopped using decimal. Should they
>> go back to that because that is also in fact what you use?
>
> I am puzzled why your answer went off on a tangent.
The answer goes off on a tangent because the argument is basically
"because I like it". Which makes it a rather meaningless argument.
A computer don't really care about how you read numbers, and don't find
one order "easier" than any other.
And when you work on the computer, you are expressing the value as a 8-,
16-, 32-, or 64-bit number, or whatever.
And that is true no matter if we talk about a little-endian or
big-endian computer. What this is about is then just in which order are
the sub-parts of this number stored in memory, and retrieved again. When
you are operating on it, you are not working on these subparts.
Johnny
|
|
|
|
| Re: Big-endian history, What's different, was Why did Dennis Ritchie write [message #414325 is a reply to message #414304] |
Sat, 30 April 2022 18:26 |
|
|
Originally posted by: Johnny Billquist
On 2022-04-30 04:59, John Levine wrote:
> According to Johnny Billquist <bqt@softjar.se>:
>>> I'm seeing a lot of "obvious" in this discussion that reverse-engineers
>>> people's personal preferences.
>>
>> That the PDP-11 is a 16-bit machine, and not a 32-bit machine is
>> obvious, and have nothing to do with personal preferences. :-)
>
> So far, so good.
>
>> That the first character is stored in the first byte is a rather natural
>> behavior.
>
> Of course.
Happy we agree.
>>> The 360/20 was a byte addressed 16 bit machine with 16 bit registers.
>>> The first character in the first byte of what they called a halfword
>>> was in the high bits if you read it as a 16 bit quantity. It's no more
>>> "natural" or "obvious" either way.
>>
>> Since we seem to claim that the 360 was a byte addressed machine (I
>> honestly have no clue about the 360)
>
> Don't take mt word for it, read the manual.
[...]
Ah. Somewhere I got lost or something here.
The 360 then makes perfect sense, just like the PDP-11.
One big-endian, the other little. Both store bytes in a text in the
reasonable order.
So, I guess there isn't much more to discuss about it.
And I can't see that either is superior to the other.
Both have their pros and cons.
Johnny
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414326 is a reply to message #414318] |
Sat, 30 April 2022 18:47 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> OTOH, there’s a lot to be said for maintaining compatibility with others.
> If nothing else, there are fewer things to be surprised by when moving to a
> new system. Everyone once had there own version of BCD because there may
> have been an unexpected advantage in having a particular character or
> arrangement. ASCII and EBCDIC were developed to standardize on one good
> choice over many other possibilities.
from post in thread couple weeks ago ... biggest computer goof, 360 was
supposed to be ASCII, by the (IBM) father of ASCII, gone 404 from
wayback machine:
https://web.archive.org/web/20180513184025/http://www.bobbem er.com/P-BIT.HTM
I mention this because it is a classic software mistake. IBM was going
to announce the 360 in 1964 April as an ASCII machine, but their
printers and punches were not ready to handle ASCII, and IBM just HAD to
announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
had a store of spendable money. They put in the P-bit. Set one way, it
ran in EBCDIC. Set the other way, it ran in ASCII.
.... snip ...
other Bemmer computer history
https://web.archive.org/web/20180402200149/http://www.bobbem er.com/HISTORY.HTM
Bemmer refs:
https://en.wikipedia.org/wiki/Bob_Bemer
https://history.computer.org/pioneers/bemer.html
Bemer is the inventor of the words "Cobol," and "CODASYL," six ASCII
characters, and the concepts of registry and escape sequences in
character codes. He also invented the term and defined the nature of the
"software factory." At IBM he developed the first load-and-go system
(PRINT I) and also was responsible for the implementation of the
programming system FORTRANSIT, which provided a quick first compiler for
the IBM 650 computer, and was the first programming language to run both
decimal (IBM 650) and binary (IBM 704) computers. For the support of
commercial programming Bemer developed PRINT I; in the late 1950s he
developed XTRAN, a step towards Algol, and "Commercial Translator,"
which became a significant input to Cobol. His major Cobol innovations
were the IDENTIFICATION and ENVIRONMENT divisions, and the PICTURE
clause.
.... snip ...
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414330 is a reply to message #414323] |
Sat, 30 April 2022 20:24 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-04-29 18:28, D.J. wrote:
>> On Fri, 29 Apr 2022 14:23:55 +0200, Johnny Billquist <bqt@softjar.se>
>> wrote:
>>> On 2022-04-29 02:46, Peter Flass wrote:
>>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>> > On 2022-04-21 23:24, Quadibloc wrote:
>>>> >> Why do little-endian CPUs even exist?
>>>> >>
>>>> >> Oh, I know, historically it was more efficient to fetch the least
>>>> >> significant part first, and start adding, with the second part
>>>> >> fetched by the time the carry was ready. But there's no excuse
>>>> >> for that today.
>>>> >
>>>> > And I don't even get the problem? In what way is either order superior?
>>>> > It seems like you (and some others) seem to think that big-endian
>>>> > somehow is the only proper choice, and superior in some way.
>>>> >
>>>> > This seems a very silly, subjective opinion. You are entitled to it, of
>>>> > course, but can you make some proper argument why cpus actually should
>>>> > be big-endian, that isn't based on "you like it".
>>>> >
>>>>
>>>> If I write one-hundred thousand, I write 100,000, not 000,001. All else
>>>> being equal, why shouldn’t computers represent data as much as possible in
>>>> the way people think of it?
>>>
>>> So it's exactly because "you like it"?
>>>
>>> It's a computer. It can deal with any format just as easily. Just
>>> because you can't is hardly an argument. That's why we have computers in
>>> the first place. To do all the boring tasks that can easily be described.
>>>
>>> It's a long time since computers also stopped using decimal. Should they
>>> go back to that because that is also in fact what you use?
>>
>> I am puzzled why your answer went off on a tangent.
>
> The answer goes off on a tangent because the argument is basically
> "because I like it". Which makes it a rather meaningless argument.
>
> A computer don't really care about how you read numbers, and don't find
> one order "easier" than any other.
>
> And when you work on the computer, you are expressing the value as a 8-,
> 16-, 32-, or 64-bit number, or whatever.
>
> And that is true no matter if we talk about a little-endian or
> big-endian computer. What this is about is then just in which order are
> the sub-parts of this number stored in memory, and retrieved again. When
> you are operating on it, you are not working on these subparts.
Sometimes you are.
--
Pete
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414331 is a reply to message #414326] |
Sat, 30 April 2022 20:24 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>> OTOH, there’s a lot to be said for maintaining compatibility with others.
>> If nothing else, there are fewer things to be surprised by when moving to a
>> new system. Everyone once had there own version of BCD because there may
>> have been an unexpected advantage in having a particular character or
>> arrangement. ASCII and EBCDIC were developed to standardize on one good
>> choice over many other possibilities.
>
> from post in thread couple weeks ago ... biggest computer goof, 360 was
> supposed to be ASCII, by the (IBM) father of ASCII, gone 404 from
> wayback machine:
> https://web.archive.org/web/20180513184025/http://www.bobbem er.com/P-BIT.HTM
>
> I mention this because it is a classic software mistake. IBM was going
> to announce the 360 in 1964 April as an ASCII machine, but their
> printers and punches were not ready to handle ASCII, and IBM just HAD to
> announce. So T.V. Learson (my boss's boss) decided to do both, as IBM
> had a store of spendable money. They put in the P-bit. Set one way, it
> ran in EBCDIC. Set the other way, it ran in ASCII.
>
> ... snip ...
>
> other Bemmer computer history
> https://web.archive.org/web/20180402200149/http://www.bobbem er.com/HISTORY.HTM
>
> Bemmer refs:
> https://en.wikipedia.org/wiki/Bob_Bemer
> https://history.computer.org/pioneers/bemer.html
>
> Bemer is the inventor of the words "Cobol," and "CODASYL," six ASCII
> characters, and the concepts of registry and escape sequences in
> character codes. He also invented the term and defined the nature of the
> "software factory." At IBM he developed the first load-and-go system
> (PRINT I) and also was responsible for the implementation of the
> programming system FORTRANSIT, which provided a quick first compiler for
> the IBM 650 computer, and was the first programming language to run both
> decimal (IBM 650) and binary (IBM 704) computers. For the support of
> commercial programming Bemer developed PRINT I; in the late 1950s he
> developed XTRAN, a step towards Algol, and "Commercial Translator,"
> which became a significant input to Cobol. His major Cobol innovations
> were the IDENTIFICATION and ENVIRONMENT divisions, and the PICTURE
> clause.
Big woo-hoo on the first two, but picture is sheer genius. IBM was smart to
bring it into PL/I.
Bemer is a very underrated figure from computer history. He seems to have
had his finger in a lot of pies.
--
Pete
|
|
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414333 is a reply to message #414322] |
Sat, 30 April 2022 22:10 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Johnny Billquist <bqt@softjar.se> writes:
> On 2022-04-29 16:29, Dan Espen wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> So it's exactly because "you like it"?
>>>
>>> It's a computer. It can deal with any format just as easily. Just
>>> because you can't is hardly an argument. That's why we have computers
>>> in the first place. To do all the boring tasks that can easily be
>>> described.
>>>
>>> It's a long time since computers also stopped using decimal. Should
>>> they go back to that because that is also in fact what you use?
>> Yes.
>> Besides all that, it seems that your argument is that there is no
>> reason
>> to make computers easier to use.
>
> In which way are they easier to use with one byte order than the
> other? Do you have problems using any x86 based machines because of
> the byte order? Do you normally even notice the byte order?
Nope, not normally.
> I can tell you that on the PDP-11, which I use all the time, I very
> seldom is bothered by the byte order. However, once in a while, if I
> want to just check some integer as just a byte, I am actually happy
> that I use the same address as if I refer to the value as a word.
> Basically, type conversions are very simple with little endian order.
>
> So, which is "easier to use"?
Isn't it obvious which is easier?
It's the one where you don't have to rearrange the bytes.
> Or are you saying that it's the decimal aspect that you miss, and
> which is the "easier to use"?
>
> Johnny
I programmed IBM 14xx systems for more than a few years.
I never did like having to count 0-9 A-F.
--
Dan Espen
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414337 is a reply to message #414333] |
Sun, 01 May 2022 01:18 |
|
|
Originally posted by: J. Clarke
On Sat, 30 Apr 2022 22:10:54 -0400, Dan Espen <dan1espen@gmail.com>
wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>
>> On 2022-04-29 16:29, Dan Espen wrote:
>>> Johnny Billquist <bqt@softjar.se> writes:
>>>
>>>> So it's exactly because "you like it"?
>>>>
>>>> It's a computer. It can deal with any format just as easily. Just
>>>> because you can't is hardly an argument. That's why we have computers
>>>> in the first place. To do all the boring tasks that can easily be
>>>> described.
>>>>
>>>> It's a long time since computers also stopped using decimal. Should
>>>> they go back to that because that is also in fact what you use?
>>> Yes.
>>> Besides all that, it seems that your argument is that there is no
>>> reason
>>> to make computers easier to use.
>>
>> In which way are they easier to use with one byte order than the
>> other? Do you have problems using any x86 based machines because of
>> the byte order? Do you normally even notice the byte order?
>
> Nope, not normally.
>
>> I can tell you that on the PDP-11, which I use all the time, I very
>> seldom is bothered by the byte order. However, once in a while, if I
>> want to just check some integer as just a byte, I am actually happy
>> that I use the same address as if I refer to the value as a word.
>> Basically, type conversions are very simple with little endian order.
>>
>> So, which is "easier to use"?
>
> Isn't it obvious which is easier?
> It's the one where you don't have to rearrange the bytes.
The only time I recall having to rearrange bytes I had to deal on a PC
with binaries created on a Z. Fortunately they were all fixed-point.
If they had been floating point I would have had a _lot_ of fun.
>> Or are you saying that it's the decimal aspect that you miss, and
>> which is the "easier to use"?
>>
>> Johnny
>
> I programmed IBM 14xx systems for more than a few years.
> I never did like having to count 0-9 A-F.
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414340 is a reply to message #414333] |
Sun, 01 May 2022 14:54 |
|
|
Originally posted by: Johnny Billquist
On 2022-05-01 04:10, Dan Espen wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>
>> I can tell you that on the PDP-11, which I use all the time, I very
>> seldom is bothered by the byte order. However, once in a while, if I
>> want to just check some integer as just a byte, I am actually happy
>> that I use the same address as if I refer to the value as a word.
>> Basically, type conversions are very simple with little endian order.
>>
>> So, which is "easier to use"?
>
> Isn't it obvious which is easier?
> It's the one where you don't have to rearrange the bytes.
When do you rearrange bytes?
When the computer read an integer that is more than one byte, it does
the byte order processing, not you.
>> Or are you saying that it's the decimal aspect that you miss, and
>> which is the "easier to use"?
>>
>> Johnny
>
> I programmed IBM 14xx systems for more than a few years.
> I never did like having to count 0-9 A-F.
:-D
Johnny
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414341 is a reply to message #414337] |
Sun, 01 May 2022 14:56 |
|
|
Originally posted by: Johnny Billquist
On 2022-05-01 07:18, J. Clarke wrote:
> On Sat, 30 Apr 2022 22:10:54 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-04-29 16:29, Dan Espen wrote:
>>>> Johnny Billquist <bqt@softjar.se> writes:
>>>>
>>>> > So it's exactly because "you like it"?
>>>> >
>>>> > It's a computer. It can deal with any format just as easily. Just
>>>> > because you can't is hardly an argument. That's why we have computers
>>>> > in the first place. To do all the boring tasks that can easily be
>>>> > described.
>>>> >
>>>> > It's a long time since computers also stopped using decimal. Should
>>>> > they go back to that because that is also in fact what you use?
>>>> Yes.
>>>> Besides all that, it seems that your argument is that there is no
>>>> reason
>>>> to make computers easier to use.
>>>
>>> In which way are they easier to use with one byte order than the
>>> other? Do you have problems using any x86 based machines because of
>>> the byte order? Do you normally even notice the byte order?
>>
>> Nope, not normally.
>>
>>> I can tell you that on the PDP-11, which I use all the time, I very
>>> seldom is bothered by the byte order. However, once in a while, if I
>>> want to just check some integer as just a byte, I am actually happy
>>> that I use the same address as if I refer to the value as a word.
>>> Basically, type conversions are very simple with little endian order.
>>>
>>> So, which is "easier to use"?
>>
>> Isn't it obvious which is easier?
>> It's the one where you don't have to rearrange the bytes.
>
> The only time I recall having to rearrange bytes I had to deal on a PC
> with binaries created on a Z. Fortunately they were all fixed-point.
> If they had been floating point I would have had a _lot_ of fun.
Yes. That is the one time when it matters. When you are communicating
between two different machines with different byte order.
Then you'll need to rearrange the bytes on one side or the other.
It becomes just a convention on deciding which side shall do the
rearranging.
In the Internet world, there is a defined network byte order, which is
big endian. Which is when most people ever notice.
Johnny
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414342 is a reply to message #414330] |
Sun, 01 May 2022 14:58 |
|
|
Originally posted by: Johnny Billquist
On 2022-05-01 02:24, Peter Flass wrote:
> Johnny Billquist <bqt@softjar.se> wrote:
>> A computer don't really care about how you read numbers, and don't find
>> one order "easier" than any other.
>>
>> And when you work on the computer, you are expressing the value as a 8-,
>> 16-, 32-, or 64-bit number, or whatever.
>>
>> And that is true no matter if we talk about a little-endian or
>> big-endian computer. What this is about is then just in which order are
>> the sub-parts of this number stored in memory, and retrieved again. When
>> you are operating on it, you are not working on these subparts.
>
> Sometimes you are.
Indeed. And when I want to read my 64-bit integer as an 8-bit integer, I
happen to like that I can refer to the value using the same address. :-)
But the other case is just when you want to convert from one byte order
to another. But you normally have functions, or even instructions in the
cpu to deal with that.
Johnny
|
|
|
|
| Re: Big-endian history, What's different, was Why did Dennis Ritchie write [message #414343 is a reply to message #414332] |
Sun, 01 May 2022 15:00 |
|
|
Originally posted by: Johnny Billquist
On 2022-05-01 04:02, John Levine wrote:
> According to Johnny Billquist <bqt@softjar.se>:
>> And I can't see that either is superior to the other.
>> Both have their pros and cons.
>
> Yup. Several decades of people arguing about big vs little endian have
> made it abundantly clear that neither has a significant practical
> advantage over the other, although it remains a minor pain to convert
> from one to the other.
Usually, the pain is minimal. On a PDP-11, you have an instruction for
that: SWAB
Johnny
|
|
|
|
| Re: byte me, was What's different, was Why did Dennis Ritchie write that [message #414344 is a reply to message #414333] |
Sun, 01 May 2022 16:10 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Dan Espen <dan1espen@gmail.com>:
>> So, which is "easier to use"?
>
> Isn't it obvious which is easier?
> It's the one where you don't have to rearrange the bytes.
Oh, OK. All of the data structures in Internet protocols like TCP, IP,
and NFS are big-endian, and obviously every computer used in this argument
is on the Internet.
So big-endian wins. Glad we sorted that out.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414345 is a reply to message #414341] |
Sun, 01 May 2022 17:25 |
|
|
Originally posted by: pmaydell
In article <t4ml48$fhr$3@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
> Yes. That is the one time when it matters. When you are communicating
> between two different machines with different byte order.
> Then you'll need to rearrange the bytes on one side or the other.
If you're really unlucky there may be three machines involved :-)
I once had to write code to handle working with images that
ran in a word-invariant[*] little-endian VM running on a host
that might be either big or little endian and where the image
data was passed to an X server that might be either big or little
endian (in the more conventional byte-invariant way)...
[*] word-invariant meaning "32-bit quantities need not be
swapped, but for wrong-endian byte access you XOR the address
with 3, and for wrong-endian 16-bit access XOR with 2". Also
seen in early Arm CPUs (later architecture versions switched
to byte-invariant).
-- PMM
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414350 is a reply to message #414337] |
Sun, 01 May 2022 20:49 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Sat, 30 Apr 2022 22:10:54 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-04-29 16:29, Dan Espen wrote:
>>>> Johnny Billquist <bqt@softjar.se> writes:
>>>>
>>>> > So it's exactly because "you like it"?
>>>> >
>>>> > It's a computer. It can deal with any format just as easily. Just
>>>> > because you can't is hardly an argument. That's why we have computers
>>>> > in the first place. To do all the boring tasks that can easily be
>>>> > described.
>>>> >
>>>> > It's a long time since computers also stopped using decimal. Should
>>>> > they go back to that because that is also in fact what you use?
>>>> Yes.
>>>> Besides all that, it seems that your argument is that there is no
>>>> reason
>>>> to make computers easier to use.
>>>
>>> In which way are they easier to use with one byte order than the
>>> other? Do you have problems using any x86 based machines because of
>>> the byte order? Do you normally even notice the byte order?
>>
>> Nope, not normally.
>>
>>> I can tell you that on the PDP-11, which I use all the time, I very
>>> seldom is bothered by the byte order. However, once in a while, if I
>>> want to just check some integer as just a byte, I am actually happy
>>> that I use the same address as if I refer to the value as a word.
>>> Basically, type conversions are very simple with little endian order.
>>>
>>> So, which is "easier to use"?
>>
>> Isn't it obvious which is easier?
>> It's the one where you don't have to rearrange the bytes.
>
> The only time I recall having to rearrange bytes I had to deal on a PC
> with binaries created on a Z. Fortunately they were all fixed-point.
> If they had been floating point I would have had a _lot_ of fun.
I used to think that, but it’s pretty simple. Besides the fact that there’s
code available, which I didn’t know about, I did just this when re-hosting
Iron Spring PL/I from a Z to x86. Of course I didn’t have to handle edge
cases, but the general case is no problem. I think I kept the code,
although I haven’t needed it since.
>
>>> Or are you saying that it's the decimal aspect that you miss, and
>>> which is the "easier to use"?
I still “sort of” recall the 1620 (decimal) instruction we typed on the
console to restart the monitor.
>>>
>>> Johnny
>>
>> I programmed IBM 14xx systems for more than a few years.
>> I never did like having to count 0-9 A-F.
>
--
Pete
|
|
|
|
| Re: byte me, was What's different, was Why did Dennis Ritchie write that [message #414353 is a reply to message #414344] |
Mon, 02 May 2022 01:20 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> Oh, OK. All of the data structures in Internet protocols like TCP, IP,
> and NFS are big-endian, and obviously every computer used in this argument
> is on the Internet.
>
> So big-endian wins. Glad we sorted that out.
IBM had different (interesting?) "bit" order issue ... its
telecommunication controllers stored arriving bits starting in the low
order bit position in a byte (and started transmitting bits from low
order position).
Ran into the problem (late 60s) when we were building a clone
telecommunication controller (built 360 mainframe channel attached card
for an Interdata/3 programmed to emulate the ibm controller). Initial
tests had garbage because simple assumption the initial arrived bit went
into the higher order bit position and then going left to right as they
arrived and then moved to the next byte ... basically "translate" tables
had to convert from storage order to bit (within byte) reversing order
.... to compensate. For ibm selectric terminals ... things were being
translated from ebcdic to tilt/rotate addressing of the selectric ball
anyway ... so the same translate tables is fiddled to compensate for the
bit reversal ... and then ebcdic to ascii translate ... but bit-reversed
so that when transmitted to terminal control unit which would reverse
for transmitting down the line.
Things got more interesting for ASCII TCP ... which came in via
non-terminal controller so didn't have the bit-within-byte reversal
.... two different sets of EBCDIC<->ASCII translate tables ... one set
for terminals where data went through terminal controller and different
set for any ascii moved thru non-terminal controllers (w/o the
bit-within-byte reversal).
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: byte me, was What's different, was Why did Dennis Ritchie write that [message #414360 is a reply to message #414353] |
Mon, 02 May 2022 19:56 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> John Levine <johnl@taugh.com> writes:
>> Oh, OK. All of the data structures in Internet protocols like TCP, IP,
>> and NFS are big-endian, and obviously every computer used in this argument
>> is on the Internet.
>>
>> So big-endian wins. Glad we sorted that out.
>
> IBM had different (interesting?) "bit" order issue ... its
> telecommunication controllers stored arriving bits starting in the low
> order bit position in a byte (and started transmitting bits from low
> order position).
>
> Ran into the problem (late 60s) when we were building a clone
> telecommunication controller (built 360 mainframe channel attached card
> for an Interdata/3 programmed to emulate the ibm controller). Initial
> tests had garbage because simple assumption the initial arrived bit went
> into the higher order bit position and then going left to right as they
> arrived and then moved to the next byte ... basically "translate" tables
> had to convert from storage order to bit (within byte) reversing order
> ... to compensate. For ibm selectric terminals ... things were being
> translated from ebcdic to tilt/rotate addressing of the selectric ball
> anyway ... so the same translate tables is fiddled to compensate for the
> bit reversal ... and then ebcdic to ascii translate ... but bit-reversed
> so that when transmitted to terminal control unit which would reverse
> for transmitting down the line.
>
> Things got more interesting for ASCII TCP ... which came in via
> non-terminal controller so didn't have the bit-within-byte reversal
> ... two different sets of EBCDIC<->ASCII translate tables ... one set
> for terminals where data went through terminal controller and different
> set for any ascii moved thru non-terminal controllers (w/o the
> bit-within-byte reversal).
>
This was my first experience with ASCII, and my reaction was”what a p** of
sh*t.” It was only later that I realized that this was an artifact of the
comm controller and not an inherent property of ASCII.
--
Pete
|
|
|
|
|
|
| Re: byte me, was What's different, was Why did Dennis Ritchie write that [message #414362 is a reply to message #414361] |
Mon, 02 May 2022 23:00 |
|
|
Originally posted by: J. Clarke
On Mon, 02 May 2022 14:50:36 -1000, Anne & Lynn Wheeler
<lynn@garlic.com> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>> This was my first experience with ASCII, and my reaction was”what a p** of
>> sh*t.” It was only later that I realized that this was an artifact of the
>> comm controller and not an inherent property of ASCII.
>
> other trivia: when the ASCII port scanner "upgrade" arrived to be
> installed in the 360 telecommunication controller ... it came in a
> "Heathkit" box
Apropos of nothing, I miss Heathkit. Got a 21" Heathkit TV for my
(IIRC) 15th birthday. Carried that thing in to school so the physics
class could watch the Apollo 10 launch (no, my high school apparently
did not own a television).
|
|
|
|
| Re: byte me, was What's different, was Why did Dennis Ritchie write that [message #414367 is a reply to message #414362] |
Tue, 03 May 2022 11:06 |
D.J.
Messages: 821
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 02 May 2022 23:00:32 -0400, J. Clarke
<jclarke.873638@gmail.com> wrote:
> On Mon, 02 May 2022 14:50:36 -1000, Anne & Lynn Wheeler
> <lynn@garlic.com> wrote:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>> This was my first experience with ASCII, and my reaction waswhat a p** of
>>> sh*t. It was only later that I realized that this was an artifact of the
>>> comm controller and not an inherent property of ASCII.
>>
>> other trivia: when the ASCII port scanner "upgrade" arrived to be
>> installed in the 360 telecommunication controller ... it came in a
>> "Heathkit" box
>
> Apropos of nothing, I miss Heathkit. Got a 21" Heathkit TV for my
> (IIRC) 15th birthday. Carried that thing in to school so the physics
> class could watch the Apollo 10 launch (no, my high school apparently
> did not own a television).
One of the guys on the US Navy ship got permission to build a Heathkit
television in one of his work spaces. He measured and it would fit out
of the hatch. Yes, a small work space.
Yes, the manual gave a certain size. But the chassis was about an
eighth of an inch too wide. He had to partially dismantle it to get it
out.
--
Jim
|
|
|
|
| Re: Big-endian history, What's different, was Why did Dennis Ritchie write [message #414560 is a reply to message #414343] |
Thu, 19 May 2022 19:12 |
chris
Messages: 130
Registered: September 2012
Karma: 0
|
Senior Member |
|
|
On 05/01/22 20:00, Johnny Billquist wrote:
> On 2022-05-01 04:02, John Levine wrote:
>> According to Johnny Billquist <bqt@softjar.se>:
>>> And I can't see that either is superior to the other.
>>> Both have their pros and cons.
>>
>> Yup. Several decades of people arguing about big vs little endian have
>> made it abundantly clear that neither has a significant practical
>> advantage over the other, although it remains a minor pain to convert
>> from one to the other.
>
> Usually, the pain is minimal. On a PDP-11, you have an instruction for
> that: SWAB
>
> Johnny
Exactly, beat me too it...
|
|
|
|
| Re: Big-endian history, What's different, was Why did Dennis Ritchie write [message #414562 is a reply to message #414560] |
Fri, 20 May 2022 11:22 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
chris <chris-nospam@tridac.net> writes:
> On 05/01/22 20:00, Johnny Billquist wrote:
>> On 2022-05-01 04:02, John Levine wrote:
>>> According to Johnny Billquist <bqt@softjar.se>:
>>>> And I can't see that either is superior to the other.
>>>> Both have their pros and cons.
>>>
>>> Yup. Several decades of people arguing about big vs little endian have
>>> made it abundantly clear that neither has a significant practical
>>> advantage over the other, although it remains a minor pain to convert
>>> from one to the other.
>>
>> Usually, the pain is minimal. On a PDP-11, you have an instruction for
>> that: SWAB
>>
>> Johnny
>
> Exactly, beat me too it...
Pretty much every modern processor today has byte swapping instructions,
most of which handle 2-byte, 4-byte and 8-byte swaps.
Classic network APIs include functions to handle the byteswapping, such
as iton and ntoi.
Our I/O bus hardware can do various swap operations with various permutations
(word swaps, byte swaps, dword swaps et. al.).
|
|
|
|
| Re: Big-endian history, What's different, was Why did Dennis Ritchie write [message #414563 is a reply to message #414562] |
Fri, 20 May 2022 15:06 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> chris <chris-nospam@tridac.net> writes:
>> On 05/01/22 20:00, Johnny Billquist wrote:
>>> On 2022-05-01 04:02, John Levine wrote:
>>>> According to Johnny Billquist <bqt@softjar.se>:
>>>> > And I can't see that either is superior to the other.
>>>> > Both have their pros and cons.
>>>>
>>>> Yup. Several decades of people arguing about big vs little endian have
>>>> made it abundantly clear that neither has a significant practical
>>>> advantage over the other, although it remains a minor pain to convert
>>>> from one to the other.
>>>
>>> Usually, the pain is minimal. On a PDP-11, you have an instruction for
>>> that: SWAB
>>>
>>> Johnny
>>
>> Exactly, beat me too it...
It used to be a problem because there was so much cr@ppy C code around that
assumed little-endian. Now that everyone is aware of it, the problem is
mostly gone.
>
> Pretty much every modern processor today has byte swapping instructions,
> most of which handle 2-byte, 4-byte and 8-byte swaps.
>
> Classic network APIs include functions to handle the byteswapping, such
> as iton and ntoi.
>
> Our I/O bus hardware can do various swap operations with various permutations
> (word swaps, byte swaps, dword swaps et. al.).
>
--
Pete
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #415484 is a reply to message #413981] |
Sun, 24 July 2022 12:34 |
|
|
Originally posted by: Bud Frede
Johnny Billquist <bqt@softjar.se> writes:
> On 2022-04-11 23:22, John Levine wrote:
>> According to Peter Maydell <pmaydell@chiark.greenend.org.uk>:
>>>> The main use for big-endian nowadays is to run zArchitecture and POWER
>>>> code. Byte swapping network data formats isn't that big a deal.
>>>
>>> It is apparently a big deal if you have a lot of legacy C code
>>> that was sloppily written to do networking stuff on embedded
>>> MIPS CPUs, ...
>> Oh, I totally believe it. Anyone can write bad code, it's not
>> limited
>> to network data. I would have said there are more POWER chips than
>> MIPS but now that someone mentioned all the MIPS based routers, who
>> knows.
>
> Yeah. I would have guessed the other way around. Plenty of MIPS in
> lots of places. Not seen that many POWER based machines ever. But
> maybe there are more out there that I'm not aware of.
Mikrotik is still shipping network devices with MIPS and TILE
CPUs, as well as ARM. They were still selling routers with PPC CPUs too
as of a few years ago.
It does seem like they're moving to ARM for newer designs though.
https://mikrotik.com/products
I have one of their routers with a MediaTek MIPS CPU. It's a pretty
amazing little device, and it was only US$60. It's perfect for my home
network and is more than adequate to handle my internet connection
(300Mbps).
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #415485 is a reply to message #413984] |
Sun, 24 July 2022 12:44 |
|
|
Originally posted by: Bud Frede
scott@slp53.sl.home (Scott Lurndal) writes:
> Johnny Billquist <bqt@softjar.se> writes:
>> On 2022-04-11 23:22, John Levine wrote:
>>> According to Peter Maydell <pmaydell@chiark.greenend.org.uk>:
>>>> > The main use for big-endian nowadays is to run zArchitecture and POWER
>>>> > code. Byte swapping network data formats isn't that big a deal.
>>>>
>>>> It is apparently a big deal if you have a lot of legacy C code
>>>> that was sloppily written to do networking stuff on embedded
>>>> MIPS CPUs, ...
>>>
>>> Oh, I totally believe it. Anyone can write bad code, it's not limited
>>> to network data. I would have said there are more POWER chips than
>>> MIPS but now that someone mentioned all the MIPS based routers, who
>>> knows.
>>
>> Yeah. I would have guessed the other way around. Plenty of MIPS in lots
>> of places. Not seen that many POWER based machines ever. But maybe there
>> are more out there that I'm not aware of.
>
> Likewise, I've never seen a Power machine in the real world. MIPS
> machines on the other hand (from SGI and in modern networking appliances,
> including Cisco and most of the major backbone vendors) abounded.
I worked with AIX on POWER (6 and then 7) at a PPOE. The hardware was
really nice. The OS was a bit odd, but I was a Solaris admin learning
AIX, so I had preconceived notions about how to do things. :-)
I do think that the overall AIX/POWER ecosystem, with its management
tools, virtualization, redundancy, and everything being hot-swap, was
very nice to work with.
|
|
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #415493 is a reply to message #415490] |
Sun, 24 July 2022 16:56 |
D.J.
Messages: 821
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 24 Jul 2022 19:52:07 +0100, Ahem A Rivet's Shot
<steveo@eircom.net> wrote:
> On Sun, 24 Jul 2022 12:44:44 -0400
> Bud Frede <frede@mouse-potato.com> wrote:
>
>> I worked with AIX on POWER (6 and then 7) at a PPOE. The hardware was
>> really nice. The OS was a bit odd, but I was a Solaris admin learning
>> AIX, so I had preconceived notions about how to do things. :-)
>
> AIX was odd coming from *any* other unix background, at least
> smitty made it discoverably odd, without smitty it would have been far
> harder to get to grips with.
We had an AIX work staton at university my last year, about 1989/90.
For Internet accounts. There was a 2 gigabyte limit on hard drives,
apparently lifted later on.
We had only BITNET up to that point.
And many of the option letters for the commands, had been changed.
Very confusing for those of us who had several UNIX SYS5RV books.
I got on an AIX newsgroup, weekly digest, and I was told, after I
asked a few questions, that the correct pronounciation was 'aches' as
in painful to use.
--
Jim
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #415500 is a reply to message #415493] |
Sun, 24 July 2022 23:02 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
D.J. <chucktheouch@gmail.com> writes:
> We had an AIX work staton at university my last year, about 1989/90.
> For Internet accounts. There was a 2 gigabyte limit on hard drives,
> apparently lifted later on.
>
> We had only BITNET up to that point.
>
> And many of the option letters for the commands, had been changed.
> Very confusing for those of us who had several UNIX SYS5RV books.
>
> I got on an AIX newsgroup, weekly digest, and I was told, after I
> asked a few questions, that the correct pronounciation was 'aches' as
> in painful to use.
Lots of IBM (mainframe) had problems after the gov. legal action and the
23Jun1969 unbundle announcement starting to charge for SE services,
maintenance, (application) software, etc (at the time management made
the case kernel software should still be free) ... with rule that
monthly charge had to cover original development plus ongoing
development and mainteance .... where the traditional enormous software
groups resulted in "formulae" prices that nobody would pay.
The hudson valley/POK favorite son (batch) software was especially prone
to this.
Things were somewhat different up at the science center. At the time the
official operating system for (virtual memory) 360/67 was TSS/360 and
had 1200 people working on it, the science center had 12 people doing
CP67/CMS
Some of the MIT/7094 CTSS people
https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System went to the
5th flr, project mac, and MULTICS.
https://en.wikipedia.org/wiki/Multics
(and folkore, UNIX as a simplified version of MUTLICS)
Others went to the 4th flr, IBM Cambridge Science Center, did virtual
machine CP40/CMS (on 360/40 with hardware mods for virtual memory,
morphs into CP67/CMS when 360/67 standard with virtual memory becomes
available, precursor to vm370), online and performance apps, CTSS RUNOFF
redid for CMS as SCRIPT, GML invented at science center in 1969 (and GML
tag processing added to SCRIPT, a decade later GML morphs into ISO SGML
and after another decade morphs into HTML at CERN), networking, etc.
https://en.wikipedia.org/wiki/CP/CMS
https://en.wikipedia.org/wiki/Conversational_Monitor_System
some more CP67/CMS and VM370/CMS history
http://www.leeandmelindavarian.com/Melinda#VMHist
before msdos
https://en.wikipedia.org/wiki/MS-DOS
there was Seattle computer
https://en.wikipedia.org/wiki/Seattle_Computer_Products
before Seattle computer, there was cp/m
https://en.wikipedia.org/wiki/CP/M
before developing CP/M, kildall worked on CP/67-CMS at npg (gone 404,
but lives on at the wayback machine)
http://web.archive.org/web/20071011100440/http://www.khet.ne t/gmc/docs/museum/en_cpmName.html
npg
https://en.wikipedia.org/wiki/Naval_Postgraduate_School
Opel's obit ...
https://www.pcworld.com/article/243311/former_ibm_ceo_john_o pel_dies.html
According to the New York Times, it was Opel who met with Bill Gates,
CEO of the then-small software firm Microsoft, to discuss the
possibility of using Microsoft PC-DOS OS for IBM's about-to-be-released
PC. Opel set up the meeting at the request of Gates' mother, Mary
Maxwell Gates. The two had both served on the National United Way's
executive committee.
co-worker at the science center was responsible for (non-SNA) internal
network, technology also used for the corporate sponsored univ. BITNET
https://en.wikipedia.org/wiki/BITNET
when it came time to release JES2 NJE/NJI networking (which couldn't
meet the unbundling pricing even at $1200/month, even tho most of the
code originally came from HASP and carried "TUCC" in cols 68-71 for the
univ. where it was original done) ... the POK forces were also heavily
lobbying corporate to kill VM370 product (followon to CP67) and attempts
to release VNET/RSCS (used later for BITNET) were being blocked. The
JES2 group came up gimmick to announce JES2 networking as a combined
product with VNET/RSCS (which met unbundling pricing at $30/month)
.... where both NJE/NJI and VNET/RSCS would be priced at $600/month
(effectively VNET/RSCS revenue subsidizing NJE/NJI).
Roll forward to AIXv3 and RS/6000 ... there were hundreds of people
implementing IBM added value for UNIX. The folklore is that for
financial reasons, the AIX software group was moved into the same
organization as OS2 (so their financials, revenue & overhead/costs, were
combined into single reporting budget).
as undergraduate, when CP67 release 1 was installed at univ (3rd after
cambridge itself, and MIT Lincoln labs), I implemented dynamic adaptive
resource management (replacing existing scheduler). Later in the early
80s when I started doing some work on Unix ... the UNIX scheduler
scheduler appeared quite similar to CP67 release 1 scheduler (somewhat
assumed that they might share common history back to CTSS).
other trivia: in the morph of CP67->VM370, lots of features were
dropped or drastically simplified. Then the VM370 members in mainframe
SHARE
https://www.share.org/
.... were lobbying that the "wheeler" scheduler be implemented for VM370
(which eventually happened a decade after I had originally done it
for CP67 at the univ).
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
Members
Search
Help
Register
Login
Home
