Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #3324 > unrolled thread

Re: Solving the Floating-Point Goldilocks Problem!

Back to article view | Back to comp.arch

Contents

  Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-01 13:39 +0000
    Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-01 08:18 -0700
      Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-02 13:44 +0000
        Re: Solving the Floating-Point Goldilocks Problem! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-02 09:37 -0700
          Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-02 10:21 -0700
            Re: Solving the Floating-Point Goldilocks Problem! rpw3@rpw3.org (Rob Warnock) - 2011-09-05 06:11 -0500
          Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-03 14:57 +0000
            Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-03 13:13 -0400
              Re: Solving the Floating-Point Goldilocks Problem! rpw3@rpw3.org (Rob Warnock) - 2011-09-05 06:41 -0500
                Re: Solving the Floating-Point Goldilocks Problem! Peter Flass <Peter_Flass@Yahoo.com> - 2011-09-05 08:21 -0400
                Re: Solving the Floating-Point Goldilocks Problem! jmfbahciv <See.above@aol.com> - 2011-09-05 13:26 +0000
              Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-05 22:48 -0700
                Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-06 16:51 -0700
                  Re: Solving the Floating-Point Goldilocks Problem! Morten Reistad <first@last.name> - 2011-09-07 14:14 +0200
                    Re: Solving the Floating-Point Goldilocks Problem! Patrick Scheible <kkt@zipcon.net> - 2011-09-07 09:45 -0700
                  Re: Solving the Floating-Point Goldilocks Problem! Rob Doyle <radioengr@gmail.com> - 2011-09-07 18:54 -0700
                    Re: Solving the Floating-Point Goldilocks Problem! Quadibloc <jsavard@ecn.ab.ca> - 2011-09-08 00:53 -0700
                    Re: Solving the Floating-Point Goldilocks Problem! MitchAlsup <MitchAlsup@aol.com> - 2011-09-08 08:00 -0700

#3324 — Re: Solving the Floating-Point Goldilocks Problem!

Peter Flass wrote:
> On 8/31/2011 12:38 PM, Terje Mathisen wrote:
>> Andy "Krazy" Glew wrote:
>>> On 8/31/2011 1:39 AM, Terje Mathisen wrote:
>>>> As you know LRB have two opcodes for this, to do 1:1:1:1:1 and
>>>> 2:1:2:1:2:1 interleaving.
>>>>
>>>> With this much hw support it becomes most practical to keep the (x,y,z)
>>>> indices separate and merge them before use.
>>>
>>> You are missing one of the other uses of bit-interleaved formats:
>>> They provide scalability.
>>>
>>> Both in online (serial) arithmetic, and in network distribution.
>>>
>>> E.g. you may want to send bit interleaved data with N bits per component
>>> around the network. At the points where you realize that this data is
>>> only ever going to be displayed on a small screen whose viewport you
>>> already know, you start truncating the bitstream.
>>
>> OK, that only works if your world coordinates are big endian, in
>> something like a 0.0 to 1.0 range: In that case you can stop the
>> transmission as soon as you have sent enough bits for the local
>> resolution, i.e. a 640x480 screen would need the top 19 bits or so (you
>> probably need some wiggle room for fractional pixel coords).
>>>
>>> People used to build graphics devices that sent data around like this,
>>> bit serially.
>>
>> With unknown (to the sender) local resolution?
>>>
>>> We may do so again.
>>>
>>> (One of my pet peeves is people assuming, for a non-lossy
>>> transformation, that A->B is necessary, but B->A is not necessary. There
>>> may not be a business case for making the reverse transformation fast.
>>> But nearly always this is a short sighted optimization.)
>>
>> So you desire unpack opcodes as well, something that can quickly extract
>> every second or every third bit?
>>
>
> This is something that would be useful for a lot of things, but should
> be general-purpose.  (thanks to DEC for PDP-10) have source and
> destination pointers in registers, with byte address, bit index and
> number of bits to extract, and increment in bits.  Extract, e.g. an
> arbitrary bit field from the source and store it at an arbitrary bit
> position in the destination.  Then update the pointers, so you could REP
> it, or have a repeat counter.  If I had a nickle for every time I've
> wanted such an instruction...
>
Don't forget the indirect addressing (not to be confused with indexing).

/BAH

[toc] | [next] | [standalone]

#3326

