| An Argument for Big-Endian: Packed Decimal [message #385723] |
Mon, 05 August 2019 17:35  |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
Generally speaking, the big-endian versus little-endian argument has been
interminable, and has generated more heat than light.
Historically, since computers were developed in the Western world, storage of
chracters in computer words was from "left" to "right", that is, from the most
significant part to the least significant part, basically without thought - it
was simply assumed to be the natural way to do it, as it corresponded to how
numbers and words were written by us on paper.
When advances in technology made it useful to build small-sized computers, with
a word length less than that of numbers it might be desired to calculate with on
those computers, some of those computers (one example is the Honeywell 316 and
related machines) would put the least significant part of a 32-bit number in the
first 16-bit word making it up.
This was done for the practical reason that adding two numbers together could
then proceed simply: go to the addresses where they're stored, get the least
significant parts first, add them, then use the carry from that for adding the
two most significant parts together.
The PDP-11 computer was a 16-bit computer made by Digital Equipment Corporation.
This company made aggressively priced minicomputers, but the PDP-11 was intended
to be more than just a run-of-the-mill minicomputer; instead of using an old-
fashioned ISA like that of DEC's own PDP-8 and PDP-4/7/9/15, or 16-bit machines
like the Honeywell 316 or the Hewlett-Packard 2115A, it was to be modern and
advanced, and in some ways similar to mainframes like the IBM System/360.
So, because it was to have a low price, it handled 32-bit numbers with their
least significant 16 bits first.
To make it less like an ordinary minicomputer, and more like a mainframe, the
byte ordering within a 32-bit integer was going to be consistent - like on the
System/360. It couldn't be ABCD, but instead of being CDAB, it could be DCBA.
Just put the first character in a 16-bit word in the least significant part, and
give that part the lower byte address!
This is how the idea of little-endian byte order was born.
The general belief today among computer scientists, it seems to me, is that the
industry should standardize on little-endian. Yes, big-endian seems more
familiar to people out of habit, but byte-order is just a convention.
Personally, I like big-endian myself. But I can see that it's an advantage that,
given that we address objects in memory by their lowest-addressed byte, the
place value for the first part is independent of length and thus always
constant.
But having the world of binary numbers used for arithmetic follow one rule, and
numbers as strings of ASCII characters that are read in and printed follow the
opposite rule... only works if those to worlds really are separate.
When the IBM System/360 came out, of course the PDP-11, which it partly helped
to inspire, didn't exist yet. So little-endian didn't exist as an alternative to
consider yet.
But despite that, if there had been a choice, big-endian would have been the
right choice for System/360.
The IBM System 360 mainframe, just like the microcomputer on your desktop,
handled character strings in its memory, even if they were in EBCDIC instead of
ASCII, and it also handled binary two's complement integers. (That was a bit of
a departure for IBM, as the 7090 used sign-magnitude.)
But it also had something else that Intel and AMD x86-architecture processors
only give very limited support to. Packed decimal numbers.
A packed decimal number is a way to represent numbers inside a computer as a
sequence of decimal digits, each one represented by four binary bits with the
binary-coded-decimal representation of that number.
The System/360 had pack and unpack instructions, to convert between numbers in
character string form and numbers in packed decimal form. Obviously, having both
kinds of numbers in the same order, with the first digit in the lowest address,
made those instructions easier to implement.
But the System/360 also *did arithmetic* with packed decimal quantities. And
they often used the same ALU, with a decimal adjust feature using nibble carries
turned on, to perform that arithmetic. So having the most significant part on
the same side of a number for binary numbers and packed decimal numbers made
_that_ easier.
Packed decimal numbers as an arithmetic data type, therefore, form a bridge
between numbers in character representation and numbers in binary
representation. As there are benefits from their byte ordering matching the byte
ordering of _both_ of those forms of numbers, their presence in a computer
architecture makes big-endian ordering advantageous for that architecture.
John Savard
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385732 is a reply to message #385723] |
Tue, 06 August 2019 02:44  |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 5 Aug 2019 14:35:27 -0700 (PDT)
Quadibloc <jsavard@ecn.ab.ca> wrote:
> Historically, since computers were developed in the Western world,
> storage of chracters in computer words was from "left" to "right", that
> is, from the most significant part to the least significant part,
> basically without thought - it was simply assumed to be the natural way
> to do it, as it corresponded to how numbers and words were written by us
> on paper.
However a little extra thought will reveal that we generally
manipulate numbers starting at the least significant end (except for long
division).
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385740 is a reply to message #385723] |
Tue, 06 August 2019 09:38 |
scott
Messages: 4239
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> writes:
> Generally speaking, the big-endian versus little-endian argument has been
> interminable, and has generated more heat than light.
>
> Packed decimal numbers as an arithmetic data type, therefore, form a bridge
> between numbers in character representation and numbers in binary
> representation. As there are benefits from their byte ordering matching the byte
> ordering of _both_ of those forms of numbers, their presence in a computer
> architecture makes big-endian ordering advantageous for that architecture.
Bit-endian ordering also creates some difficulties when doing arithmetic,
particularly when the architecture supports variable length "packed decimal"
operands. Consider addition, for example; normally one start with the least
significant digit and applies any carry to digits of more significance; but
that's not particularly efficient, expecially if the result would overflow.
Burroughs medium systems would do the arithmetic from the most significant
digit (logically adding leading zeros to the shorter operand). This allowed
overflow to be detected quickly.
To do this, they add corresponding digits and if they carry, overflow is signaled.
If not and the result was '9', they increment a 9's counter and add the next pair
of digits; if a subsequent pair of digits produces a carry, and the the nines counter
is nonzero, an overflow is signaled.
One can find a flow-chart of the algorithm in the B3500 RefMan on Bitsavers.
1025475_B2500_B3500_RefMan_Oct69.pdf
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385746 is a reply to message #385740] |
Tue, 06 August 2019 16:50 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Scott Lurndal <scott@slp53.sl.home> wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> Generally speaking, the big-endian versus little-endian argument has been
>> interminable, and has generated more heat than light.
>>
>
>> Packed decimal numbers as an arithmetic data type, therefore, form a bridge
>> between numbers in character representation and numbers in binary
>> representation. As there are benefits from their byte ordering matching the byte
>> ordering of _both_ of those forms of numbers, their presence in a computer
>> architecture makes big-endian ordering advantageous for that architecture.
>
> Bit-endian ordering also creates some difficulties when doing arithmetic,
> particularly when the architecture supports variable length "packed decimal"
> operands. Consider addition, for example; normally one start with the least
> significant digit and applies any carry to digits of more significance; but
> that's not particularly efficient, expecially if the result would overflow.
>
> Burroughs medium systems would do the arithmetic from the most significant
> digit (logically adding leading zeros to the shorter operand). This allowed
> overflow to be detected quickly.
>
> To do this, they add corresponding digits and if they carry, overflow is signaled.
> If not and the result was '9', they increment a 9's counter and add the next pair
> of digits; if a subsequent pair of digits produces a carry, and the the nines counter
> is nonzero, an overflow is signaled.
>
> One can find a flow-chart of the algorithm in the B3500 RefMan on Bitsavers.
> 1025475_B2500_B3500_RefMan_Oct69.pdf
>
Big-endian has always made more sense to me, but this is a discussion that
will never be resolved. We’re long past the time where hardware
considerations of either are significant.
--
Pete
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385748 is a reply to message #385746] |
Tue, 06 August 2019 16:58 |
scott
Messages: 4239
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>> Generally speaking, the big-endian versus little-endian argument has been
>>> interminable, and has generated more heat than light.
>>>
>>
>>> Packed decimal numbers as an arithmetic data type, therefore, form a bridge
>>> between numbers in character representation and numbers in binary
>>> representation. As there are benefits from their byte ordering matching the byte
>>> ordering of _both_ of those forms of numbers, their presence in a computer
>>> architecture makes big-endian ordering advantageous for that architecture.
>>
>> Bit-endian ordering also creates some difficulties when doing arithmetic,
>> particularly when the architecture supports variable length "packed decimal"
>> operands. Consider addition, for example; normally one start with the least
>> significant digit and applies any carry to digits of more significance; but
>> that's not particularly efficient, expecially if the result would overflow.
>>
>> Burroughs medium systems would do the arithmetic from the most significant
>> digit (logically adding leading zeros to the shorter operand). This allowed
>> overflow to be detected quickly.
>>
>> To do this, they add corresponding digits and if they carry, overflow is signaled.
>> If not and the result was '9', they increment a 9's counter and add the next pair
>> of digits; if a subsequent pair of digits produces a carry, and the the nines counter
>> is nonzero, an overflow is signaled.
>>
>> One can find a flow-chart of the algorithm in the B3500 RefMan on Bitsavers.
>> 1025475_B2500_B3500_RefMan_Oct69.pdf
>>
>
> Big-endian has always made more sense to me, but this is a discussion that
> will never be resolved. We’re long past the time where hardware
> considerations of either are significant.
>
That's not the case. The processor we just taped out can be configured
for big-endian or little-endian independently in all privilege levels of
the processor (ARM Aarch64). Big-endian is popular with networking appliances
(because multibyte data on IEEE 803.1 networks is interpreted as big-endian);
whereas little-endian is popular in most other contexts. Little-endian is
somewhat easier to work with once one becomes accustomed to it. In any case,
99% of all programmers don't know or care what the endianness is.
With Arm64 processors, linux looks at the codefile (ELF) header and tells the
kernel what endianness to set for the process based on header flags during
the exec(2) system call.
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385754 is a reply to message #385740] |
Tue, 06 August 2019 21:06 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> Generally speaking, the big-endian versus little-endian argument has been
>> interminable, and has generated more heat than light.
>>
>
>> Packed decimal numbers as an arithmetic data type, therefore, form a bridge
>> between numbers in character representation and numbers in binary
>> representation. As there are benefits from their byte ordering matching the byte
>> ordering of _both_ of those forms of numbers, their presence in a computer
>> architecture makes big-endian ordering advantageous for that architecture.
>
> Bit-endian ordering also creates some difficulties when doing arithmetic,
> particularly when the architecture supports variable length "packed decimal"
> operands. Consider addition, for example; normally one start with the least
> significant digit and applies any carry to digits of more significance; but
> that's not particularly efficient, expecially if the result would overflow.
On S/360 the packed decimal instructions have the address of the first
byte and a length. Using that, the hardware should know where
ALL the digits are.
Typically, the packed number is unpacked and printed with
either UNPK, ED, or EDMK. I suppose ED and EDMK could be
engineered to reverse nibble order, but we'd need a new instruction
to UNPK in reverse order.
I can't see how little endian is an optimization, how hard is it
for a machine to find all the bytes in a word, half word...just because
the instruction references the first byte, doesn't mean the machine
can't start working on the second or fourth.
--
Dan Espen
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385756 is a reply to message #385754] |
Tue, 06 August 2019 22:05 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, August 6, 2019 at 7:06:20 PM UTC-6, Dan Espen wrote:
> I can't see how little endian is an optimization, how hard is it
> for a machine to find all the bytes in a word, half word...just because
> the instruction references the first byte, doesn't mean the machine
> can't start working on the second or fourth.
Fundamentally, it isn't. But remember, this started back in the days of small-
scale integration, if not discrete transistors.
John Savard
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385760 is a reply to message #385754] |
Wed, 07 August 2019 04:24 |
Andrew Swallow
Messages: 1705
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 07/08/2019 02:06, Dan Espen wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>> Generally speaking, the big-endian versus little-endian argument has been
>>> interminable, and has generated more heat than light.
>>>
>>
>>> Packed decimal numbers as an arithmetic data type, therefore, form a bridge
>>> between numbers in character representation and numbers in binary
>>> representation. As there are benefits from their byte ordering matching the byte
>>> ordering of _both_ of those forms of numbers, their presence in a computer
>>> architecture makes big-endian ordering advantageous for that architecture.
>>
>> Bit-endian ordering also creates some difficulties when doing arithmetic,
>> particularly when the architecture supports variable length "packed decimal"
>> operands. Consider addition, for example; normally one start with the least
>> significant digit and applies any carry to digits of more significance; but
>> that's not particularly efficient, expecially if the result would overflow.
>
> On S/360 the packed decimal instructions have the address of the first
> byte and a length. Using that, the hardware should know where
> ALL the digits are.
>
> Typically, the packed number is unpacked and printed with
> either UNPK, ED, or EDMK. I suppose ED and EDMK could be
> engineered to reverse nibble order, but we'd need a new instruction
> to UNPK in reverse order.
>
> I can't see how little endian is an optimization, how hard is it
> for a machine to find all the bytes in a word, half word...just because
> the instruction references the first byte, doesn't mean the machine
> can't start working on the second or fourth.
>
It is easy if you have index registers and instructions that can extract
the digit or byte. Where you have to shift and mask to extract and
insert it gets harder.
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385765 is a reply to message #385756] |
Wed, 07 August 2019 07:55 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> writes:
> On Tuesday, August 6, 2019 at 7:06:20 PM UTC-6, Dan Espen wrote:
>
>> I can't see how little endian is an optimization, how hard is it
>> for a machine to find all the bytes in a word, half word...just because
>> the instruction references the first byte, doesn't mean the machine
>> can't start working on the second or fourth.
>
> Fundamentally, it isn't. But remember, this started back in the days of small-
> scale integration, if not discrete transistors.
Hardly an excuse. There were all kinds of machines built before then
that were big endian and worked fine, including IBM 14xx.
--
Dan Espen
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385779 is a reply to message #385746] |
Wed, 07 August 2019 12:25 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-08-06, Peter Flass <peter_flass@yahoo.com> wrote:
> Big-endian has always made more sense to me, but this is a discussion that
> will never be resolved. We’re long past the time where hardware
> considerations of either are significant.
8080 One little,
8085 Two little,
8086 Three little-endians...
8088 Four little,
80186 Five little,
80286 Six little-endians...
80386 Seven little,
80386SX Eight little,
80486 Nine little-endians...
Pentium <segment fault>
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385797 is a reply to message #385779] |
Wed, 07 August 2019 16:21 |
Gene Wirchenko
Messages: 1166
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 7 Aug 2019 16:25:51 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:
> On 2019-08-06, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Big-endian has always made more sense to me, but this is a discussion that
>> will never be resolved. Were long past the time where hardware
>> considerations of either are significant.
>
> 8080 One little,
> 8085 Two little,
No Z-80?
> 8086 Three little-endians...
> 8088 Four little,
> 80186 Five little,
> 80286 Six little-endians...
> 80386 Seven little,
> 80386SX Eight little,
> 80486 Nine little-endians...
> Pentium <segment fault>
Sincerely,
Gene Wirchenko
|
|
|
|
| Where do byte orders come from [message #385806 is a reply to message #385765] |
Wed, 07 August 2019 17:12 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <qiee6p$ev8$1@dont-email.me>,
Dan Espen <dan1espen@gmail.com> wrote:
>> Fundamentally, it isn't. But remember, this started back in the days of small-
>> scale integration, if not discrete transistors.
>
> Hardly an excuse. There were all kinds of machines built before then
> that were big endian and worked fine, including IBM 14xx.
As far as I can tell, until the DEC PDP-11 every machine that had a
byte order was big-endian. Even the -11 has some big-endianness in
some of its multi-word arithmetic hardware.
I have never been able to get a straight answer to the question of
where the PDP-11's byte order came from. The description in Computer
Engineering by Bell et al doesn't mention it. There's plenty of
speculation (please don't start) but no answer from anyone in a
position to know.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: Where do byte orders come from [message #385809 is a reply to message #385806] |
Wed, 07 August 2019 17:43 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, August 7, 2019 at 3:12:29 PM UTC-6, John Levine wrote:
> I have never been able to get a straight answer to the question of
> where the PDP-11's byte order came from. The description in Computer
> Engineering by Bell et al doesn't mention it. There's plenty of
> speculation (please don't start) but no answer from anyone in a
> position to know.
That may be, but I would have thought the answer was obvious. The PDP-11 had
general registers. It was an attempt to get fancy, like a System/360. But DEC
was the low-price leader in the minicomputer business. So they wanted to keep
things simple, and have the least significant word of a 32-bit quantity first -
it saved a few transistors. And other machines like the Honeywell 316 did it
that way, it was a common practice.
Going little-endian for byte addressing and for packing characters in a word
gave you consistency "for free". That's an obvious enough fact that I don't
think it really is speculation to assume this is the cause.
Yes, it would be nice to have a primary source, but if, for whatever reaon, the
specific engineer responsible wishes to remain anonymous, we may never know for
sure.
John Savard
|
|
|
|
|
|
| Re: Where do byte orders come from [message #385819 is a reply to message #385809] |
Wed, 07 August 2019 19:13 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <bcb6a694-3379-4157-8764-9992bef4dab8@googlegroups.com> you write:
> On Wednesday, August 7, 2019 at 3:12:29 PM UTC-6, John Levine wrote:
>
>> I have never been able to get a straight answer to the question of
>> where the PDP-11's byte order came from. ...
> That may be, but I would have thought the answer was obvious. The PDP-11 had
> general registers. It was an attempt to get fancy, like a System/360. But DEC
> was the low-price leader in the minicomputer business. So they wanted to keep
> things simple, and have the least significant word of a 32-bit quantity first -
> it saved a few transistors. And other machines like the Honeywell 316 did it
> that way, it was a common practice.
Actually, the early PDP-11's handled nothing bigger than a 16 bit
word. (I programmed a PDP-11/20 so I'm speaking from experience
here.) Any 32 bit values were done in software. As others have
noted, when they added some optional multiple precision hardware
later, they got the word order wrong leading to "middle-endian"
For character strings, byte order doesn't really matter, since you
address the bytes rather than the words they might be packed into.
The DDP 316 was word addressed. I never programmed one, but the
reference manual at bitsavers says that in double precision values,
the most significant 15 bits are in the first word and the less
significant 15 bits are in the second word. The sign is the high
bit of the first word. Floating point also put the high part first.
For that and other reasons I doubt it was an influence on DEC.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385834 is a reply to message #385797] |
Wed, 07 August 2019 23:10 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-08-07, Gene Wirchenko <gene@shaw.ca> wrote:
> On 7 Aug 2019 16:25:51 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
> wrote:
>
>> 8080 One little,
>> 8085 Two little,
>
> No Z-80?
Maybe I could replace the 80186. But I can't have too many
or the rhyme wouldn't work.
There once was a fellow named Dan,
Whose limericks wouldn't quite scan.
When told this was so,
He replied, "Yes, I know,
But I always try to get as many syllables into the last line as I possibly can."
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: Where do byte orders come from [message #385837 is a reply to message #385819] |
Thu, 08 August 2019 04:00 |
|
|
Originally posted by: Bob Eager
On Wed, 07 Aug 2019 23:13:39 +0000, John Levine wrote:
> Actually, the early PDP-11's handled nothing bigger than a 16 bit word.
> (I programmed a PDP-11/20 so I'm speaking from experience here.) Any 32
> bit values were done in software.
Me too. It was luxury when we got bigger 11s that had hardware for it!
> The DDP 316 was word addressed. I never programmed one, but the
> reference manual at bitsavers says that in double precision values,
> the most significant 15 bits are in the first word and the less
> significant 15 bits are in the second word. The sign is the high bit of
> the first word. Floating point also put the high part first.
Yes, I was programming a 516 (pretty well the same) at around the same
time. Completely different. It was more fun for me though, because I
ended up modifying the CPU to change the instruction set a bit.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385840 is a reply to message #385834] |
Thu, 08 August 2019 04:58 |
|
|
Originally posted by: Gareth's was W7 now W10 Downstairs Computer
On 08/08/2019 04:10, Charlie Gibbs wrote:
> On 2019-08-07, Gene Wirchenko <gene@shaw.ca> wrote:
>
>> On 7 Aug 2019 16:25:51 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>> wrote:
>>
>>> 8080 One little,
>>> 8085 Two little,
>>
>> No Z-80?
>
> Maybe I could replace the 80186. But I can't have too many
> or the rhyme wouldn't work.
>
> There once was a fellow named Dan,
> Whose limericks wouldn't quite scan.
> When told this was so,
> He replied, "Yes, I know,
> But I always try to get as many syllables into the last line as I possibly can."
>
There was a young fellow from Trinity,
Who, though he could trill like a linnet, he
Could never complete
Any verses with feet,
For, as he said, "Look, you fools, what I am writing here is free verse.".
|
|
|
|
| Re: An Argument for Big-Endian: Packed Decimal [message #385859 is a reply to message #385840] |
Thu, 08 August 2019 20:16 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2019-08-08, Gareth's was W7 now W10 Downstairs Computer
<headstone255@yahoo.com> wrote:
> On 08/08/2019 04:10, Charlie Gibbs wrote:
>
>> On 2019-08-07, Gene Wirchenko <gene@shaw.ca> wrote:
>>
>>> On 7 Aug 2019 16:25:51 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>>> wrote:
>>>
>>>> 8080 One little,
>>>> 8085 Two little,
>>>
>>> No Z-80?
>>
>> Maybe I could replace the 80186. But I can't have too many
>> or the rhyme wouldn't work.
>>
>> There once was a fellow named Dan,
>> Whose limericks wouldn't quite scan.
>> When told this was so,
>> He replied, "Yes, I know,
>> But I always try to get as many syllables into the last line as I possibly can."
>
> There was a young fellow from Trinity,
> Who, though he could trill like a linnet, he
> Could never complete
> Any verses with feet,
> For, as he said, "Look, you fools, what I am writing here is free verse.".
There once was a man from Purdue,
Whose limericks stopped at line two.
There once was a fellow named Dunn,
(There was something about someone named Nero,
but I can't find a reference...)
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ "Alexa, define 'bugging'."
|
|
|
|
| Re: Where do byte orders come from [message #385869 is a reply to message #385837] |
Thu, 08 August 2019 20:41 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Bob Eager <news0073@eager.cx> wrote:
> On Wed, 07 Aug 2019 23:13:39 +0000, John Levine wrote:
>
>> Actually, the early PDP-11's handled nothing bigger than a 16 bit word.
>> (I programmed a PDP-11/20 so I'm speaking from experience here.) Any 32
>> bit values were done in software.
>
> Me too. It was luxury when we got bigger 11s that had hardware for it!
Didn’t the original -11s have to have the bootstrap toggled in from the
console? I seem to recall some machine where a boot prom was an option.
--
Pete
|
|
|
|
| Re: Where do byte orders come from [message #385873 is a reply to message #385869] |
Fri, 09 August 2019 04:30 |
|
|
Originally posted by: Gareth's was W7 now W10 Downstairs Computer
On 09/08/2019 01:41, Peter Flass wrote:
> Bob Eager <news0073@eager.cx> wrote:
>> On Wed, 07 Aug 2019 23:13:39 +0000, John Levine wrote:
>>
>>> Actually, the early PDP-11's handled nothing bigger than a 16 bit word.
>>> (I programmed a PDP-11/20 so I'm speaking from experience here.) Any 32
>>> bit values were done in software.
>>
>> Me too. It was luxury when we got bigger 11s that had hardware for it!
>
> Didn’t the original -11s have to have the bootstrap toggled in from the
> console? I seem to recall some machine where a boot prom was an option.
>
Altogether now ...
16701
26
12702
352
5211
105711 ...
Can't remember much more, but it got cemented in my
mind 48 years ago :-)
|
|
|
|
| Re: Where do byte orders come from [message #385903 is a reply to message #385806] |
Sat, 10 August 2019 15:04 |
|
|
Originally posted by: googlegroups jmfbahciv
On Wednesday, August 7, 2019 at 5:12:29 PM UTC-4, John Levine wrote:
> In article <qiee6p$ev8$1@dont-email.me>,
> Dan Espen <dan1espen@gmail.com> wrote:
>>> Fundamentally, it isn't. But remember, this started back in the days of small-
>>> scale integration, if not discrete transistors.
>>
>> Hardly an excuse. There were all kinds of machines built before then
>> that were big endian and worked fine, including IBM 14xx.
>
> As far as I can tell, until the DEC PDP-11 every machine that had a
> byte order was big-endian. Even the -11 has some big-endianness in
> some of its multi-word arithmetic hardware.
>
> I have never been able to get a straight answer to the question of
> where the PDP-11's byte order came from. The description in Computer
> Engineering by Bell et al doesn't mention it. There's plenty of
> speculation (please don't start) but no answer from anyone in a
> position to know.
>
>
>
> --
> Regards,
> John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
Who did the design? If it was someone who left to start up Data General,
perhaps reading _The Soul of a Machine_ might give hints.
/BAH
|
|
|
|
| Re: Where do byte orders come from [message #385904 is a reply to message #385869] |
Sat, 10 August 2019 15:08 |
|
|
Originally posted by: googlegroups jmfbahciv
On Thursday, August 8, 2019 at 8:41:27 PM UTC-4, Peter Flass wrote:
> Bob Eager <news0073@eager.cx> wrote:
>> On Wed, 07 Aug 2019 23:13:39 +0000, John Levine wrote:
>>
>>> Actually, the early PDP-11's handled nothing bigger than a 16 bit word..
>>> (I programmed a PDP-11/20 so I'm speaking from experience here.) Any 32
>>> bit values were done in software.
>>
>> Me too. It was luxury when we got bigger 11s that had hardware for it!
>
> Didn’t the original -11s have to have the bootstrap toggled in from the
> console? I seem to recall some machine where a boot prom was an option.
>
> --
> Pete
Toggling to read in a papertape was the de rigor in 1971.
/BAH
|
|
|
|
| Re: Where do byte orders come from [message #385908 is a reply to message #385903] |
Sat, 10 August 2019 16:33 |
|
|
Originally posted by: Bob Eager
On Sat, 10 Aug 2019 12:04:56 -0700, googlegroups jmfbahciv wrote:
> Who did the design? If it was someone who left to start up Data
> General,
> perhaps reading _The Soul of a Machine_ might give hints.
For the sake of those Googling:
"The Soul of a New Machine", by Tracy Kidder
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
|
|
| Re: Where do byte orders come from [message #385913 is a reply to message #385910] |
Sat, 10 August 2019 16:56 |
|
|
Originally posted by: Bob Eager
On Sat, 10 Aug 2019 20:46:38 +0000, John Levine wrote:
> In article <7e3c27ab-a45f-4e9a-9ecf-c85b868e4b0d@googlegroups.com>,
> googlegroups jmfbahciv <jmfbah102162@gmail.com> wrote:
>>> I have never been able to get a straight answer to the question of
>>> where the PDP-11's byte order came from.
>
>> Who did the design? If it was someone who left to start up Data
>> General,
>> perhaps reading _The Soul of a Machine_ might give hints.
>
> No, Ed de Castro's 16-bit machine was apparently more like what ended up
> as the Nova, which was word addressed. The PDP-11 was Gordon Bell's
> project.
The only DEC machine that de Castro was really involved in was the word
addressed PDP-8 (he was project manager).
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Where do byte orders come from [message #385914 is a reply to message #385806] |
Sat, 10 August 2019 17:08 |
cb
Messages: 300
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
In article <qiferr$1inr$1@gal.iecc.com>, John Levine <johnl@taugh.com> wrote:
> In article <qiee6p$ev8$1@dont-email.me>,
> Dan Espen <dan1espen@gmail.com> wrote:
>>> Fundamentally, it isn't. But remember, this started back in the days
> of small-
>>> scale integration, if not discrete transistors.
>>
>> Hardly an excuse. There were all kinds of machines built before then
>> that were big endian and worked fine, including IBM 14xx.
>
> As far as I can tell, until the DEC PDP-11 every machine that had a
> byte order was big-endian. Even the -11 has some big-endianness in
> some of its multi-word arithmetic hardware.
>
> I have never been able to get a straight answer to the question of
> where the PDP-11's byte order came from. The description in Computer
> Engineering by Bell et al doesn't mention it. There's plenty of
> speculation (please don't start) but no answer from anyone in a
> position to know.
An excellent discussion of endianness - both regarding bytes and bits -
is IEN137, https://www.ietf.org/rfc/ien/ien137.txt, published on 1st
April 1980, and this actually uses the PDP11 as one of the examples
(though no, it does not claim to describe its origin either).
// Christian
|
|
|
|
| Re: Where do byte orders come from [message #385916 is a reply to message #385903] |
Sat, 10 August 2019 18:08 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, August 10, 2019 at 1:04:57 PM UTC-6, googlegroups jmfbahciv wrote:
> On Wednesday, August 7, 2019 at 5:12:29 PM UTC-4, John Levine wrote:
>> I have never been able to get a straight answer to the question of
>> where the PDP-11's byte order came from. The description in Computer
>> Engineering by Bell et al doesn't mention it. There's plenty of
>> speculation (please don't start) but no answer from anyone in a
>> position to know.
> Who did the design? If it was someone who left to start up Data General,
> perhaps reading _The Soul of a Machine_ might give hints.
The Soul of a New Machine, by Tracy Kidder, was about a group of young designers
hired by Data General to design their 32-bit version of the Eclipse.
Edson de Castro, who designed the original Nova, and used to work at DEC... left
because DEC went with the PDP-11 instead of his design. So he wasn't working on
the PDP-11.
So I doubt it would have any information of use.
John Savard
|
|
|
|
| Re: Where do byte orders come from [message #385918 is a reply to message #385916] |
Sat, 10 August 2019 19:16 |
|
|
Originally posted by: Bob Eager
On Sat, 10 Aug 2019 15:08:47 -0700, Quadibloc wrote:
> On Saturday, August 10, 2019 at 1:04:57 PM UTC-6, googlegroups jmfbahciv
> wrote:
>> On Wednesday, August 7, 2019 at 5:12:29 PM UTC-4, John Levine wrote:
>
>>> I have never been able to get a straight answer to the question of
>>> where the PDP-11's byte order came from. The description in Computer
>>> Engineering by Bell et al doesn't mention it. There's plenty of
>>> speculation (please don't start) but no answer from anyone in a
>>> position to know.
>
>> Who did the design? If it was someone who left to start up Data
>> General,
>> perhaps reading _The Soul of a Machine_ might give hints.
>
> The Soul of a New Machine, by Tracy Kidder, was about a group of young
> designers hired by Data General to design their 32-bit version of the
> Eclipse.
>
> Edson de Castro, who designed the original Nova, and used to work at
> DEC... left because DEC went with the PDP-11 instead of his design. So
> he wasn't working on the PDP-11.
>
> So I doubt it would have any information of use.
It doesn't. I re-read it recently.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Where do byte orders come from [message #386002 is a reply to message #385916] |
Tue, 13 August 2019 17:47 |
Rich Alderson
Messages: 489
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> writes:
> Edson de Castro, who designed the original Nova, and used to work at
> DEC... left because DEC went with the PDP-11 instead of his design. So he
> wasn't working on the PDP-11.
This is the mythology. The real story is a little more complicated, as I
learned last October at the Nova@50 celebration hosted by Bruce Ray of Wild
Hare. I met a number of original DG folks.
I've seen the 16-bit design which EdC pitched to DEC management. It looks like
a 16-bit extended PDP-8, rather than either a Nova or a PDP-11.
The Nova came out and was in production for a full year before DEC started on
the PDP-11. It was beating out the PDP-8/i (then the latest model) for sales,
which is why DEC went with a 16-bit system.
So no, DEC didn't go with EdC's 16-bit design--but neither did Data General.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
|
|
|
|
| Re: Where do byte orders come from, Nova vs PDP-11 [message #386003 is a reply to message #386002] |
Tue, 13 August 2019 18:13 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <mdd1rxod9fy.fsf@panix5.panix.com>,
Rich Alderson <news@alderson.users.panix.com> wrote:
> I've seen the 16-bit design which EdC pitched to DEC management. It looks like
> a 16-bit extended PDP-8, rather than either a Nova or a PDP-11.
Was it more like a stretched -8 or a squashed -9?
> The Nova came out and was in production for a full year before DEC started on
> the PDP-11. It was beating out the PDP-8/i (then the latest model) for sales,
> which is why DEC went with a 16-bit system.
The Nova was a good computer, a lot of performance from a low cost
design. It eventually had the same problem DEC did, nobody wanted
a mini any more when they could get commodity micros.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: Where do byte orders come from, Nova vs PDP-11 [message #386005 is a reply to message #386003] |
Tue, 13 August 2019 19:19 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> The Nova was a good computer, a lot of performance from a low cost
> design. It eventually had the same problem DEC did, nobody wanted
> a mini any more when they could get commodity micros.
Old post, I've periodically reference, decade of DEC VAX sales, sliced
and diced by year, model, US/non-US ... around mid-80s drop in sales,
effectively shows mid-range market moving to large PCs and workstations
http://www.garlic.com/~lynn/2002f.html#0
IBM 4300s sold in the same mid-range market with similar numbers (modulo
large corporate orders of 100+ for distributed computing placing out
in departmental areas) ... and experienced similar decline.
I had a project that I was told neeeded some IBM content so went to order
some Series/1 ... but this was just after IBM had bought ROLM ... ROLM
was DG machines and years output of Series/1 were ordered to replace
DG. The person running ROLM datacenter (even before IBM bought them), I
had known several years earlier at IBM ... and horse traded some of help
with their build&test for some series/1.
later in SCI meetings
https://en.wikipedia.org/wiki/Scalable_Coherent_Interface
both sequent and data general went with four i486 proceessor (shared
cache) boards ... with SCI memory interface (allowing up to 64 boards,
256 processors). Never did see any of the data general machines
https://en.wikipedia.org/wiki/Sequent_Computer_Systems
.... but did see some number of the sequent
https://en.wikipedia.org/wiki/Sequent_Computer_Systems#NUMA
this was before IBM bought them and shut them down. I had left in the
early 90s ... but did some consulting for Steve Chen ... who
was CTO of Sequent at the time
https://en.wikipedia.org/wiki/Steve_Chen_(computer_engineer)
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: Where do byte orders come from [message #386008 is a reply to message #386002] |
Tue, 13 August 2019 19:58 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, August 13, 2019 at 3:47:31 PM UTC-6, Rich Alderson wrote:
> So no, DEC didn't go with EdC's 16-bit design--but neither did Data General.
Well, of course he had to change it, at least a little! He couldn't use something
he designed while an employee of DEC, it would still have belonged to them. Plus,
since he had the PDP-11 to compete with, designing something that looked like the
HP 211x or the Honeywell x16 would not have been successful.
John Savard
|
|
|
|
| Re: Where do byte orders come from [message #386009 is a reply to message #386002] |
Tue, 13 August 2019 20:00 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, August 13, 2019 at 3:47:31 PM UTC-6, Rich Alderson wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> Edson de Castro, who designed the original Nova, and used to work at
>> DEC... left because DEC went with the PDP-11 instead of his design. So he
>> wasn't working on the PDP-11.
> This is the mythology.
Where did I say that the design of Edson de Castro that DEC didn't go with - was
the same design as he used later for the Nova?
John Savard
|
|
|
|
| DG Nova. was: Where do byte orders come from [message #386045 is a reply to message #386002] |
Wed, 14 August 2019 15:34 |
Alfred Falk
Messages: 195
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
Rich Alderson <news@alderson.users.panix.com> wrote in
news:mdd1rxod9fy.fsf@panix5.panix.com:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>
>> Edson de Castro, who designed the original Nova, and used to work at
>> DEC... left because DEC went with the PDP-11 instead of his design. So
>> he wasn't working on the PDP-11.
>
> This is the mythology. The real story is a little more complicated, as
> I learned last October at the Nova@50 celebration hosted by Bruce Ray
> of Wild Hare. I met a number of original DG folks.
Wild Hare? They still exist?! Wow!
> I've seen the 16-bit design which EdC pitched to DEC management. It
> looks like a 16-bit extended PDP-8, rather than either a Nova or a
> PDP-11.
I have heard that a factor in DEC's rejection of DeCastro's design was the
15" boards with 200+ contacts, which was deemed impractical to test and
manufacture reliably.
> The Nova came out and was in production for a full year before DEC
> started on the PDP-11. It was beating out the PDP-8/i (then the latest
> model) for sales, which is why DEC went with a 16-bit system.
>
> So no, DEC didn't go with EdC's 16-bit design--but neither did Data
> General.
>
|
|
|
|
| Re: DG Nova. was: Where do byte orders come from [message #386047 is a reply to message #386045] |
Wed, 14 August 2019 18:29 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <qj1no3$jj4$1@dont-email.me>, Alfred Falk <aefalk@telus.net> wrote:
> I have heard that a factor in DEC's rejection of DeCastro's design was the
> 15" boards with 200+ contacts, which was deemed impractical to test and
> manufacture reliably.
I can believe it. The PDP-6 had large boards which had reliability problems. I gather
a standard piece of the kit was a rubber mallet to tap all the boards and reseat the
connectors.
The PDP-7 through PDP-10 and early PDP-11s used small Flip Chip cards and wire wrapped
backplanes which worked well.
--
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
|
|
|
|
| Re: Where do byte orders come from [message #396899 is a reply to message #396889] |
Wed, 22 July 2020 06:05 |
|
|
Originally posted by: Gareth Evans
On 22/07/2020 01:51, Alan Bowler wrote:
> On 2019-08-08 8:41 p.m., Peter Flass wrote:
>
>> Didn’t the original -11s have to have the bootstrap toggled in from the
>> console?
>
> Yes. Did that a few times.
>
Altogther now, off the top of my head, from 46 years ago ...
16701
26
12702
352
.... but I forget the rest!
|
|
|
|
| Re: Where do byte orders come from [message #396907 is a reply to message #396899] |
Wed, 22 July 2020 12:45 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, July 22, 2020 at 4:05:25 AM UTC-6, Gareth Evans wrote:
> On 22/07/2020 01:51, Alan Bowler wrote:
>> On 2019-08-08 8:41 p.m., Peter Flass wrote:
>>
>>> Didn’t the original -11s have to have the bootstrap toggled in from the
>>> console?
>>
>> Yes. Did that a few times.
>>
>
> Altogther now, off the top of my head, from 46 years ago ...
>
> 16701
> 26
> 12702
> 352
>
> ... but I forget the rest!
I was able to Google a page which preserves it:
http://gunkies.org/wiki/PDP-11_Bootstrap_Loader
Set the address to 7744.
Then put the loader in:
7744 016701
7746 000026
7750 012702
7752 000352
7754 005211
7756 105711
7760 100376
7762 116162
7764 000002
7766 007400
7770 005267
7772 177756
7774 000765
and then the next word needs to contain the address of the boot device, which
may vary between systems.
John Savard
|
|
|
|
Members
Search
Help
Register
Login
Home
