211–220 of 220 posts
> gcc doesn’t have a rotation intrinsic, so I couldn’t try it there Gcc and Clang both recognize the pattern of shifts and OR that reproduce a rotation, and substitute the actual instruction, no intrinsic needed. I bet MSVC does too.
Earlier quoted context omitted.
The obvious form of the code with a comparison still produces a conditional branch on latest gcc [1]. It's extremely doubtful that you'll find a version that uses any comparison that consistently performs as quickly as any version that uses a little bit-twiddling, no matter what modern CPU you're talking about. Many of your statements are misleading in context. Implying that you can't know or deduce things about the…
The code generated by gcc in this case is just bad. It is known that gcc fails to do "if conversion" in many cases when it should. The correct code using the CMOV instruction and only a single computation of the expression could easily be written with inline assembly. However, if inline assembly is used, there is a much simpler solution using the carry flag, which was presented at the end of the article that started…
We don't need to admit defeat in optimizing such a simple case. A comparison is unnecessary and will pessimize, compared to a little bit-manipulation.
Earlier quoted context omitted.
This thread is full of people who challenged themselves to solve it and then failed to come up with the 'obvious' 1-cycle solution. It's clearly non-obvious, as this thread shows. The actual patent system failure here is the patent is not useful -- it's not valuable. If you needed this solution, you could sit down and derive it in less than an hour. That's not because it's obvious, but because the scope is so small.…
> This thread is full of people who challenged themselves to solve it and then failed to come up with the 'obvious' 1-cycle solution. It's clearly non-obvious, as this thread shows. If a significant fraction of people come up with it on the spot, it's obvious. And they did.
Keep in mind this solution was to support MPEG-1 video encoding in the olden days when state of the art processors were 100 MHz and 800 nm process. Doing this in 1 cycle while reusing already existing function units seems like a clever solution to me -- not patent-worthy, not difficult, but clever.
Earlier quoted context omitted.
> This thread is full of people who challenged themselves to solve it and then failed to come up with the 'obvious' 1-cycle solution. It's clearly non-obvious, as this thread shows. If a significant fraction of people come up with it on the spot, it's obvious. And they did.
I don't even see a single comment mentioning doing this in 1 cycle except from those who read the patent, much less reusing existing functional units to do so, so it's not clear to me any commenter came up with an equivalent to the patented solution or even identified the problem solved by it. Keep in mind this solution was to support MPEG-1 video encoding in the olden days when state of the art processors were 100 M…
If so then the technique in the post isn't actually patented.
If that C code would get threatened, then the 1 cycle thing is a red herring.
Also "Doing this in 1 cycle while reusing already existing function units"? In hardware you can use a normal adder without any special technique...
Earlier quoted context omitted.
I don't even see a single comment mentioning doing this in 1 cycle except from those who read the patent, much less reusing existing functional units to do so, so it's not clear to me any commenter came up with an equivalent to the patented solution or even identified the problem solved by it. Keep in mind this solution was to support MPEG-1 video encoding in the olden days when state of the art processors were 100 M…
Are you very sure that patent would never get threatened toward a software implementation that doesn't know anything about cycles? If so then the technique in the post isn't actually patented. If that C code would get threatened, then the 1 cycle thing is a red herring. Also "Doing this in 1 cycle while reusing already existing function units"? In hardware you can use a normal adder without any special technique...
Earlier quoted context omitted.
It's not the solution that's patented, but it's the implementation in a single CPU cycle in hardware.
So the compiler developers had to pay fees? Or Intel and AMD?
But likely, Intel/AMD would have had to pay fees if they were implementing a similar solution in their hardware.
Earlier quoted context omitted.
Are you very sure that patent would never get threatened toward a software implementation that doesn't know anything about cycles? If so then the technique in the post isn't actually patented. If that C code would get threatened, then the 1 cycle thing is a red herring. Also "Doing this in 1 cycle while reusing already existing function units"? In hardware you can use a normal adder without any special technique...
I've already said twice now that it's not patent-worthy, so it seems we're in agreement on that point.
Having done computer architecture and bit twiddling x86 in the ye olden days, I immediately, independently converged on the patented solution (code / circuit / Verilog, more or less the same thing). It goes to show how broken the USPTO is because it's obvious to anyone in the field. Patents are supposed to be nonobvious. (35 USC 103) https://patentdefenses.klarquist.com/obviousness-sec-103/
This is bizarre. I wonder how many of us saw that title, thought "That's a really simple problem, surely?" came up with a solution and then were shocked when their coffee-lacking brain actually came up with the patented solution? I mean... ignoring the bitwise arithmentic (which this only obvious to people used to doing binary operations) this is the kind of maths that an 11yo could do. That said, the patented soluti…
Having done computer architecture and bit twiddling x86 in the ye olden days, I immediately, independently converged on the patented solution (code / circuit / Verilog, more or less the same thing). It goes to show how broken the USPTO is because it's obvious to anyone in the field. Patents are supposed to be nonobvious. (35 USC 103) https://patentdefenses.klarquist.com/obviousness-sec-103/
What is obvious today might not have been obvious in 1996. Our experiences and training has changed dramatically over the past 26 years.