On 9/1/2011 6:39 AM, jmfbahciv wrote:
> Peter Flass wrote:
>> On 8/31/2011 12:38 PM, Terje Mathisen wrote:
>>> Andy "Krazy" Glew wrote:
>>>> On 8/31/2011 1:39 AM, Terje Mathisen wrote:
>>>>> As you know LRB have two opcodes for this, to do 1:1:1:1:1 and
>>>>> 2:1:2:1:2:1 interleaving.
>>>>>
>>>>> With this much hw support it becomes most practical to keep the (x,y,z)
>>>>> indices separate and merge them before use.
>>>>
>>>> You are missing one of the other uses of bit-interleaved formats:
>>>> They provide scalability.
>>>>
>>>> Both in online (serial) arithmetic, and in network distribution.
>>>>
>>>> E.g. you may want to send bit interleaved data with N bits per component
>>>> around the network. At the points where you realize that this data is
>>>> only ever going to be displayed on a small screen whose viewport you
>>>> already know, you start truncating the bitstream.
>>>
>>> OK, that only works if your world coordinates are big endian, in
>>> something like a 0.0 to 1.0 range: In that case you can stop the
>>> transmission as soon as you have sent enough bits for the local
>>> resolution, i.e. a 640x480 screen would need the top 19 bits or so (you
>>> probably need some wiggle room for fractional pixel coords).
>>>>
>>>> People used to build graphics devices that sent data around like this,
>>>> bit serially.
>>>
>>> With unknown (to the sender) local resolution?
>>>>
>>>> We may do so again.
>>>>
>>>> (One of my pet peeves is people assuming, for a non-lossy
>>>> transformation, that A->B is necessary, but B->A is not necessary. There
>>>> may not be a business case for making the reverse transformation fast.
>>>> But nearly always this is a short sighted optimization.)
>>>
>>> So you desire unpack opcodes as well, something that can quickly extract
>>> every second or every third bit?
>>>
>>
>> This is something that would be useful for a lot of things, but should
>> be general-purpose.  (thanks to DEC for PDP-10) have source and
>> destination pointers in registers, with byte address, bit index and
>> number of bits to extract, and increment in bits.  Extract, e.g. an
>> arbitrary bit field from the source and store it at an arbitrary bit
>> position in the destination.  Then update the pointers, so you could REP
>> it, or have a repeat counter.  If I had a nickle for every time I've
>> wanted such an instruction...
>>
> Don't forget the indirect addressing (not to be confused with indexing).

Seems that you guys may be pulling my leg.

[toc] | [prev] | [next] | [standalone]

#3373

Andy "Krazy" Glew wrote:
> On 9/1/2011 6:39 AM, jmfbahciv wrote:
>> Peter Flass wrote:
>>> On 8/31/2011 12:38 PM, Terje Mathisen wrote:
>>>> Andy "Krazy" Glew wrote:
>>>>> On 8/31/2011 1:39 AM, Terje Mathisen wrote:
>>>>>> As you know LRB have two opcodes for this, to do 1:1:1:1:1 and
>>>>>> 2:1:2:1:2:1 interleaving.
>>>>>>
>>>>>> With this much hw support it becomes most practical to keep the (x,y,z)
>>>>>> indices separate and merge them before use.
>>>>>
>>>>> You are missing one of the other uses of bit-interleaved formats:
>>>>> They provide scalability.
>>>>>
>>>>> Both in online (serial) arithmetic, and in network distribution.
>>>>>
>>>>> E.g. you may want to send bit interleaved data with N bits per component
>>>>> around the network. At the points where you realize that this data is
>>>>> only ever going to be displayed on a small screen whose viewport you
>>>>> already know, you start truncating the bitstream.
>>>>
>>>> OK, that only works if your world coordinates are big endian, in
>>>> something like a 0.0 to 1.0 range: In that case you can stop the
>>>> transmission as soon as you have sent enough bits for the local
>>>> resolution, i.e. a 640x480 screen would need the top 19 bits or so (you
>>>> probably need some wiggle room for fractional pixel coords).
>>>>>
>>>>> People used to build graphics devices that sent data around like this,
>>>>> bit serially.
>>>>
>>>> With unknown (to the sender) local resolution?
>>>>>
>>>>> We may do so again.
>>>>>
>>>>> (One of my pet peeves is people assuming, for a non-lossy
>>>>> transformation, that A->B is necessary, but B->A is not necessary. There
>>>>> may not be a business case for making the reverse transformation fast.
>>>>> But nearly always this is a short sighted optimization.)
>>>>
>>>> So you desire unpack opcodes as well, something that can quickly extract
>>>> every second or every third bit?
>>>>
>>>
>>> This is something that would be useful for a lot of things, but should
>>> be general-purpose.  (thanks to DEC for PDP-10) have source and
>>> destination pointers in registers, with byte address, bit index and
>>> number of bits to extract, and increment in bits.  Extract, e.g. an
>>> arbitrary bit field from the source and store it at an arbitrary bit
>>> position in the destination.  Then update the pointers, so you could REP
>>> it, or have a repeat counter.  If I had a nickle for every time I've
>>> wanted such an instruction...
>>>
>> Don't forget the indirect addressing (not to be confused with indexing).
>
> Seems that you guys may be pulling my leg.

[puzzled emoticon here]  No.  The PDP-10 had LDB, DPB, ILDB, IDPB.
I could specify the size of the byte, use the all the hardware
addressing calculation, which included indexing, indirection.
The limitation was that a byte had a maximum of 36 bits which
was the width of a word.  How young are you?  I ask because you
may not know defintions of word and other terms.

