| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413958 is a reply to message #413953] |
Mon, 11 April 2022 03:20   |
|
|
Originally posted by: pmaydell
In article <t2vkm1$316h$1@gal.iecc.com>, John Levine <johnl@taugh.com> wrote:
> According to Scott Lurndal <slp53@pacbell.net>:
>> Makes sense, since the main
>> use for big-endian nowadays is to handle IP packets without byteswapping
>> and for processing data (e.g. interoperability). Doesn't
>> really make sense for the instruction stream to be big-endian.
>
> 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, because the task of finding where in your millions
of lines of code the missing byteswap function calls need to
be added is nightmarish. It's a lot less risky to say "we'll
migrate CPU architecture for our product but we'll stick to
big-endian" if you've got yourself into that kind of situation.
This is why some architectures retain BE support even when 99%+
of their use is LE, and why Intel has a funky "bi-endian"
compiler where you mark up C typedefs and structs as "this
is big-endian" and the compiler inserts byteswaps for you...
-- PMM
|
|
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413960 is a reply to message #413955] |
Mon, 11 April 2022 04:58 |
|
|
Originally posted by: Johnny Billquist
On 2022-04-11 00:36, John Levine wrote:
> According to Johnny Billquist <bqt@softjar.se>:
>> On 2022-04-09 22:29, John Levine wrote:
>>> I have never been able to figure out why DEC made the PDP-11
>>> little-endian, when all previous byte addressed machines were big-endian.
>>> If you have a reference about why they did that, I would love to see
>>> it because I have looked and found nothing. If you want to guess about
>>> why, please don't, we've been through that a dozen times already.
>>
>> What other byte addressable machines were there in 1969?
>>
>> IBM 360, I assume. But do we have any others?
>
> The IBM Spectra 70 was a 360 semi-clone. Interdata had some
> byte addressed minis. They were all big-endian.
Before 1969? Hmm, maybe they did. Interdata was founded in 1966. They
must have had some product before 1970. Wikipedia claims their
architectures were based on the IBM 360. Never really used any
Interdata. Never liked them...
>> But disregarding previous machines, the obvious answer is that there is
>> less headache when wanting to refer to a value with different sizes. You
>> don't even have to guess about that one.
>
> I really wish people would stop guessing. None of the material about
> the origin of the PDP-11 says anything like that, and when you look at
> the screwed up middle-endian addressing of 32 bit numbers on later
> models of the -11, it's quite clear that wasn't what they were
> thinking.
I am not guessing. And I know the middle-endian stuff as well. Not that
it has anything to do with this.
DEC hadn't really done something similar to the byte addressable thing
before the PDP-11. Noticeable is that the bit numbering on the PDP-11
was the opposite to what DEC had done on any machine before. Which does
make sense in a similar way. You now suddenly had that the weight of a
bit was 2^n where n was the bit number. On all previous machines, bits
had been numbered from right to left, and started with 1.
And on the PDP-11 you also had that the weight of a byte was 256^n,
where n was the offset from the "base" address. As well as if you
addressed a value, independent of if using a byte or a word instruction,
you got the same value, assuming the value wasn't larger than could be
held in a byte.
These are all facts. Now, did DEC have other/additional reasons? That I
don't know, and I won't try to speculate on it. But the above reasons
clearly exist. And the EIS 32-bit middle-endian things are not relevant
because they were not in the mind of the people who designed the initial
machine. We could have a separate discussion on why the engineers who
did the EIS decided to do the words big-endian. That would be a *really*
interesting question. A whole bunch of DEC software on the PDP-11 still
went little endian, even for 32-bit. So clearly there were disagreements
even inside DEC about that one.
Johnny
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413961 is a reply to message #413960] |
Mon, 11 April 2022 09:01 |
|
|
Originally posted by: Johnny Billquist
On 2022-04-11 10:58, Johnny Billquist wrote:
>
> I am not guessing. And I know the middle-endian stuff as well. Not that
> it has anything to do with this.
> DEC hadn't really done something similar to the byte addressable thing
> before the PDP-11. Noticeable is that the bit numbering on the PDP-11
> was the opposite to what DEC had done on any machine before. Which does
> make sense in a similar way. You now suddenly had that the weight of a
> bit was 2^n where n was the bit number. On all previous machines, bits
> had been numbered from right to left, and started with 1.
Sigh. Numbered left to right I should have written. The PDP-11 numbers
the bits from right to left.
Johnny
|
|
|
|
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413964 is a reply to message #413960] |
Mon, 11 April 2022 14:22 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Johnny Billquist <bqt@softjar.se> writes:
> Before 1969? Hmm, maybe they did. Interdata was founded in 1966. They
> must have had some product before 1970. Wikipedia claims their
> architectures were based on the IBM 360. Never really used any
> Interdata. Never liked them...
up thread, my post about we built a 360 clone telecommunication using
interdata/3 (design/built channel interface board) ... which was
enhanced to interdata/4 for the channel interface and cluster of
interdata/3 for the port/line scanners.
--
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 #413972 is a reply to message #413958] |
Mon, 11 April 2022 17:22 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.
I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
happened to have a zero byte at location zero, and a lot of badly
written code depended on being able to dereference a null pointer
and get a null. So a whole generation of early Unix workstations
had to be sure they had a readable null byte at location zero, too.
--
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 #413974 is a reply to message #413960] |
Mon, 11 April 2022 17:41 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Johnny Billquist <bqt@softjar.se>:
>> The RCA Spectra 70 was a 360 semi-clone. Interdata had some
>> byte addressed minis. They were all big-endian.
>
> Before 1969?
Yes, the Internet Archive has a magazine ad for Interdata's early
machines from 1967.
>> I really wish people would stop guessing. None of the material about
>> the origin of the PDP-11 says anything like that, ...
> I am not guessing.
Of course you're guessing. You weren't there, and neither you nor I
know what the people at DEC were thinking when they designed the
PDP-11. Everything you say about the -11 was equally true when IBM
designed the 360, and they made it big-endian.
For all we know, DEC's motivation could have been something short term
like it saved a couple of gates in the KA-11 and let them squeeze the
processor onto one less card.
--
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 #413980 is a reply to message #413974] |
Tue, 12 April 2022 03:07 |
|
|
Originally posted by: Johnny Billquist
On 2022-04-11 23:41, John Levine wrote:
> According to Johnny Billquist <bqt@softjar.se>:
>>> I really wish people would stop guessing. None of the material about
>>> the origin of the PDP-11 says anything like that, ...
>
>> I am not guessing.
>
> Of course you're guessing. You weren't there, and neither you nor I
> know what the people at DEC were thinking when they designed the
> PDP-11. Everything you say about the -11 was equally true when IBM
> designed the 360, and they made it big-endian.
Am I guessing that the addressing is the same if you refer to a value as
a byte or a word gives the same value using the same address?
No. I am not.
Am I guessing that the value of a multibyte integer becomes 256^n where
n is the relative address of the byte from the base?
No. I am not.
Might DEC have had additional reasons? Maybe. But I'm not going to
speculate on that.
(Repeating what I wrote in the previous post. Maybe it gets through this
time? :-) )
Johnny
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413981 is a reply to message #413972] |
Tue, 12 April 2022 03:13 |
|
|
Originally posted by: Johnny Billquist
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.
> I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
> happened to have a zero byte at location zero, and a lot of badly
> written code depended on being able to dereference a null pointer
> and get a null. So a whole generation of early Unix workstations
> had to be sure they had a readable null byte at location zero, too.
I know this is true for Unix on PDP-11. Part of the reason being that
you don't want to waste a whole page, and people also weren't doing
clever enough things to just loose 64 bytes. But with the limited amount
of virtual memory available, even that might have been considered
wasteful. So it's totally understandable on the PDP-11, even if in a way
unfortunate. But did this really live on on the VAX?
I don't have any older BSD setup on any VAX, so I can't easily check this.
Johnny
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413983 is a reply to message #413972] |
Tue, 12 April 2022 04:26 |
|
|
Originally posted by: pmaydell
In article <t3267e$2ke5$1@gal.iecc.com>, John Levine <johnl@taugh.com> 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.
I think it's the combination of:
* a widely used big endian CPU in a particular market niche
* a use case that is constantly dealing with big endian
data (ie network packet fields) and so missing byteswaps
are likely to be pervasive rather than limited to a small
part of the codebase
* systems where you can get away with running a completely
different config to everybody else (embedded products can
be built for non-standard endianness; servers running
stock OSes need to go along with the rest of the world)
* directly buying CPUs and designing hardware around them,
not buying off-the-shelf systems
If you don't meet all of those then you just had to bite the
bullet and fix your endianness bugs like the rest of us :-)
-- PMM
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413984 is a reply to message #413981] |
Tue, 12 April 2022 09:56 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
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 also take exception at the characterization of "bad code". When
your design target is big-endian, there's no need to use byteswapping
interfaces.
>
>> I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
>> happened to have a zero byte at location zero, and a lot of badly
>> written code depended on being able to dereference a null pointer
>> and get a null. So a whole generation of early Unix workstations
>> had to be sure they had a readable null byte at location zero, too.
>
> I know this is true for Unix on PDP-11. Part of the reason being that
> you don't want to waste a whole page, and people also weren't doing
> clever enough things to just loose 64 bytes. But with the limited amount
> of virtual memory available, even that might have been considered
> wasteful. So it's totally understandable on the PDP-11, even if in a way
> unfortunate. But did this really live on on the VAX?
Yes. I also spent time circa 1990 fixing broken BSD utilities that
assumed accessing a null pointer would produce a zero value instead of
a SIGSEGV/SIGBUS.
|
|
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413986 is a reply to message #413984] |
Tue, 12 April 2022 12:09 |
Andy Leighton
Messages: 203
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 12 Apr 2022 13:56:45 GMT, Scott Lurndal <scott@slp53.sl.home> wrote:
> 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.
I used to work at a place that had standardised on IBM RS/6000 which
used POWER CPUs.
> MIPS
> machines on the other hand (from SGI and in modern networking appliances,
> including Cisco and most of the major backbone vendors) abounded.
I would guess that in addition to the IBM stuff, PowerPC also had a load
of Apple Macs and a load of games consoles. As well as a load of older
CISCO and Juniper routers.
--
Andy Leighton => andyl@azaal.plus.com
"We demand rigidly defined areas of doubt and uncertainty!"
- Douglas Adams
|
|
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413988 is a reply to message #413984] |
Tue, 12 April 2022 13:22 |
|
|
Originally posted by: Chris Adams
Once upon a time, Scott Lurndal <slp53@pacbell.net> said:
> 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.
If you include PowerPC, there of course were a number of generations of
Macs. Some old model TiVo DVRs also used PowerPCs.
While early Ciscos used MIPS CPUs, they moved to custom ASICs a long
time ago for the forwarding plane for better performance and handling of
route table growth. A significant portion of the Internet has run on
Juniper routers as well for quite a while, and they have only ever used
custom ASICs for forwarding, with mostly x86 and some PowerPC used for
the control plane.
--
Chris Adams <chris@cmadams.net>
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413989 is a reply to message #413985] |
Tue, 12 April 2022 14:21 |
|
|
Originally posted by: pmaydell
In article <20220412150344.5f0a74ebd70faf038599df35@eircom.net>,
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On Tue, 12 Apr 2022 13:56:45 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>
>> I also take exception at the characterization of "bad code". When
>> your design target is big-endian, there's no need to use byteswapping
>> interfaces.
>
> Agreed, if you have a task involving manipulation of big endian
> entities and have chosen a big endian processor for the job you can
> perfectly correctly forget about the problem.
>
> The code isn't bad, just not entirely portable but for embedded use
> not portable is fine.
....up until the point when you need to switch your embedded
product to a different CPU architecture, when it turns out
that actually it does matter. It's not that hard to put
the conceptually-required-but-happen-to-be-nop transforms in
as you go along. and it's awful to have to go back and
retrofit them, so I maintain that not doing so is indeed
sloppy practice.
-- PMM
|
|
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413991 is a reply to message #413980] |
Tue, 12 April 2022 14:49 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Johnny Billquist <bqt@softjar.se>:
>> Of course you're guessing. You weren't there, and neither you nor I
>> know what the people at DEC were thinking when they designed the
>> PDP-11. Everything you say about the -11 was equally true when IBM
>> designed the 360, and they made it big-endian.
>
> Am I guessing that the addressing is the same if you refer to a value as
> a byte or a word gives the same value using the same address?
>
> No. I am not. ...
Hi. To repeat the part of my message you apparently didn't read, all
the stuff you say is true. It was equally true about the big-endian
IBM 360.
We have no idea whether any of it affected DEC's design of the PDP-11,
or for that matter, the design of the IBM 360. You're guessing.
If you have any actual info about why DEC did it backward from everyone
else, a lot of us would be delighted to see it. But guesses don't help.
R's,
John
--
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 #413992 is a reply to message #413983] |
Tue, 12 April 2022 15:19 |
Jorgen Grahn
Messages: 606
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 2022-04-12, Peter Maydell wrote:
> In article <t3267e$2ke5$1@gal.iecc.com>, John Levine <johnl@taugh.com> 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.
>
> I think it's the combination of:
> * a widely used big endian CPU in a particular market niche
> * a use case that is constantly dealing with big endian
> data (ie network packet fields) and so missing byteswaps
> are likely to be pervasive rather than limited to a small
> part of the codebase
> * systems where you can get away with running a completely
> different config to everybody else (embedded products can
> be built for non-standard endianness; servers running
> stock OSes need to go along with the rest of the world)
Nitpick: They don't necessarily need to go along: most free Unix
software builds for big-endian and little-endian machines. I'm too
lazy to check if e.g. Debian Linux supports any big-endian
architectures right /now/, but they did supported PowerPC a few years
ago. That's thousands of correctly written programs.
> * directly buying CPUs and designing hardware around them,
> not buying off-the-shelf systems
>
> If you don't meet all of those then you just had to bite the
> bullet and fix your endianness bugs like the rest of us :-)
Yes. I find the best way to do that is to treat network buffers etc
as arrays of octets, and never casting them. Unless there's a
performance reason to take shortcuts.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413993 is a reply to message #413989] |
Tue, 12 April 2022 15:42 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
pmaydell@chiark.greenend.org.uk (Peter Maydell) writes:
> In article <20220412150344.5f0a74ebd70faf038599df35@eircom.net>,
> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>> On Tue, 12 Apr 2022 13:56:45 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>>> I also take exception at the characterization of "bad code". When
>>> your design target is big-endian, there's no need to use byteswapping
>>> interfaces.
>>
>> Agreed, if you have a task involving manipulation of big endian
>> entities and have chosen a big endian processor for the job you can
>> perfectly correctly forget about the problem.
>>
>> The code isn't bad, just not entirely portable but for embedded use
>> not portable is fine.
>
> ...up until the point when you need to switch your embedded
> product to a different CPU architecture, when it turns out
> that actually it does matter. It's not that hard to put
> the conceptually-required-but-happen-to-be-nop transforms in
> as you go along. and it's awful to have to go back and
> retrofit them, so I maintain that not doing so is indeed
> sloppy practice.
Actually, the modern CPU's that one would transition that
workload to are generally ARMv8 based, where the applications
can run in little or big-endian mode, while the kernel executes
in either big or little-endian mode.
And for most of those internet protocol accelerator chips (now
known as DPUs), there's custom packet processing hardware in use
that makes porting to other DPU's more complicated leaving aside
any byte order issues.
Most companies using DPUs are transitioning to standard packet processing
frameworks (ODP, etc) rather than using bespoke code which makes
the code more portable to multiple vendors.
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #413994 is a reply to message #413987] |
Tue, 12 April 2022 15:52 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> Yep, fairly large project were I worked was on RS/6000. For a while
> IBM had a line of RS/6000 workstations to compete with Sun. Never
> liked smit.
the last product did at IBM ... started out HA/6000 to move NYTimes
newspaper system (ATEX) off VAXCluster. I renamed it HA/CMP when I
started doing technically/scientific cluster scaleup with national labs
and commercial cluster scaleup with RDBMS vendors (oracle, informix,
sybase, ingres). It started out relying on the aixv3 journal/logging
filesystem for fast fallover.
https://en.wikipedia.org/wiki/IBM_High_Availability_Cluster_ Multiprocessing
The RDBMS vendors all had vaxcluster support in same source base as unix
... and so I did distributed lock manager with VAXCluster API semantics
to simplify the port. The RDBMS vendors also had their list of
VAXcluster shortcomings that needed improvement .... I had my own list
having worked on mainframe loosely-coupled (cluster) for a couple
decades and having been involved with System/R (original sql/relational)
implementation.
old post about JAN1992 meeting in Ellison's (oracle ceo) conference
room mention 16-way cluster by mid92 and 128-way cluster by ye92
http://www.garlic.com/~lynn/95.html#13
within a few weeks, cluster-scaleup is transferred, announced as
IBM supercomputer (for technical/scientific *ONLY*), and we were told we
couldn't work with anything involving more than four processors. We
leave IBM a few months later. Part of the issue was the mainframe
DB2 people were complaining if we were allowed to continue, it would
be years ahead of them.
After leaving IBM we ware then involved with multiple projects mostly in
the financial industry, although at one point, SUN asks me if I would
consider productizing and shipping
https://en.wikipedia.org/wiki/Spring_(operating_system)
had hardcopy, softcopy gone 404, but lives free at wayback
http://web.archive.org/web/20030404182953/http://java.sun.co m/people/kgh/spring/
From one of the Spring Papers:
A Client-Side Stub Interpreter
Petere B. Kessler
Abstract
We have built a research operating system in which all services are
presented through interfaces described by an interface description
language. The system consists of a micro-kernel that supports a small
number of these interfaces, and a large number of interfaces that are
implemented by user-level code. A typical service implements one or
more interfaces, but is a client of many other interfaces that are
implemented elsewhere in the system. We have an interface compiler
that generates client-side and service-side stubs to deliver calls
from clients to services providing location transparency if the client
and server are in different address spaces. The code for client-side
stubs was occupying a large amount of the text space on our clients,
so a stub interpreter was written to replace the client-side stub
methods. The result was that we traded 125k bytes of stub code for 13k
bytes of stub descriptions and 4k bytes of stub interpreter. This
paper describes the stub interpreter, the stub descriptions, and
discusses some alternatives.
.... snip ...
There was also financial company that used cluster oracle and HA/SUN for
the first stored-value (gift and merchant) magstripe cards in the US
.... and doing large pilot (with a couple large merchants & gas stations)
.... there was glitch and database was lost and had to be recreated with
all cards having original $$$ value.
I was brought in to be part of the review ... that opened with SUN VP
giving introducton ... I noted that it was almost word-for-word one of
my sales pitches for HA/CMP.
Turns out it was a couple hardware failures with human errors in between
over a couple month period (disk failure in RAID configuration,
fall-over, a system RAID driver card failure ... and one of the systems
was partially misconfigured).
--
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 #414000 is a reply to message #413951] |
Tue, 12 April 2022 19:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> John Levine <johnl@taugh.com> writes:
>> According to Acceptable Name <metta.crawler@gmail.com>:
>>>> I have never been able to figure out why DEC made the PDP-11
>>>> little-endian, when all previous byte addressed machines were big-endian.
>>
>>> I read somewhere that RISC-V is little endian because that was good for performance.
>>
>> The PDP-11 was in 1969, RISC-V was four decades later in 2010 by which
>> time the endian wars had largely burned out.
>
> I might argue that - big-endian processors are still available and
> widely used in packet processing hardware such as DPUs. It's true that
> most processors default to little-endian, but that's more because of the
> ubiquity of x86 than anything else.
>
>>
>> Data accesses in RISC-V are either endian set by a mode bit, code is
>> always little-endian. The manual claims that little-endian makes it
>> easier to look at instruction bits and see how long the instruction is
>> which I find unpersuasive.
>
> They'd have to byte-swap the 32-bit instruction before decoding if they
> accepted big-endian instructions or add a bunch of gates with
> a dependency on the endianness bit in a control register. That
> dependency would add complexity for OoO implementations.
>
> Same for ARMv8 where the 32-bit instructions are always little-endian.
>
> Makes sense, since the main
> use for big-endian nowadays is to handle IP packets without byteswapping
> and for processing data (e.g. interoperability). Doesn't
> really make sense for the instruction stream to be big-endian.
>
I would think big-endian is best for instruction decoding. Leaving aside
issues of cache access, the processor can load the first byte to determine
the format (and hence length) of the rest of the instruction, unless the
architecture stores the opcode in the low-order byte and reads that first
in little-endian format.
I forget the details of the Intel 432 architecture, but one of the things
that seems to me to be a misfeature is how much of an instruction had to be
read to begin decoding (IIRC).
--
Pete
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414001 is a reply to message #413955] |
Tue, 12 April 2022 19:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> According to Johnny Billquist <bqt@softjar.se>:
>> On 2022-04-09 22:29, John Levine wrote:
>>> I have never been able to figure out why DEC made the PDP-11
>>> little-endian, when all previous byte addressed machines were big-endian.
>>> If you have a reference about why they did that, I would love to see
>>> it because I have looked and found nothing. If you want to guess about
>>> why, please don't, we've been through that a dozen times already.
>>
>> What other byte addressable machines were there in 1969?
>>
>> IBM 360, I assume. But do we have any others?
>
> The IBM Spectra 70 was a 360 semi-clone. Interdata had some
> byte addressed minis. They were all big-endian.
Univac 9x00, which were mostly 360/20 clones. I think NCRs were decimal
machines.
>
>> But disregarding previous machines, the obvious answer is that there is
>> less headache when wanting to refer to a value with different sizes. You
>> don't even have to guess about that one.
>
> I really wish people would stop guessing. None of the material about
> the origin of the PDP-11 says anything like that, and when you look at
> the screwed up middle-endian addressing of 32 bit numbers on later
> models of the -11, it's quite clear that wasn't what they were
> thinking.
--
Pete
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414002 is a reply to message #413974] |
Tue, 12 April 2022 19:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> According to Johnny Billquist <bqt@softjar.se>:
>>> The RCA Spectra 70 was a 360 semi-clone. Interdata had some
>>> byte addressed minis. They were all big-endian.
>>
>> Before 1969?
>
> Yes, the Internet Archive has a magazine ad for Interdata's early
> machines from 1967.
>
>>> I really wish people would stop guessing. None of the material about
>>> the origin of the PDP-11 says anything like that, ...
>
>> I am not guessing.
>
> Of course you're guessing. You weren't there, and neither you nor I
> know what the people at DEC were thinking when they designed the
> PDP-11. Everything you say about the -11 was equally true when IBM
> designed the 360, and they made it big-endian.
IBM published a lot of material about what was going on with 360 design,
but I think all earlier computers were big-endian, so I suspect the issue
never came up. Little-endian was a screwball deviation.
>
> For all we know, DEC's motivation could have been something short term
> like it saved a couple of gates in the KA-11 and let them squeeze the
> processor onto one less card.
>
--
Pete
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414003 is a reply to message #413981] |
Tue, 12 April 2022 19:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Johnny Billquist <bqt@softjar.se> wrote:
> 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.
>
>> I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
>> happened to have a zero byte at location zero, and a lot of badly
>> written code depended on being able to dereference a null pointer
>> and get a null. So a whole generation of early Unix workstations
>> had to be sure they had a readable null byte at location zero, too.
>
> I know this is true for Unix on PDP-11. Part of the reason being that
> you don't want to waste a whole page, and people also weren't doing
> clever enough things to just loose 64 bytes. But with the limited amount
> of virtual memory available, even that might have been considered
> wasteful. So it's totally understandable on the PDP-11, even if in a way
> unfortunate. But did this really live on on the VAX?
> I don't have any older BSD setup on any VAX, so I can't easily check this.
>
> Johnny
>
On the other hand, there’s no quicker way to root out invalid memory
accesses than to have the machine trap. If nothing else let the OS trap
handler log the access and return null, so the program continues to work,
but now you have a record of what needs to be fixed.
--
Pete
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414004 is a reply to message #413984] |
Tue, 12 April 2022 19:55 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> 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 spent some time on a POWER AIX machine years back. I think now most POWER
chips are used in automotive control.
>
> I also take exception at the characterization of "bad code". When
> your design target is big-endian, there's no need to use byteswapping
> interfaces.
>
>>
>>> I am reminded of the BSD null pointer bug, in which BSD Unix on VAX
>>> happened to have a zero byte at location zero, and a lot of badly
>>> written code depended on being able to dereference a null pointer
>>> and get a null. So a whole generation of early Unix workstations
>>> had to be sure they had a readable null byte at location zero, too.
>>
>> I know this is true for Unix on PDP-11. Part of the reason being that
>> you don't want to waste a whole page, and people also weren't doing
>> clever enough things to just loose 64 bytes. But with the limited amount
>> of virtual memory available, even that might have been considered
>> wasteful. So it's totally understandable on the PDP-11, even if in a way
>> unfortunate. But did this really live on on the VAX?
>
> Yes. I also spent time circa 1990 fixing broken BSD utilities that
> assumed accessing a null pointer would produce a zero value instead of
> a SIGSEGV/SIGBUS.
>
>
--
Pete
|
|
|
|
|
|
| Re: Endian wars, What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414007 is a reply to message #414000] |
Tue, 12 April 2022 21:55 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
> I would think big-endian is best for instruction decoding. Leaving aside
> issues of cache access, the processor can load the first byte to determine
> the format (and hence length) of the rest of the instruction, unless the
> architecture stores the opcode in the low-order byte and reads that first
> in little-endian format.
Look at the x86. Its instruction format treats memory as a stream of
bytes. It is of course little-endian but its instruction format would
work about the same in big-endian.
On the PDP-11 instructions were a sequence of 16 bit words and the
memory was 16 bit words (or later perhaps larger cache lines) so again
instruction decoding would have worked pretty much the same in either
byte order.
--
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 #414008 is a reply to message #414002] |
Tue, 12 April 2022 22:21 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
>> PDP-11. Everything you say about the -11 was equally true when IBM
>> designed the 360, and they made it big-endian.
>
> IBM published a lot of material about what was going on with 360 design,
> but I think all earlier computers were big-endian, so I suspect the issue
> never came up.
The 360 was the first byte addressed machine. The earlier IBM
scientific machines were binary 36 bit word addressed (which explains
where the PDP-6, GE 635 and Univac 1100 came from) or decimal. Most of
the decimal machines were digit serial, other than the tube and drum
650 and the transistorized 7070 which were word addressed with 10
digit words. The small decimal scientific 1620 was digit addressed
with variable length numbers, in which an arithmetic instruction
addressed the low digit of the number which was at the highest
address, and it counted down to get the rest of the number, but some
other instructions and I/O addressed the leftmost digit or character
at the lowest address and counted up to get the rest of the record, so
I suppose that was more or less big-endian.
"Architecture of the IBM System/360" in the April 1964 IBM Journal of
R and D says a lot about their decision to use 8 rather than 6 bit
bytes (not totally obvious since characters then were six bits and
memory was expensive), ASCII vs EBCDIC, two's complement arithmetic,
binary registers rather than a stack, no decimal accumulators,
with decimal operand sizes given by a length in the instruction rather
than a field mark as in older machines. It also explains the mistaken
assumptions behind the hex floating point.
It says nothing whatsoever about byte order, other than implicitly in
a diagram about instruction formats and alignment. Evidently it seemed
obvious at the time.
> Little-endian was a screwball deviation.
Indeed.
--
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 #414012 is a reply to message #413993] |
Wed, 13 April 2022 03:52 |
|
|
Originally posted by: pmaydell
In article <tCk5K.165785$8V_7.34144@fx04.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
> pmaydell@chiark.greenend.org.uk (Peter Maydell) writes:
>> ...up until the point when you need to switch your embedded
>> product to a different CPU architecture, when it turns out
>> that actually it does matter. It's not that hard to put
>> the conceptually-required-but-happen-to-be-nop transforms in
>> as you go along. and it's awful to have to go back and
>> retrofit them, so I maintain that not doing so is indeed
>> sloppy practice.
>
> Actually, the modern CPU's that one would transition that
> workload to are generally ARMv8 based, where the applications
> can run in little or big-endian mode, while the kernel executes
> in either big or little-endian mode.
Yes, that's where we started. The major reason why
running BE there is even possible is to accomodate all
this legacy sloppily written code.
-- PMM
|
|
|
|
| Re: What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414013 is a reply to message #413992] |
Wed, 13 April 2022 04:06 |
|
|
Originally posted by: pmaydell
In article <slrnt5bk6c.2ude.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Tue, 2022-04-12, Peter Maydell wrote:
>> I think it's the combination of:
>> * a widely used big endian CPU in a particular market niche
>> * a use case that is constantly dealing with big endian
>> data (ie network packet fields) and so missing byteswaps
>> are likely to be pervasive rather than limited to a small
>> part of the codebase
>> * systems where you can get away with running a completely
>> different config to everybody else (embedded products can
>> be built for non-standard endianness; servers running
>> stock OSes need to go along with the rest of the world)
>
> Nitpick: They don't necessarily need to go along: most free Unix
> software builds for big-endian and little-endian machines. I'm too
> lazy to check if e.g. Debian Linux supports any big-endian
> architectures right /now/, but they did supported PowerPC a few years
> ago. That's thousands of correctly written programs.
That's kind of what I mean -- Debian doesn't, and never has,
supported big-endian Arm. Now of course Debian totally *could*
build all that software for BE Arm, because it works on
s390x and so on. But there aren't enough general users
out there for anybody to ship a distro for it. Which means
that if you run BE Arm you are absolutely running a
non-standard config where you had to build everything yourself,
and not a stock OS. The set of hardware configurations
you can get a stock OS for is a subset of all the possible
things one might be able to build. (For another example,
you can build x86-based systems that don't look like an
IBM PC, and for some embedded setups you might want to.
Your hardware will work fine, but if you want to run a stock
OS then it's got to look like an x86 PC.)
-- PMM
|
|
|
|
| Re: Endian wars, What's different, was Why did Dennis Ritchie write that UNIX was a modern implementation of CTSS? [message #414014 is a reply to message #414007] |
Wed, 13 April 2022 04:18 |
|
|
Originally posted by: pmaydell
In article <t35aiv$2gm6$2@gal.iecc.com>, John Levine <johnl@taugh.com> wrote:
> On the PDP-11 instructions were a sequence of 16 bit words and the
> memory was 16 bit words (or later perhaps larger cache lines) so again
> instruction decoding would have worked pretty much the same in either
> byte order.
Did the PDP-11 read the whole 16-bit instruction as a single
memory access? (I'm guessing it did.) If you load the whole
instruction at once, as any modern fixed-width-instruction
CPU will, you can lay out the instruction fields in it
however you like, because you've already got all of them.
I think my favourite oddball instruction encoding is
the transputer, which depending on how you think of
it is either a one-byte-per-instruction fixed width encoding,
or else a variable width encoding where you don't know what
the instruction operation is until the very last byte :-)
(Each byte is 4 bits of opcode and 4 bits of immediate
data; if you want a bigger immediate you use the PFIX and
NFIX instructions which shift-and-accumulate their 4 bit
immediate into the internal register that's building up the
immediate value that a subsequent 'real' insn uses.)
-- PMM
|
|
|
|
Members
Search
Help
Register
Login
Home
