Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Newsgroups | comp.arch, alt.folklore.computers |
| Subject | Re: Solving the Floating-Point Goldilocks Problem! |
| Date | 2011-09-02 13:44 +0000 |
| Organization | "Have EDDT, will travel" |
| Message-ID | <PM0004ABF5A32D0B6C@ac8120a2.ipt.aol.com> (permalink) |
| References | <PM0004ABE18AD7D78B@aca343ef.ipt.aol.com> <PM0004ABE18AD7D78B@aca343ef.ipt.aol.com> <PM0004ABE18AD7D78B@aca343ef.ipt.aol.com> <4E5FA249.7040604@SPAM.comp-arch.net> |
Cross-posted to 2 groups.
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
Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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