Oh, shit.  I've noticed these posts have been going to comp.arch.
My apologies.  I'll stop after this one.

/BAH

[toc] | [prev] | [next] | [standalone]

#3386

On 9/2/2011 6:44 AM, jmfbahciv wrote:
> Andy "Krazy" Glew wrote:
>> On 9/1/2011 6:39 AM, jmfbahciv wrote:
>>> Peter Flass wrote:
>>>> On 8/31/2011 12:38 PM, Terje Mathisen wrote:
>>>>> Andy "Krazy" Glew wrote:
>>>>>> On 8/31/2011 1:39 AM, Terje Mathisen wrote:
>>>>>>> As you know LRB have two opcodes for this, to do 1:1:1:1:1 and
>>>>>>> 2:1:2:1:2:1 interleaving.
>>>>>>>
>>>>>>> With this much hw support it becomes most practical to keep the (x,y,z)
>>>>>>> indices separate and merge them before use.
>>>>>>
>>>>>> You are missing one of the other uses of bit-interleaved formats:
>>>>>> They provide scalability.
>>>>>>
>>>>>> Both in online (serial) arithmetic, and in network distribution.
>>>>>>
>>>>>> E.g. you may want to send bit interleaved data with N bits per component
>>>>>> around the network. At the points where you realize that this data is
>>>>>> only ever going to be displayed on a small screen whose viewport you
>>>>>> already know, you start truncating the bitstream.
>>>>>
>>>>> OK, that only works if your world coordinates are big endian, in
>>>>> something like a 0.0 to 1.0 range: In that case you can stop the
>>>>> transmission as soon as you have sent enough bits for the local
>>>>> resolution, i.e. a 640x480 screen would need the top 19 bits or so (you
>>>>> probably need some wiggle room for fractional pixel coords).
>>>>>>
>>>>>> People used to build graphics devices that sent data around like this,
>>>>>> bit serially.
>>>>>
>>>>> With unknown (to the sender) local resolution?
>>>>>>
>>>>>> We may do so again.
>>>>>>
>>>>>> (One of my pet peeves is people assuming, for a non-lossy
>>>>>> transformation, that A->B is necessary, but B->A is not necessary. There
>>>>>> may not be a business case for making the reverse transformation fast.
>>>>>> But nearly always this is a short sighted optimization.)
>>>>>
>>>>> So you desire unpack opcodes as well, something that can quickly extract
>>>>> every second or every third bit?
>>>>>
>>>>
>>>> This is something that would be useful for a lot of things, but should
>>>> be general-purpose.  (thanks to DEC for PDP-10) have source and
>>>> destination pointers in registers, with byte address, bit index and
>>>> number of bits to extract, and increment in bits.  Extract, e.g. an
>>>> arbitrary bit field from the source and store it at an arbitrary bit
>>>> position in the destination.  Then update the pointers, so you could REP
>>>> it, or have a repeat counter.  If I had a nickle for every time I've
>>>> wanted such an instruction...
>>>>
>>> Don't forget the indirect addressing (not to be confused with indexing).
>>
>> Seems that you guys may be pulling my leg.
>
> [puzzled emoticon here]  No.  The PDP-10 had LDB, DPB, ILDB, IDPB.
> I could specify the size of the byte, use the all the hardware
> addressing calculation, which included indexing, indirection.
> The limitation was that a byte had a maximum of 36 bits which
> was the width of a word.  How young are you?  I ask because you
> may not know defintions of word and other terms.
>
> Oh, shit.  I've noticed these posts have been going to comp.arch.
> My apologies.  I'll stop after this one.
>
> /BAH

No, please, I have been enjoying it.

comp.arch is about generic "is this a good idea".

alt.folklore.computers is about "what was done on such and such a machine".

There is a lot of overlap.

comp.arcj is not really interested in the grotty details of which 
version of MVS had which feature.  But is interested in the features.




I thought that you might be pulling my leg because I am often accused of 
pushing for CISCy instructions - and you were pushing my comfort zone.




If you were serious:


What applications made you want these features?

[toc] | [prev] | [next] | [standalone]

#3388

"Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> writes:

