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

Groups > comp.arch > #3482 > unrolled thread

Bit Interleaving, Instruction Set Support for

Back to article view | Back to comp.arch

Contents

  Bit Interleaving, Instruction Set Support for "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 16:23 -0700
    Re: Bit Interleaving, Instruction Set Support for Mark Thorson <nospam@sonic.net> - 2011-09-05 20:07 -0800
      Re: Bit Interleaving, Instruction Set Support for "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 21:25 -0700
        Re: Bit Interleaving, Instruction Set Support for Andrew Reilly <areilly---@bigpond.net.au> - 2011-09-06 05:09 +0000
          Re: Bit Interleaving, Instruction Set Support for torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-09-06 10:20 +0200
            Re: Bit Interleaving, Instruction Set Support for Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-06 13:28 +0200
              Re: Bit Interleaving, Instruction Set Support for "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-06 11:29 -0700
            Re: Bit Interleaving, Instruction Set Support for "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-06 11:21 -0700
            Re: Bit Interleaving, Instruction Set Support for timcaffrey@aol.com (Tim McCaffrey) - 2011-09-09 19:10 +0000
              Re: Bit Interleaving, Instruction Set Support for "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-10 12:50 -0700
              Re: Bit Interleaving, Instruction Set Support for torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-09-13 10:34 +0200
        Re: Bit Interleaving, Instruction Set Support for Mark Thorson <nospam@sonic.net> - 2011-09-07 12:43 -0800
          Re: Bit Interleaving, Instruction Set Support for "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-10 12:27 -0700
            Re: Bit Interleaving, Instruction Set Support for "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-11 21:05 -0700
          Re: Bit Interleaving, Instruction Set Support for EricP <ThatWouldBeTelling@thevillage.com> - 2011-09-10 16:57 -0400
            Re: Bit Interleaving, Instruction Set Support for George Neuner <gneuner2@comcast.net> - 2011-09-10 23:14 -0400
              Re: Bit Interleaving, Instruction Set Support for nmm1@cam.ac.uk - 2011-09-11 10:16 +0100
                Re: Bit Interleaving, Instruction Set Support for EricP <ThatWouldBeTelling@thevillage.com> - 2011-09-11 12:30 -0400
      Re: Bit Interleaving, Instruction Set Support for Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-06 13:25 +0200
    Re: Bit Interleaving, Instruction Set Support for Quadibloc <jsavard@ecn.ab.ca> - 2011-09-05 21:02 -0700
    Re: Bit Interleaving, Instruction Set Support for Piotr Wyderski <peter.pan@neverland.mil> - 2011-09-06 14:12 +0200
      Re: Bit Interleaving, Instruction Set Support for Bakul Shah <usenet@bitblocks.com> - 2011-09-06 11:49 -0700
        Re: Bit Interleaving, Instruction Set Support for Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-07 11:18 +0200
          Re: Bit Interleaving, Instruction Set Support for Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-09-07 10:54 +0100
            Re: Bit Interleaving, Instruction Set Support for Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-07 20:27 +0200
    Re: Bit Interleaving, Instruction Set Support for MitchAlsup <MitchAlsup@aol.com> - 2011-09-07 12:23 -0700

Page 1 of 2  [1] 2  Next page →

#3482 — Bit Interleaving, Instruction Set Support for

(Thanks, Terje)

[[Category:ISA]]

http://semipublic.comp-arch.net/wiki/Bit_Interleaving,_Instruction_Set_Support_for

= Instruction Set Support for Bit Interleaving =

== What is Bit Interleaving? ==

[[Bit interleaving]] is a very common form of multi-operand bit permutation.
It has been important enough to occasionally warrant special instruction 
set support.

2-way bit interleaving of A and B;

  for i = 0 to N do
    result.bit[2*i] := A.bit[i]
    result.bit[2*i+1] := B.bit[i]

