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

Groups > comp.arch > #3388

Re: Solving the Floating-Point Goldilocks Problem!

Cross-posted to 2 groups.

Show all headers | View raw

"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

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web