> On 9/2/2011 6:44 AM, jmfbahciv wrote:
>> Andy "Krazy" Glew wrote:
>>> On 9/1/2011 6:39 AM, jmfbahciv wrote:
>>>> Peter Flass wrote:
>>>>> On 8/31/2011 12:38 PM, Terje Mathisen wrote:
>>>>>> Andy "Krazy" Glew wrote:
>>>>>>> On 8/31/2011 1:39 AM, Terje Mathisen wrote:
>>>>>>>> As you know LRB have two opcodes for this, to do 1:1:1:1:1 and
>>>>>>>> 2:1:2:1:2:1 interleaving.
>>>>>>>>
>>>>>>>> With this much hw support it becomes most practical to keep the (x,y,z)
>>>>>>>> indices separate and merge them before use.
>>>>>>>
>>>>>>> You are missing one of the other uses of bit-interleaved formats:
>>>>>>> They provide scalability.
>>>>>>>
>>>>>>> Both in online (serial) arithmetic, and in network distribution.
>>>>>>>
>>>>>>> E.g. you may want to send bit interleaved data with N bits per component
>>>>>>> around the network. At the points where you realize that this data is
>>>>>>> only ever going to be displayed on a small screen whose viewport you
>>>>>>> already know, you start truncating the bitstream.
>>>>>>
>>>>>> OK, that only works if your world coordinates are big endian, in
>>>>>> something like a 0.0 to 1.0 range: In that case you can stop the
>>>>>> transmission as soon as you have sent enough bits for the local
>>>>>> resolution, i.e. a 640x480 screen would need the top 19 bits or so (you
>>>>>> probably need some wiggle room for fractional pixel coords).
>>>>>>>
>>>>>>> People used to build graphics devices that sent data around like this,
>>>>>>> bit serially.
>>>>>>
>>>>>> With unknown (to the sender) local resolution?
>>>>>>>
>>>>>>> We may do so again.
>>>>>>>
>>>>>>> (One of my pet peeves is people assuming, for a non-lossy
>>>>>>> transformation, that A->B is necessary, but B->A is not necessary. There
>>>>>>> may not be a business case for making the reverse transformation fast.
>>>>>>> But nearly always this is a short sighted optimization.)
>>>>>>
>>>>>> So you desire unpack opcodes as well, something that can quickly extract
>>>>>> every second or every third bit?
>>>>>>
>>>>>
>>>>> This is something that would be useful for a lot of things, but should
>>>>> be general-purpose.  (thanks to DEC for PDP-10) have source and
>>>>> destination pointers in registers, with byte address, bit index and
>>>>> number of bits to extract, and increment in bits.  Extract, e.g. an
>>>>> arbitrary bit field from the source and store it at an arbitrary bit
>>>>> position in the destination.  Then update the pointers, so you could REP
>>>>> it, or have a repeat counter.  If I had a nickle for every time I've
>>>>> wanted such an instruction...
>>>>>
>>>> Don't forget the indirect addressing (not to be confused with indexing).
>>>
>>> Seems that you guys may be pulling my leg.
>>
>> [puzzled emoticon here]  No.  The PDP-10 had LDB, DPB, ILDB, IDPB.
>> I could specify the size of the byte, use the all the hardware
>> addressing calculation, which included indexing, indirection.
>> The limitation was that a byte had a maximum of 36 bits which
>> was the width of a word.  How young are you?  I ask because you
>> may not know defintions of word and other terms.
>>
>> Oh, shit.  I've noticed these posts have been going to comp.arch.
>> My apologies.  I'll stop after this one.
>>
>> /BAH
>
> No, please, I have been enjoying it.
>
> comp.arch is about generic "is this a good idea".
>
> alt.folklore.computers is about "what was done on such and such a machine".
>
> There is a lot of overlap.
>
> comp.arcj is not really interested in the grotty details of which
> version of MVS had which feature.  But is interested in the features.
>
>
>
>
> I thought that you might be pulling my leg because I am often accused
> of pushing for CISCy instructions - and you were pushing my comfort
> zone.
>
>
>
>
> If you were serious:
>
>
> What applications made you want these features?

The PDP-10 is a word-oriented 36-bit machine, in which bytesize is
chosen most appropriately for each application.  The load byte and
deposit byte instruction are the canonical ways to get one character out
of a string into a register by itself so you can compare it, change it,
etc., and then pack it into a string again.

The PDP-10 is agnostic about byte size, and different applications use
different character sizes according to need.  7-bit ascii is the most
common for text files, sixbit is common for symbols in shared libraries,
8-bit ascii is commonly used for imported extended ascii text files,
etc.  Other data in small chunks is easy to load and store with the byte
instructions too, they'll load and store any size byte from 1 to 36.

Partly it's that memory was so precious that you wouldn't want to waste
1 or 2 bits per byte the way putting 7-bit ascii into 8-bit bytes does.

-- Patrick

[toc] | [prev] | [next] | [standalone]

#3465

Patrick Scheible  <kkt@zipcon.net> wrote:
+---------------
| "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> writes:
| > What applications made you want these features?
| 
| The PDP-10 is a word-oriented 36-bit machine, in which
| bytesize is chosen most appropriately for each application.
+---------------

Not chosen just once per application, PDP-10 but the byte size
could be chosen differently for *each* LDB/DPB instruction executed!
Also, byte pointers could be indexed (and indirected), and thus
were useful for packing *multiple* "byte" sizes -- or perhaps
"bitfields" would be a better term -- into word-sized pieces
of memory -- or to think about it another way, "bit strips" in
arrays of words.