3-way bit interleaving off A, B, C:

  for i = 0 to N do
    result.bit[3*i] := A.bit[i]
    result.bit[3*i+1] := B.bit[i]
    result.bit[3*i+2] := C.bit[i]

M-way bit interleaving of A[i]

  for i = 0 to N do
    for j = 0 to M do
      result.bit[N*i+j] := A[j].bit[i]

Note that since bit interleaving combines multiple operands into a 
single operand, issues of overflow may arise.
For example, the result is often used in address arithmetic,
in which case the inputs (aka the coordinates)
are probably not full width addresses.
The bit interleaving may be used in only a subrange of  the input bits.

== Why Bit Interleaving? ==

See [[http://en.wikipedia.org/wiki/Morton_number_(number_theory) 
Wikipedia Morton numbers]].

Bit interleaving is often used as a component of hash functions.

In particular, bit interleaving of 2D and 3D coordinates in computer 
graphics
often produces hash functions that have better cache locality than 
uninterleaved coordinates used to index an array.

== Bit Interleaving Instructions ==

Intel Larrabee has 1:1 and 2:1 interleave instructions, in both scalar 
and vector form:

   vbitinterleave11pi: 1:1 bit-interleave vectors
   vbitinterleave21pi: 2:1 bit-interleave vectors

   bitinterleave11: 1:1 bit-interleave scalar
   bitinterleave21: 2:1 bit-interleave scalar