+---------------
| The PDP-10 is agnostic about byte size, and different applications use
| different character sizes according to need.  7-bit ascii is the most
| common for text files, sixbit is common for symbols in shared libraries,
| 8-bit ascii is commonly used for imported extended ascii text files,
| etc.  Other data in small chunks is easy to load and store with the byte
| instructions too, they'll load and store any size byte from 1 to 36.
+---------------

Indeed. As I have describe elsewhere[1], LDB/DPB were useful for
ordered character "equivalence classes", which could be used for
fast lexical dispatching via indirect jumps. The equivalence classes
could be stored *vary* compactly as the above-mentioned "bit strips",
with a given class taking only log2(#class_elements - 1)*#characters
*bits* from the word array. One could map a character to a character
class and then jump to the handler for that class in only *two*
instructions. For the PDP-10 folk, the two instructions were:

    ; Come here with the character in register C.
    ldb    t0, lex_class_foo	; A byte pointer indexed by register C.
    sojge  t0, @class_foo_jumps(t0)
    ; Fall through to here if C was not in lexical class "foo".

The refs[1] contain much more of the low-level details.


-Rob

[1] Multiple places/times, actually:  ;-}

      Message-ID: <90vps3$93uon$1@fido.engr.sgi.com>
      Message-ID: <938v11$m89cq$1@fido.engr.sgi.com>

    Hmmm... Google Groups "Advanced Search" seems more broken
    than usual today. Try this URL instead, and search in-page
    for my name:

      http://www.inwap.com/pdp10/usenet/focal

-----
Rob Warnock		<rpw3@rpw3.org>
627 26th Avenue		<http://rpw3.org/>
San Mateo, CA 94403

[toc] | [prev] | [next] | [standalone]

#3407

Andy "Krazy" Glew wrote:
> On 9/2/2011 6:44 AM, jmfbahciv wrote:

<snip>

>> Oh, shit.  I've noticed these posts have been going to comp.arch.
>> My apologies.  I'll stop after this one.
>>
>> /BAH
>
> No, please, I have been enjoying it.


As have I.

>
> comp.arch is about generic "is this a good idea".


There are a couple of people in c.a who do not like my posts.  Since
they do useful work, I try not to irritate them and don't post to c.a.

>
> alt.folklore.computers is about "what was done on such and such a machine".


Not really.  Most of us are used to taking what exists, or existed,
and creating new things.  a.f.c.'s discussions range from food to
politics to religions to blacksmithing and we usually manage to
tie the topic back to the computing biz.  Even when the conversation
strays far off-topic, it sounds like I'm attending the bullshit and
design sessions we used to have when creating the "new" stuff.

>
> There is a lot of overlap.
>
> comp.arcj is not really interested in the grotty details of which
> version of MVS had which feature.  But is interested in the features.

I understand that.  I figured that, if anyone was interested in what
I talkked about, they would buzz over to a.f.c or the PDP-10 newsgroup.

> I thought that you might be pulling my leg because I am often accused of
> pushing for CISCy instructions - and you were pushing my comfort zone.


<snort>  I don't consider our byte instructions CISCy.  My opinion,
which has to be taken as an uneducated opinion in c.a, is that
the PDP-10 had the RISC philosophy underneath.  All the instructions
could be documented on a 5"x7" card.  The formula used for creating
the proper name of each instruction was common to most of the
machine instructions.  Looking for an instruction to do x was
very easy and didn't require 100s pages of a manual to find it.

> If you were serious:
>
>
> What applications made you want these features?

The monitor (which in your terms is now called the kernal).
Our linker, called LINK, used ASCII, SIXBIT, EBCDIC, and
something else to its job.  "Foreign" data could be in
all kinds of formats.  Anything that needed to use bytes
of any size would use the byte instructions.  If you wanted
to move a block of data, you did a BLT (block transfer)
instruction instead of moving a byte a time.  I could edit
any data with a program called FILDDT.  Can't do that these
days.

/BAH

[toc] | [prev] | [next] | [standalone]

#3412

On 9/3/2011 10:57 AM, jmfbahciv wrote:
> <snort>   I don't consider our byte instructions CISCy.  My opinion,
> which has to be taken as an uneducated opinion in c.a, is that
> the PDP-10 had the RISC philosophy underneath.

I'd not say they were CISCy.  As I recall there was ILDB and IDPB for 
byte loads and stores that were register-storage; no storage to storage 
stuff.  The comp.arch people know a lot more about the details than I 
do, but a barrel-shifter and a few gates for masking would be all you'd 
need.

[toc] | [prev] | [next] | [standalone]

#3466

Peter Flass  <Peter_Flass@Yahoo.com> wrote:
+---------------
| jmfbahciv wrote:
| > <snort>   I don't consider our byte instructions CISCy.  My opinion,
| > which has to be taken as an uneducated opinion in c.a, is that
| > the PDP-10 had the RISC philosophy underneath.
| 
| I'd not say they were CISCy.  As I recall there was ILDB and IDPB for 
| byte loads and stores that were register-storage; no storage to storage 
| stuff.  The comp.arch people know a lot more about the details than I do,
| but a barrel-shifter and a few gates for masking would be all you'd need.
+---------------

I suspect you may be confusing [or misremembering] two independent
aspects of the PDP-10:

1. The byte pointer instructions, LDB/ILDB/DPB/IDPB/IBP, were "memory-
   reference" instructions, and thus worked on byte pointers which were
   located *in memory*: the instructions used the normal address resolution
   (including indexing & indirection) to get to the byte pointers.
   The byte pointers themselves also accessed the data they referenced
   *in memory* (and also including potential indexing & indirection).

2. The 16 general purpose accumulators -- a.k.a. registers -- were also
   accessible *as memory* by any memory-reference instruction, at memory
   locations 0-15 [0-17 octal]. [In the first PDP-6, they *were* actually
   memory -- the "fast registers" were a later, high-priced option.]

   Now on the KA-10 [which had no cache(!), but on which the "fast
   register" option was standard (IIRC)] putting little bits of code
   or byte pointers or data accessed by byte pointers into the registers
   and jumping to them (for code, or using memory-reference instructions,
   for data) was significantly faster than putting then in memory, since
   the registers were fast TTL (4x4?) register files whereas the core
   memory cycle times were 1.0us, 1.67us, or slower, depending on the
   model of core. So "clever" programs often put the inner loops of
   searches (or whatever) into the regs... or byte pointers, or data
   that needed to be munged multiple times.

   Unfortunately, by the time the KL-10 came out, the interactions
   with instruction fetching, the MMU delays, and caching made using
   the registers as "memory" actually *slower* than putting the code/data
   in real memory.

   [I don't remember whether on the intermediate KI-10 it was faster
   or slower to do so. Barb?]

So while you *could* put byte pointer instructions, or byte pointers,
or the data they referenced into registers, that was *not* required
[and wasn't even fastest, on the later machiens].


-Rob

-----
Rob Warnock		<rpw3@rpw3.org>
627 26th Avenue		<http://rpw3.org/>
San Mateo, CA 94403

[toc] | [prev] | [next] | [standalone]

#3467

On 9/5/2011 7:41 AM, Rob Warnock wrote:
> Peter Flass<Peter_Flass@Yahoo.com>  wrote:
> +---------------
> | jmfbahciv wrote:
> |>  <snort>    I don't consider our byte instructions CISCy.  My opinion,
> |>  which has to be taken as an uneducated opinion in c.a, is that
> |>  the PDP-10 had the RISC philosophy underneath.
> |
> | I'd not say they were CISCy.  As I recall there was ILDB and IDPB for
> | byte loads and stores that were register-storage; no storage to storage
> | stuff.  The comp.arch people know a lot more about the details than I do,
> | but a barrel-shifter and a few gates for masking would be all you'd need.
> +---------------
>
> I suspect you may be confusing [or misremembering] two independent
> aspects of the PDP-10:
>
> 1. The byte pointer instructions, LDB/ILDB/DPB/IDPB/IBP, were "memory-
>     reference" instructions, and thus worked on byte pointers which were
>     located *in memory*: the instructions used the normal address resolution
>     (including indexing&  indirection) to get to the byte pointers.
>     The byte pointers themselves also accessed the data they referenced
>     *in memory* (and also including potential indexing&  indirection).
>
> 2. The 16 general purpose accumulators -- a.k.a. registers -- were also
>     accessible *as memory* by any memory-reference instruction, at memory
>     locations 0-15 [0-17 octal]. [In the first PDP-6, they *were* actually
>     memory -- the "fast registers" were a later, high-priced option.]
>
>     Now on the KA-10 [which had no cache(!), but on which the "fast
>     register" option was standard (IIRC)] putting little bits of code
>     or byte pointers or data accessed by byte pointers into the registers
>     and jumping to them (for code, or using memory-reference instructions,
>     for data) was significantly faster than putting then in memory, since
>     the registers were fast TTL (4x4?) register files whereas the core
>     memory cycle times were 1.0us, 1.67us, or slower, depending on the
>     model of core. So "clever" programs often put the inner loops of
>     searches (or whatever) into the regs... or byte pointers, or data
>     that needed to be munged multiple times.
>
>     Unfortunately, by the time the KL-10 came out, the interactions
>     with instruction fetching, the MMU delays, and caching made using
>     the registers as "memory" actually *slower* than putting the code/data
>     in real memory.
>
>     [I don't remember whether on the intermediate KI-10 it was faster
>     or slower to do so. Barb?]
>
> So while you *could* put byte pointer instructions, or byte pointers,
> or the data they referenced into registers, that was *not* required
> [and wasn't even fastest, on the later machiens].
>

Thanks Rob, yes, it was long ago and far away, so I've probaby forgotten 
more about the PDP-10 than I ever knew;-)

[toc] | [prev] | [next] | [standalone]

#3469

Rob Warnock wrote:
> Peter Flass  <Peter_Flass@Yahoo.com> wrote:
> +---------------
> | jmfbahciv wrote:
> | > <snort>   I don't consider our byte instructions CISCy.  My opinion,
> | > which has to be taken as an uneducated opinion in c.a, is that
> | > the PDP-10 had the RISC philosophy underneath.
> |
> | I'd not say they were CISCy.  As I recall there was ILDB and IDPB for
> | byte loads and stores that were register-storage; no storage to storage
> | stuff.  The comp.arch people know a lot more about the details than I do,
> | but a barrel-shifter and a few gates for masking would be all you'd need.
> +---------------
>
> I suspect you may be confusing [or misremembering] two independent
> aspects of the PDP-10:
>
> 1. The byte pointer instructions, LDB/ILDB/DPB/IDPB/IBP, were "memory-
>    reference" instructions, and thus worked on byte pointers which were
>    located *in memory*: the instructions used the normal address resolution
>    (including indexing & indirection) to get to the byte pointers.
>    The byte pointers themselves also accessed the data they referenced
>    *in memory* (and also including potential indexing & indirection).
>
> 2. The 16 general purpose accumulators -- a.k.a. registers -- were also
>    accessible *as memory* by any memory-reference instruction, at memory
>    locations 0-15 [0-17 octal]. [In the first PDP-6, they *were* actually
>    memory -- the "fast registers" were a later, high-priced option.]
>
>    Now on the KA-10 [which had no cache(!), but on which the "fast
>    register" option was standard (IIRC)] putting little bits of code
>    or byte pointers or data accessed by byte pointers into the registers
>    and jumping to them (for code, or using memory-reference instructions,
>    for data) was significantly faster than putting then in memory, since
>    the registers were fast TTL (4x4?) register files whereas the core
>    memory cycle times were 1.0us, 1.67us, or slower, depending on the
>    model of core. So "clever" programs often put the inner loops of
>    searches (or whatever) into the regs... or byte pointers, or data
>    that needed to be munged multiple times.
>
>    Unfortunately, by the time the KL-10 came out, the interactions
>    with instruction fetching, the MMU delays, and caching made using
>    the registers as "memory" actually *slower* than putting the code/data
>    in real memory.
>
>    [I don't remember whether on the intermediate KI-10 it was faster
>    or slower to do so. Barb?]

I don't know hardware specs.
>
> So while you *could* put byte pointer instructions, or byte pointers,
> or the data they referenced into registers, that was *not* required
> [and wasn't even fastest, on the later machiens].

ISTR some things had to be done in the registers but I can't remember
what.  Probably something to do with bootstrapping.  LINK probably did
quite a bit in the registers.

/BAH

[toc] | [prev] | [next] | [standalone]

#3490

Peter Flass <Peter_Flass@Yahoo.com> writes:

> On 9/3/2011 10:57 AM, jmfbahciv wrote:
>> <snort>   I don't consider our byte instructions CISCy.  My opinion,
>> which has to be taken as an uneducated opinion in c.a, is that
>> the PDP-10 had the RISC philosophy underneath.
>
> I'd not say they were CISCy.  As I recall there was ILDB and IDPB for
> byte loads and stores that were register-storage; no storage to
> storage stuff.  The comp.arch people know a lot more about the details
> than I do, but a barrel-shifter and a few gates for masking would be
> all you'd need.

Yeah, but the PDP-10 also featured arbitrary levels of indirection on
memory accesses.  It made possible a lot of interesting data structures,
but also made it very difficult to tell which pieces of memory any given
instruction were going to access in advance.

-- Patrick

[toc] | [prev] | [next] | [standalone]

#3507

On Sep 5, 11:48 pm, Patrick Scheible <k...@zipcon.net> wrote:

> but also made it very difficult to tell which pieces of memory any given
> instruction were going to access in advance.

Yes. While the PDP-10 was a wonderful machine, it would not be
appropriate for that architecture to be today's standard instead of
the x86 architecture - for all of its flaws. It's essential that any
modern architecture lend itself well to deep pipelines and arithmetic
units designed to work quickly in parallel (i.e. Wallace trees instead
of handing the multiplier serially).

John Savard

[toc] | [prev] | [next] | [standalone]

#3519

In article <d12d6d7d-759d-47ab-b894-cf6ce397301e@z4g2000vbz.googlegroups.com>,
Quadibloc  <jsavard@ecn.ab.ca> wrote:
>On Sep 5, 11:48 pm, Patrick Scheible <k...@zipcon.net> wrote:
>
>> but also made it very difficult to tell which pieces of memory any given
>> instruction were going to access in advance.
>
>Yes. While the PDP-10 was a wonderful machine, it would not be
>appropriate for that architecture to be today's standard instead of
>the x86 architecture - for all of its flaws. It's essential that any
>modern architecture lend itself well to deep pipelines and arithmetic
>units designed to work quickly in parallel (i.e. Wallace trees instead
>of handing the multiplier serially).

The only things I have found that would make a pdp10 non-pipelige
friendly are related to the effective address calculation, which could
loop, and was totally unpredictable until the code got there.

If bit 13 (the "@") was set, I cannot see how a pipeline could handle
it without exploding in complexity.

There are some other smaller things, like aliasing registers as 
memory locations, indexing with wild abandon (and even sometimes invoking
"@" there too) and some skips over instructions, but otherwise it
should lend itself well to pipelining. 

The pipelining could also do "bit 13" excepts, and fall back to a
stall if this happened.

Advanced pipelining could analyse one step into a "@", and see if
the chain ended there.

-- mrr

[toc] | [prev] | [next] | [standalone]

#3529

Morten Reistad <first@last.name> writes:

> In article <d12d6d7d-759d-47ab-b894-cf6ce397301e@z4g2000vbz.googlegroups.com>,
> Quadibloc  <jsavard@ecn.ab.ca> wrote:
>>On Sep 5, 11:48 pm, Patrick Scheible <k...@zipcon.net> wrote:
>>
>>> but also made it very difficult to tell which pieces of memory any given
>>> instruction were going to access in advance.
>>
>>Yes. While the PDP-10 was a wonderful machine, it would not be
>>appropriate for that architecture to be today's standard instead of
>>the x86 architecture - for all of its flaws. It's essential that any
>>modern architecture lend itself well to deep pipelines and arithmetic
>>units designed to work quickly in parallel (i.e. Wallace trees instead
>>of handing the multiplier serially).
>
> The only things I have found that would make a pdp10 non-pipelige
> friendly are related to the effective address calculation, which could
> loop, and was totally unpredictable until the code got there.
>
> If bit 13 (the "@") was set, I cannot see how a pipeline could handle
> it without exploding in complexity.
>
> There are some other smaller things, like aliasing registers as 
> memory locations, indexing with wild abandon (and even sometimes invoking
> "@" there too) and some skips over instructions, but otherwise it
> should lend itself well to pipelining. 
>
> The pipelining could also do "bit 13" excepts, and fall back to a
> stall if this happened.
>
> Advanced pipelining could analyse one step into a "@", and see if
> the chain ended there.

You could, but multiple indirection was heavily used in PDP-10 code.
Pipelining failing in that case means it's less than successful
overall.  My understanding is this is why the Jupiter's performance was
less than hoped.

-- Patrick

[toc] | [prev] | [next] | [standalone]

#3556

On 9/6/2011 4:51 PM, Quadibloc wrote:
> On Sep 5, 11:48 pm, Patrick Scheible<k...@zipcon.net>  wrote:
>
>> but also made it very difficult to tell which pieces of memory any given
>> instruction were going to access in advance.
>
> Yes. While the PDP-10 was a wonderful machine, it would not be
> appropriate for that architecture to be today's standard instead of
> the x86 architecture - for all of its flaws. It's essential that any
> modern architecture lend itself well to deep pipelines and arithmetic
> units designed to work quickly in parallel (i.e. Wallace trees instead
> of handing the multiplier serially).
>
> John Savard

I'll bite -

I'm unaware of anything in the PDP-10 floating point architecture that
would have preventing implemention using modern techniques.

The way the PDP-10 instruction set handled indirection *fundamentally* 
causes pipeline implementation issues.

Rob

[toc] | [prev] | [next] | [standalone]

#3561

On Sep 7, 7:54 pm, Rob Doyle <radioe...@gmail.com> wrote:

> I'm unaware of anything in the PDP-10 floating point architecture that
> would have preventing implemention using modern techniques.

I was thinking of its byte handling. Which would just be a trifle
awkward, not impossible, using a barrel shifter.

John Savard

[toc] | [prev] | [next] | [standalone]

#3576

On Wednesday, September 7, 2011 8:54:59 PM UTC-5, Rob Doyle wrote:
> I'm unaware of anything in the PDP-10 floating point architecture that
> would have preventing implemention using modern techniques.

You can build any of the old machines wth gates from a modern gate library.
 
> The way the PDP-10 instruction set handled indirection *fundamentally* 
> causes pipeline implementation issues.

No, you just set up a scenario where when a reservation station launches a memory reference and the result does not indicat indirect, you deliver the result, if it does indicate indirect, the reservation station takes the indirect address and dumps it <back> into the memory reference pipeline again.

Thus not problem for deep pipelines, you just have to eat the whole amount of latency. Only a little trouble for the reservation station.

As to John Savard's barrel shifter issue, I would not approach the problem like that. I would build the same set of gates as the PDP-10 KI used.

{Besides, barrel shifters are so 1980s. None of the other x86 manufactures use them, prefering a 3 level fall through tree of 4-input multiplexers. Less gates of delay and less wires in width.}

Mitch

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web