(See [[http://drdobbs.com/architecture-and-design/216402188?pgno=5 Mike 
Abrash's Dr. Dobb's article]] which comments that
"is useful for generating swizzled addresses, particularly in 
conjunction with vinsertfield, for example in preparation for texture 
sample fetches (volume textures in the case of vbitinterleave21pi".)

The 1:1 interleaving instruction obviously accomplishes 2D   interleaving,
i.e. the interleaving of two coordinates for a 2D system.

The 2:1 interleaving instruction accoplishes 3D interleaving.
Or, rather, first one interleaves two coordinates, say X and Y, using 1:1,
and then one interleaves the third coordinate, Z, using 2:1.

4:1 interleaving is accomplished by two 1:1 interleaves.
However, operations on objects and spaces of more than 1D, 2D, or 3D are 
much less common.

== Expand (Interleave with 0) ==

Although 1:1 and 2:1 interleaving "fit" into commion instruction sets,
higher degrees of interleaving may not - too many operands may be required.

Some support may be afforded by bit expansion,
or interleaving with 0.
This takes 2 (or 3) inputs:
* the bitvector to which 0s will be inserted between elements
* the number of 0 bits to be inserted between elements
* possibly an offset to cause the result to be aligned appropriately for 
the last step.

The last step would be ORing the results together.
(Or equivalently, ANDing).

[toc] | [next] | [standalone]

#3485

While you're at it, what about bit reverse?

  for i = 0 to N do
    result.bit[i] := A.bit[N-i]

If I recall correctly, this is supposed to be
useful for address generation in FFT.  It was
supported in the hardware of a microcoded
accelerator board I worked on at Weitek.

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

#3487

On 9/5/2011 9:07 PM, Mark Thorson wrote:
> While you're at it, what about bit reverse?
>
>    for i = 0 to N do
>      result.bit[i] := A.bit[N-i]
>
> If I recall correctly, this is supposed to be
> useful for address generation in FFT.  It was
> supported in the hardware of a microcoded
> accelerator board I worked on at Weitek.

I'm collecting as many bit munging operations as I can think of.  Yes, 
bit reverse is one, and transpose is another.  I just write 'em up as I 
have time.

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

#3488

On Mon, 05 Sep 2011 21:25:50 -0700, Andy \"Krazy\" Glew wrote:

> On 9/5/2011 9:07 PM, Mark Thorson wrote:
>> While you're at it, what about bit reverse?
>>
>>    for i = 0 to N do
>>      result.bit[i] := A.bit[N-i]
>>
>> If I recall correctly, this is supposed to be useful for address
>> generation in FFT.  It was supported in the hardware of a microcoded
>> accelerator board I worked on at Weitek.
> 
> I'm collecting as many bit munging operations as I can think of.  Yes,
> bit reverse is one, and transpose is another.  I just write 'em up as I
> have time.

On recent ARM (perhaps only in the NEON set) there are both "shuffle" and 
"deal" instructions: shuffle is your 1:1 interleave and deal is the 
reverse (taking an interleaved double-length vector and producing two de-
interleaved results).

Cheers,

-- 
Andrew

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

#3493

Andrew Reilly <areilly---@bigpond.net.au> writes:


> On recent ARM (perhaps only in the NEON set) there are both "shuffle" and 
> "deal" instructions: shuffle is your 1:1 interleave and deal is the 
> reverse (taking an interleaved double-length vector and producing two de-
> interleaved results).

I think "zip" and "unzip" are better names for these operations.

A more general form of zip would be an operation that takes two
operands: A bitmask and bit vector.  The bits in the bit vector (from
one end) would be positioned at the 1-bits in the bitmask.

For example, if the bitmask is 101101 and the bitvector has bits abcdef,
then the result would be c0de0f for a right-zip and a0bc0e for a
left-zip.

Any m:n zip can be made using two of the above and a bitwise or --
providing the bit masks are available in registers.

The inverse operation would take the bits at the positions indicated by
the bitmask and compress them to one end.

I'm thinking that both operations could be implemented by a relatively
simple modification of a multiplier.

	Torben

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

#3499

Torben Ægidius Mogensen wrote:
> A more general form of zip would be an operation that takes two
> operands: A bitmask and bit vector.  The bits in the bit vector (from
> one end) would be positioned at the 1-bits in the bitmask.
>
> For example, if the bitmask is 101101 and the bitvector has bits abcdef,
> then the result would be c0de0f for a right-zip and a0bc0e for a
> left-zip.
>
> Any m:n zip can be made using two of the above and a bitwise or --
> providing the bit masks are available in registers.
>
> The inverse operation would take the bits at the positions indicated by
> the bitmask and compress them to one end.
>
> I'm thinking that both operations could be implemented by a relatively
> simple modification of a multiplier.

Indeed.

Aren't you more or less back at Andy's desired BMM now?

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#3505

On 9/6/2011 4:28 AM, Terje Mathisen wrote:
> Torben Ægidius Mogensen wrote:
>> A more general form of zip would be an operation that takes two
>> operands: A bitmask and bit vector. The bits in the bit vector (from
>> one end) would be positioned at the 1-bits in the bitmask.
>>
>> For example, if the bitmask is 101101 and the bitvector has bits abcdef,
>> then the result would be c0de0f for a right-zip and a0bc0e for a
>> left-zip.
>>
>> Any m:n zip can be made using two of the above and a bitwise or --
>> providing the bit masks are available in registers.
>>
>> The inverse operation would take the bits at the positions indicated by
>> the bitmask and compress them to one end.
>>
>> I'm thinking that both operations could be implemented by a relatively
>> simple modification of a multiplier.
>
> Indeed.
>
> Aren't you more or less back at Andy's desired BMM now?
>
> Terje

No, Torben's zip and unzip (which I was also thinking of, but had not 
gotten around to writing down as an invention disclsoure - Torben beat 
me fair and  square) is a special case of a bit permutation.

For that matter, BMM (Bit Matrix Multiply) is more general than a bit 
permutation, since any bit in the output can be a function of more than 
one bit of the input.

The most general bit permutation of N bit operands takes as an argument 
a vector of N indexes each of ceil(log2(N)) width.  This allows 
replication of bits.  Or, equivalently, a BMM matrix with only a single 
1 in any row and column.

Torben's zip and unzip correspond to having an index vector that is 
constrained to be monotonic - bit numbers to be extracted or expanded 
can only be increasing (or decreasing). Less  geberal, but good enough 
for many purposes.

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

#3504

On 9/6/2011 1:20 AM, Torben Ægidius Mogensen wrote:
> Andrew Reilly<areilly---@bigpond.net.au>  writes:
>
>
>> On recent ARM (perhaps only in the NEON set) there are both "shuffle" and
>> "deal" instructions: shuffle is your 1:1 interleave and deal is the
>> reverse (taking an interleaved double-length vector and producing two de-
>> interleaved results).
>
> I think "zip" and "unzip" are better names for these operations.
>
> A more general form of zip would be an operation that takes two
> operands: A bitmask and bit vector.  The bits in the bit vector (from
> one end) would be positioned at the 1-bits in the bitmask.
>
> For example, if the bitmask is 101101 and the bitvector has bits abcdef,
> then the result would be c0de0f for a right-zip and a0bc0e for a
> left-zip.
>
> Any m:n zip can be made using two of the above and a bitwise or --
> providing the bit masks are available in registers.
>
> The inverse operation would take the bits at the positions indicated by
> the bitmask and compress them to one end.
>
> I'm thinking that both operations could be implemented by a relatively
> simple modification of a multiplier.
>
> 	Torben



Yes, I think this is a very good special case of the general bit 
permutation.  Especially for what I called "bit expansion", or 
interleaving with 0.

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

#3595

In article <7zwrdmaxqg.fsf@ask.diku.dk>, torbenm@diku.dk says...
>
>Andrew Reilly <areilly---@bigpond.net.au> writes:
>
>
>> On recent ARM (perhaps only in the NEON set) there are both "shuffle" and 
>> "deal" instructions: shuffle is your 1:1 interleave and deal is the 
>> reverse (taking an interleaved double-length vector and producing two de-
>> interleaved results).
>
>I think "zip" and "unzip" are better names for these operations.
>
>A more general form of zip would be an operation that takes two
>operands: A bitmask and bit vector.  The bits in the bit vector (from
>one end) would be positioned at the 1-bits in the bitmask.
>
>For example, if the bitmask is 101101 and the bitvector has bits abcdef,
>then the result would be c0de0f for a right-zip and a0bc0e for a
>left-zip.
>
>Any m:n zip can be made using two of the above and a bitwise or --
>providing the bit masks are available in registers.
>
>The inverse operation would take the bits at the positions indicated by
>the bitmask and compress them to one end.
>
>I'm thinking that both operations could be implemented by a relatively
>simple modification of a multiplier.
>
>        Torben

See http://software.intel.com/file/36945 for the Haswell New Instructions 
(due 2013?) PEXT and PDEP.  They do what you suggest (more or less).

		- Tim

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

#3604

On 9/9/2011 12:10 PM, Tim McCaffrey wrote:
> In article<7zwrdmaxqg.fsf@ask.diku.dk>, torbenm@diku.dk says...
>>
>> Andrew Reilly<areilly---@bigpond.net.au>  writes:
>>
>>
>>> On recent ARM (perhaps only in the NEON set) there are both "shuffle" and
>>> "deal" instructions: shuffle is your 1:1 interleave and deal is the
>>> reverse (taking an interleaved double-length vector and producing two de-
>>> interleaved results).
>>
>> I think "zip" and "unzip" are better names for these operations.
>>
>> A more general form of zip would be an operation that takes two
>> operands: A bitmask and bit vector.  The bits in the bit vector (from
>> one end) would be positioned at the 1-bits in the bitmask.
>>
>> For example, if the bitmask is 101101 and the bitvector has bits abcdef,
>> then the result would be c0de0f for a right-zip and a0bc0e for a
>> left-zip.
>>
>> Any m:n zip can be made using two of the above and a bitwise or --
>> providing the bit masks are available in registers.
>>
>> The inverse operation would take the bits at the positions indicated by
>> the bitmask and compress them to one end.
>>
>> I'm thinking that both operations could be implemented by a relatively
>> simple modification of a multiplier.
>>
>>         Torben
>
> See http://software.intel.com/file/36945 for the Haswell New Instructions
> (due 2013?) PEXT and PDEP.  They do what you suggest (more or less).
>
> 		- Tim
>



Good point.

This is in part why I am trying to write comp-arch.net: to make some of 
this information easier to find.

E.g. for example I had not realized that Torben's zip and unzip were the 
same as the[[compress bits under mask]] instruction (and accompanying 
[[uncompress bits under mask]], which I had already posted on the wiki 
(http://semipublic.comp-arch.net/wiki/Compress_Bits_Under_Mask)

And [[compress bits under mask]] is in turn the same as the 
[[centrifuge]] instruction that has been done before.  Although IIRC 
Cray's centrifuge was a special unit, not so neatly packaged as an 
instruction.

And these seem to be the same as Intel's [[PEXT]] and [[PDEP]] instructions.

So many different names, for similar concepts.



All of these are [[bit interleave with zero]] instructions.  You can use 
them to do a full bit interleaving by ORing their results.


Or, you can do what Larrabee's vbitinterleave11 and vbitinterleave21 
instructions do - interleave the data directly.



I.e.

    Larrabee bitinterleave 11 and 21:
        * fixed interleaving patterns
        * fewer instructions

    compress/uncompress bits under mask
        * flexible interleaving patterns (also bitfield extraction)
        * but more instructions needed
          to accomplish what Larrabee does in a single instruction

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

#3652

timcaffrey@aol.com (Tim McCaffrey) writes:

> In article <7zwrdmaxqg.fsf@ask.diku.dk>, torbenm@diku.dk says...

>>A more general form of zip would be an operation that takes two
>>operands: A bitmask and bit vector.  The bits in the bit vector (from
>>one end) would be positioned at the 1-bits in the bitmask.
>>
>>For example, if the bitmask is 101101 and the bitvector has bits abcdef,
>>then the result would be c0de0f for a right-zip and a0bc0e for a
>>left-zip.
>>
>>The inverse operation would take the bits at the positions indicated by
>>the bitmask and compress them to one end.

> See http://software.intel.com/file/36945 for the Haswell New Instructions 
> (due 2013?) PEXT and PDEP.  They do what you suggest (more or less).

They do indeed.  Thanks for the ref.

	Torben

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

#3543

Andy \"Krazy\" Glew wrote:
> 
> I'm collecting as many bit munging operations as I can think of.  Yes,
> bit reverse is one, and transpose is another.  I just write 'em up as I
> have time.

Sorry if I missed the explanation, but what
is the purpose of this?  It seems like you're
collecting an encyclopedia of computer architecture
prior art.

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

#3603

On 9/7/2011 1:43 PM, Mark Thorson wrote:
> Andy \"Krazy\" Glew wrote:
>>
>> I'm collecting as many bit munging operations as I can think of.  Yes,
>> bit reverse is one, and transpose is another.  I just write 'em up as I
>> have time.
>
> Sorry if I missed the explanation, but what
> is the purpose of this?  It seems like you're
> collecting an encyclopedia of computer architecture
> prior art.

I *am* trying to write an encyclopedia of computer architecture.  Or, as 
I have long mentioned on this newsgroup, I am trying to write "The Art 
of Computer Architecture", inspired by Knuth.  I want my wiki/book to be 
a collection, a grab-bag, of computer architecture ideas and techniques.

I get tired of NCGs (New College Grads)

Unfortunately, I am not doing as good a job as Knuth in providing 
references.  I am more interested in regularity, pointing to patterns, 
etc., than in pointing to a possibly irregular history.

I'm not opposed to academic references. I'll provide them when I have 
time, or when they are right at hand.  But I don't have much time to 
work on this.

This lack of references makes my wiki/book not very useful as an 
encyclopedia of prior art looking backwards.  Although I suppose that 
anything, once mentioned on my wiki/book, is prior art going forwards. 
For that matter, so is anything discussed on comp.arch.

I originally tried to some of this on wikipedia, but wikipedia aspires 
to having proper references for everything.  And wikipedia folk deleted 
some of my contributions.  So I decided to start doing it myself. 
Perhaps, one day, comp-arch.net can be an authority referred to by 
wikipedia.

I would like to make comp-arch.net a public or semi-public forum. 
However, my first attempts to do that resulted in excessive wiki spam.
In my copious spare time I want o tweak the wiki software to allow this, 
but I am making progress at that even more slowly.

I think I have a statement of my goals on the wiki somewhere.  If not, I 
should add it.

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

#3629

On 9/10/2011 12:27 PM, Andy "Krazy" Glew wrote:
> On 9/7/2011 1:43 PM, Mark Thorson wrote:
>> Andy \"Krazy\" Glew wrote:
>>>
>>> I'm collecting as many bit munging operations as I can think of. Yes,
>>> bit reverse is one, and transpose is another. I just write 'em up as I
>>> have time.
>>
>> Sorry if I missed the explanation, but what
>> is the purpose of this? It seems like you're
>> collecting an encyclopedia of computer architecture
>> prior art.
>
> I *am* trying to write an encyclopedia of computer architecture. Or, as
> I have long mentioned on this newsgroup, I am trying to write "The Art
> of Computer Architecture", inspired by Knuth. I want my wiki/book to be
> a collection, a grab-bag, of computer architecture ideas and techniques.
>
> I get tired of NCGs (New College Grads)

Not a Freudian slip!

I *love* NCGs.  So much energy!

But, I get tired of NCGs not knowing what has already been done.

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

#3605

Mark Thorson wrote:
> Andy \"Krazy\" Glew wrote:
>> I'm collecting as many bit munging operations as I can think of.  Yes,
>> bit reverse is one, and transpose is another.  I just write 'em up as I
>> have time.
> 
> Sorry if I missed the explanation, but what
> is the purpose of this?  It seems like you're
> collecting an encyclopedia of computer architecture
> prior art.

As a by-the-way, Thursday the US Senate passed the
America Invents Act effectively changing from
first-to-invent to first-to-file.
Also has some changes to prior-art definitions.
House passed it back on 23 June and Obama is expected to sign
so it would phase into effect 12 to 18 months afterward.

(I don't know how accurate this page is, but here is a link)
http://en.wikipedia.org/wiki/America_Invents_Act

Eric

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

#3608

On Sat, 10 Sep 2011 16:57:43 -0400, EricP
<ThatWouldBeTelling@thevillage.com> wrote:

>As a by-the-way, Thursday the US Senate passed the
>America Invents Act effectively changing from
>first-to-invent to first-to-file.
>Also has some changes to prior-art definitions.
>House passed it back on 23 June and Obama is expected to sign
>so it would phase into effect 12 to 18 months afterward.
>
>(I don't know how accurate this page is, but here is a link)
>http://en.wikipedia.org/wiki/America_Invents_Act
>
>Eric

Yup.  This brings the US law into line with much of the rest of the
WIPO world - whether that's a good thing is yet to be determined.  But
it will mean a lot less "interference" work for IP attorneys (and
unemployed attorneys tend to become politicians.)

IANAL
George

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

#3613

In article <1m9o67llk1cqiimlh3lakjmgufk0g53876@4ax.com>,
George Neuner  <gneuner2@comcast.net> wrote:
>On Sat, 10 Sep 2011 16:57:43 -0400, EricP
><ThatWouldBeTelling@thevillage.com> wrote:
>
>>As a by-the-way, Thursday the US Senate passed the
>>America Invents Act effectively changing from
>>first-to-invent to first-to-file.
>>Also has some changes to prior-art definitions.
>>House passed it back on 23 June and Obama is expected to sign
>>so it would phase into effect 12 to 18 months afterward.
>>
>>(I don't know how accurate this page is, but here is a link)
>>http://en.wikipedia.org/wiki/America_Invents_Act
>
>Yup.  This brings the US law into line with much of the rest of the
>WIPO world - whether that's a good thing is yet to be determined.  But
>it will mean a lot less "interference" work for IP attorneys (and
>unemployed attorneys tend to become politicians.)

As far as I know, that is false.  Most countries use a form of first
to invent.

The Act should really be called America_Steals, as it is intended to
allow the patenting of inventions made by other people, especially
in other countries and by non-grasping academics.  In recent years,
we have seen a vast increase in patents obtained by companies with
lots of lawyers but no research facilities, and this Act will make
that the norm.  It will also SERIOUSLY harm information-sharing
within the research community, because any information a researcher
shares can be used to obtain a patent and even force the inventor
to pay royalties on working with his own invention!

In the USA and its satellites and vassal states, Jehovah was
dethroned a long time ago by Mammon.


Regards,
Nick Maclaren.

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

#3620

nmm1@cam.ac.uk wrote:
> In article <1m9o67llk1cqiimlh3lakjmgufk0g53876@4ax.com>,
> George Neuner  <gneuner2@comcast.net> wrote:
>> On Sat, 10 Sep 2011 16:57:43 -0400, EricP
>> <ThatWouldBeTelling@thevillage.com> wrote:
>>
>>> As a by-the-way, Thursday the US Senate passed the
>>> America Invents Act effectively changing from
>>> first-to-invent to first-to-file.
>>> Also has some changes to prior-art definitions.
>>> House passed it back on 23 June and Obama is expected to sign
>>> so it would phase into effect 12 to 18 months afterward.
>>>
>>> (I don't know how accurate this page is, but here is a link)
>>> http://en.wikipedia.org/wiki/America_Invents_Act
>> Yup.  This brings the US law into line with much of the rest of the
>> WIPO world - whether that's a good thing is yet to be determined.  But
>> it will mean a lot less "interference" work for IP attorneys (and
>> unemployed attorneys tend to become politicians.)
> 
> As far as I know, that is false.  Most countries use a form of first
> to invent.

After looking at multiple legal sources,
it seems you are correct only to the extent that
that is as far as you know. :-)

> The Act should really be called America_Steals, as it is intended to
> allow the patenting of inventions made by other people, especially
> in other countries and by non-grasping academics.  In recent years,
> we have seen a vast increase in patents obtained by companies with
> lots of lawyers but no research facilities, and this Act will make
> that the norm.  It will also SERIOUSLY harm information-sharing
> within the research community, because any information a researcher
> shares can be used to obtain a patent and even force the inventor
> to pay royalties on working with his own invention!
> 
> In the USA and its satellites and vassal states, Jehovah was
> dethroned a long time ago by Mammon.
> 
> 
> Regards,
> Nick Maclaren.

The changes to prior-art and disclosure are far more important.
It is difficult to find authoritative sources at this early date,
however while the old patent law only defined "on sale" prior-art
as in the US, the new law defines "on sale" as anywhere.

However one must look at how "on sale" is now defined,
so that is why exact answers are difficult.
For example, if device A includes device B but does not document B,
does that constitute a "sale" of B, thus making B non-patentable,
or is B a trade secret and therefore not publically disclosed?

IANAL
Eric

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

#3498

Mark Thorson wrote:
> While you're at it, what about bit reverse?
>
>    for i = 0 to N do
>      result.bit[i] := A.bit[N-i]
>
> If I recall correctly, this is supposed to be
> useful for address generation in FFT.  It was
> supported in the hardware of a microcoded
> accelerator board I worked on at Weitek.

Bit reverse used to be an important part of the FFT algorithm.

Well, not anymore:

For small sizes FFTW and similar codes will unroll/compile/compress 
everthing completely, so there are no address calculations at all, for 
slightly larger sizes a small lookup table handles this just fine.

As soon as we get into larger FFTs the the actual memory accesses 
dominate, to the point where calculations could just as well be free, right?

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#3486

And here I thought it would be called "bit transpose".

John Savard

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web