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

Groups > comp.arch > #4049 > unrolled thread

Q: bit shifting

Back to article view | Back to comp.arch

Contents

  Q: bit shifting Mok-Kong Shen <mok-kong.shen@t-online.de> - 2011-10-07 13:31 +0200
    Re: Q: bit shifting nmm1@cam.ac.uk - 2011-10-07 12:17 +0100
      Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-07 17:35 +0200
        Re: Q: bit shifting Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-10-07 09:31 -0700
          Re: Q: bit shifting nmm1@cam.ac.uk - 2011-10-07 17:16 +0100
            Re: Q: bit shifting Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-10-07 23:13 -0700
              Re: Q: bit shifting nmm1@cam.ac.uk - 2011-10-08 09:56 +0100
                Re: Q: bit shifting Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-08 21:28 +0000
                Re: Q: bit shifting timcaffrey@aol.com (Tim McCaffrey) - 2011-10-11 15:05 +0000
                  Re: Q: bit shifting Sean Case <seancase@tpg.com.au> - 2011-10-16 23:15 +1000
                    Re: Q: bit shifting timcaffrey@aol.com (Tim McCaffrey) - 2011-10-19 20:12 +0000
        Re: Q: bit shifting Robert Wessel <robertwessel2@yahoo.com> - 2011-10-07 12:24 -0500
          Re: Q: bit shifting Kai Harrekilde-Petersen <khp@harrekilde.dk> - 2011-10-07 19:27 +0200
            Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-08 10:41 +0200
              Re: Q: bit shifting Kai Harrekilde-Petersen <khp@harrekilde.dk> - 2011-10-08 11:28 +0200
                Re: Q: bit shifting Andrew Reilly <areilly---@bigpond.net.au> - 2011-10-08 21:38 +0000
              Re: Q: bit shifting Robert Wessel <robertwessel2@yahoo.com> - 2011-10-08 22:57 -0500
                Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-09 08:18 +0200
                Re: Q: bit shifting Mok-Kong Shen <mok-kong.shen@t-online.de> - 2011-10-19 15:08 +0200
              Re: Q: bit shifting Michael S <already5chosen@yahoo.com> - 2011-10-11 16:41 -0700
                Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-12 07:55 +0200
                  Re: Q: bit shifting MitchAlsup <MitchAlsup@aol.com> - 2011-10-12 10:21 -0700
                    Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-12 21:22 +0200
                      Re: Q: bit shifting kenney@cix.compulink.co.uk - 2011-10-13 11:00 -0500
                        Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-13 20:32 +0200
        Re: Q: bit shifting Mike Hore <mike_horeREM@OVE.invalid.aapt.net.au> - 2011-10-11 17:08 +1100
    Re: Q: bit shifting MitchAlsup <MitchAlsup@aol.com> - 2011-10-07 12:49 -0700
      Re: Q: bit shifting nmm1@cam.ac.uk - 2011-10-07 21:20 +0100
      The word is devolving into 3 architectures (NOT?) "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-07 19:48 -0700
        Re: The word is devolving into 3 architectures (NOT?) Mark Thorson <nospam@sonic.net> - 2011-10-07 19:56 -0800
        Re: The word is devolving into 3 architectures (NOT?) "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-10-08 04:53 +0200
        Re: The word is devolving into 3 architectures (NOT?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-10-08 17:26 +0000
      Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-08 10:47 +0200
        Re: Q: bit shifting MitchAlsup <MitchAlsup@aol.com> - 2011-10-08 12:27 -0700
          Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-09 08:07 +0200
            Re: Q: bit shifting MitchAlsup <MitchAlsup@aol.com> - 2011-10-09 12:36 -0700
              Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-10 09:06 +0200
                Re: Q: bit shifting timcaffrey@aol.com (Tim McCaffrey) - 2011-10-10 15:31 +0000
                  Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-10 18:13 +0200
                    Re: Q: bit shifting timcaffrey@aol.com (Tim McCaffrey) - 2011-10-10 20:27 +0000
                      Re: Q: bit shifting Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-10 23:45 +0200
                        Re: Q: bit shifting Robert Wessel <robertwessel2@yahoo.com> - 2011-10-10 17:32 -0500
                          Re: Q: bit shifting timcaffrey@aol.com (Tim McCaffrey) - 2011-10-11 14:58 +0000
                            Re: Q: bit shifting Robert Wessel <robertwessel2@yahoo.com> - 2011-10-11 11:30 -0500
                              Re: Q: bit shifting "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-11 10:05 -0700
                                Re: Q: bit shifting timcaffrey@aol.com (Tim McCaffrey) - 2011-10-11 17:59 +0000
                                Re: Q: bit shifting timcaffrey@aol.com (Tim McCaffrey) - 2011-10-11 18:00 +0000
                                  Re: Q: bit shifting Al Grant <algrant@myrealbox.com> - 2011-10-11 13:49 -0700
                                    Re: Q: bit shifting Al Grant <algrant@myrealbox.com> - 2011-10-11 14:18 -0700
                                Re: Q: bit shifting Robert Wessel <robertwessel2@yahoo.com> - 2011-10-11 16:03 -0500
                  Re: Q: bit shifting MitchAlsup <MitchAlsup@aol.com> - 2011-10-10 09:52 -0700
          Re: Q: bit shifting anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-10-09 12:24 +0000
            Re: Q: bit shifting nmm1@cam.ac.uk - 2011-10-09 13:13 +0100
    Re: Q: bit shifting Quadibloc <jsavard@ecn.ab.ca> - 2011-10-09 10:11 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4153

Michael S wrote:
> On Oct 8, 10:41 am, Terje Mathisen<"terje.mathisen at tmsw.no">
>> Particularly since that 5-bit limit is even enforced for the double-wide
>> (i.e. 64-bit source) shifts. :-(
>>
> By double-wide do you mean SHLD/SHRD? Yes, that true, [in 32-bit mode]
> SHLD is limited to 5 bits.

That's indeed what I meant: "double-wide" meaning twice the width of a 
single register.
>
> However for me your above statement sounds like SHL/SHR/SAR in 64-bit
> mode are limited to 5 bits. Which is, of course, incorrect.

Of course.

The 64-bit version _had_ to allow at the very least [0-63] bit shifts, 
I've never even verified this.

OTOH, they (AMD) could have fixed it so as to allow effective counts 
from 0 to 64, but I assumed that they didn't?

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

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

#4157

On Wednesday, October 12, 2011 12:55:17 AM UTC-5, Terje Mathisen wrote:
> OTOH, they (AMD) could have fixed it so as to allow effective counts 
> from 0 to 64, but I assumed that they didn't?

No, AMD would have lost bug-for-bug compatability with <the other guys>.

Mitch

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

#4160

MitchAlsup wrote:
> On Wednesday, October 12, 2011 12:55:17 AM UTC-5, Terje Mathisen wrote:
>> OTOH, they (AMD) could have fixed it so as to allow effective counts
>> from 0 to 64, but I assumed that they didn't?
>
> No, AMD would have lost bug-for-bug compatability with<the other guys>.

I meant for x64 only, since AMD effectively got to define that one.

Or did Microsoft force AMD to be compatible with a "if we ever do 
64-bit, this is what it will be like" specification from Intel?

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

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

#4180

In article <906hm8-5m02.ln1@ntp6.tmsw.no>, "terje.mathisen at tmsw.no" 
(Terje Mathisen) wrote:

> Or did Microsoft force AMD to be compatible with a "if we ever do 
> 64-bit, this is what it will be like" specification from Intel?

 More likely it was done to make it easier to run recompiled 32 bit 
source code on a 64 bit processor. 

 Ken Young

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

#4185

kenney@cix.compulink.co.uk wrote:
> In article<906hm8-5m02.ln1@ntp6.tmsw.no>, "terje.mathisen at tmsw.no"
> (Terje Mathisen) wrote:
>
>> Or did Microsoft force AMD to be compatible with a "if we ever do
>> 64-bit, this is what it will be like" specification from Intel?
>
>   More likely it was done to make it easier to run recompiled 32 bit
> source code on a 64 bit processor.

That presupposes that there exists at least one (important) compiler 
which will happily load shift counts with spurious top bits set, 
depending upon the cpu to mask them!

I must admit that I have a hard time believing this.

It is in fact much more probable that some bit hacking code has been 
written which actually does depend on the masking:

   bitpos += bits;
   return buffer_of_32bit_values[bitpos >> 5] >> bitpos;

I.e. there's no need to mask the bit offset into the relevant word, 
since that masking happens by default anyway.

It also means that it is always faster to work with register-sized 
chunks, otherwise you do need that mask:

   bitpos += bits;
   return buffer_of_8bit_values[bitpos >> 3] >> (bitpos & 7);

Terje

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

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

#4137

On 8/10/11 2:35 AM, Terje Mathisen wrote:

> ...
> Nick is absolutely correct here, bit shifts have been badly treated
> since day one.
>
> Most people would probably agree that a left shift (or logical right
> shift) of an N-wide register by N or more bits, should result in a zero.
>
> Likewise, arithmetic right shifts of the same size should give the sign
> bit replicated across the entire register.
>
> If you absolutely have to limit N, then make the limit no less than
> twice the register width. Masking the shift count is a really bad idea...

KDF9 nearly got it right.  On a 48-bit word, or 96-bit doubleword, you 
could specify a shift from -128 to +127, and get what you expected. 
Positive shifts were left, negative shifts were right.  Going outside 
the limits gave "incorrect results with no warning" (from the Usercode 
manual on Bitsavers).

Cheers,  Mike.

---------------------------------------------------------------
      Mike Hore     mike_horeREM@OVE.invalid.aapt.net.au
---------------------------------------------------------------

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

#4063

In the Mc88K architecture a shift was encoded as a degenerate subset of a bit field extract (or insert) instruction. Bit positions from 4:0 were the shift count, bit positions 9:5 were the wield width (0->32-bits). In retrospect, separating the field width from the shift count by 3-ish bits would have made the encoding much more pleasant for everyone involved.

At the C-level, a programmer could do his own bit field manipulations via the shift operators::

    field = container >> ((WIDTH<<5) | OFFSET);

And we taught the compiler to use these instructions to do C-level bit manipulation. {In retrospect '<<5' should have been '<<8')

The extract instruction were available in signed and unsigned forms, and even useful in FP I/O formatting.

As to Terje's assertion that a right shift of greater than word count should be zero, I disagree. I take the position that this is really a SHIFT operation (signed or otherwise) you use shift instructions/operations to move fields of bits around in a container. At the language level, a portable language cannot assume that there are double width containers. There are no good answers here, but since the world is devolving into 3 architectures, it maters less these days than back when the count was approaching 20 (all different).

Mitch

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

#4064

In article <18197974.1344.1318016976706.JavaMail.geo-discussion-forums@yqmn40>,
MitchAlsup  <comp.arch@googlegroups.com> wrote:
>
>As to Terje's assertion that a right shift of greater than word count
>should be zero, I disagree. I take the position that this is really a
>SHIFT operation (signed or otherwise) you use shift
>instructions/operations to move fields of bits around in a container.

Well, yes, but what do you think that it should deliver?  Or should
it interrupt?

>At the language level, a portable language cannot assume that there are
>double width containers.

In a well-designed high-level language, you have arbitrary-width bit
types.

>There are no good answers here, but since the world is devolving into 3
>architectures, it maters less these days than back when the count was
>approaching 20 (all different).

Eh?  You know better than that!  Consistency between the mathematics (or
at least logical design) of a program and the code is one key to
reliable software.  Doing something crazy with large shifts breaks that.
Define the wrong behaviour is the IEEE 754 and Java error.


Regards,
Nick Maclaren.

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

#4068 — The word is devolving into 3 architectures (NOT?)

On 10/7/2011 12:49 PM, MitchAlsup wrote:
> since the world is devolving into 3 architecture

x86
ARM
what's the third?
IBM Power?

I think that x86 may have already lost to ARM.
And I wouldn't count SPARC out, given Oracle
and Larry Ellison's apparent strategy.

I differ (I don't beg (or at least am not good at begging)):
I think the arrival, finally, of
(I never know what to call them)
dynamic/interpretive/whatever
languages like Javascript and Java
and open/CL and ...
has opened a window for other architectures.

Similarly, the advent of cloud services will reduce the barriers to 
entry. In the old world you had to do a heck of a lot to be worth 
consideration. Now, if you can deliver a benefit to a narrow but 
important market niche, a big cloud provider may be willing to buy your 
systems just for that purpose.

Utility computing means professional sysadmin. Now management might try 
to minimize labor costs, but if cost of equipment and operation (power) 
matters, professional sysadmin can optimize.  The bigger the datacenter, 
the more impact sysadmin can have.

(Can you tell I used to be a sysadmin?)

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

#4069 — Re: The word is devolving into 3 architectures (NOT?)

Andy \"Krazy\" Glew wrote:
> 
> On 10/7/2011 12:49 PM, MitchAlsup wrote:
> > since the world is devolving into 3 architecture
> 
> x86
> ARM
> what's the third?

8051

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

#4070 — Re: The word is devolving into 3 architectures (NOT?)

I also keep my eye on CUDA (4) and it's PTX ;)

Bye,
  Skybuck :)

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

#4088 — Re: The word is devolving into 3 architectures (NOT?)

"Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> writes:
>I differ (I don't beg (or at least am not good at begging)):
>I think the arrival, finally, of
>(I never know what to call them)
>dynamic/interpretive/whatever
>languages like Javascript and Java
>and open/CL and ...
>has opened a window for other architectures.

One might think so.  One might also think that the high portability of
free software opens a window for other architectures there, too.  But
in practice OSs and applications are not the only factor.  There are
many components involved, and the network effect favours dominant
things everywhere, so IA-32 and AMD64 are very dominant in the Linux
world, too.  And therefore, I doubt that architecture-neutral code
distribution formats like .class or .js files will make much of a
difference.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

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

#4078

MitchAlsup wrote:
> As to Terje's assertion that a right shift of greater than word count
> should be zero, I disagree. I take the position that this is really a
> SHIFT operation (signed or otherwise) you use shift
> instructions/operations to move fields of bits around in a container.
> At the language level, a portable language cannot assume that there
> are double width containers. There are no good answers here, but
> since the world is devolving into 3 architectures, it maters less
> these days than back when the count was approaching 20 (all
> different).

What about the principle of least astonishment?

Most beginners would expect any shift of N bits to behave the same as N 
iterations of a single shift, or the sum of two shifts with a combined 
count of N.

Both of these break badly in the face of masked counts.

Terje

PS.I do like the combined shift/width instructions you devised!

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

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

#4090

On Saturday, October 8, 2011 3:47:23 AM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > As to Terje's assertion that a right shift of greater than word count
> > should be zero, I disagree. I take the position that this is really a
> > SHIFT operation (signed or otherwise) you use shift
> > instructions/operations to move fields of bits around in a container.
> > At the language level, a portable language cannot assume that there
> > are double width containers. There are no good answers here, but
> > since the world is devolving into 3 architectures, it maters less
> > these days than back when the count was approaching 20 (all
> > different).
> 
> What about the principle of least astonishment?

Its good at the language level, its is not a good paradigm for creating and documenting instructions; similar to languages that define certain operations that have to be synthesized byt the compiler as a series of instructions.

While we are down here in the valley of least astonishment: does it surprise anyone that a shift by 0 in x86 does not result in the condition codes being set? Of course it does, whereas DIVIDE by 1 DOES set the condition codes.

> Most beginners would expect any shift of N bits to behave the same as N 
> iterations of a single shift, or the sum of two shifts with a combined 
> count of N.

Note that on VAX, performing 32 (or more) 1-bit shifts on a register (or memory) results in what the programmer expected, but performinig a 32-bit shift on a register (or memory) results in an exception! Talk about the suprise coefficient!

An arithmetic right shift of -1 yeilds -1 for any number of shifts either as one operation or as a loop of operations; whereas -1 / 2 = 0. Thus ASR is not a cousin to integer divide by power of 2.

> Both of these break badly in the face of masked counts.

Here, I disagree, not with the assertion, but with the conclusion. You are basically asking to define something that was explicitly undefined at the instruction level. Languages can do this, and languages that do define these things tend to run slowly as the compiler has to synthsize the language requirement as series of actually vavilable instructions.

Mitch

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

#4107

MitchAlsup wrote:
>> Both of these break badly in the face of masked counts.
>
> Here, I disagree, not with the assertion, but with the conclusion.
> You are basically asking to define something that was explicitly
> undefined at the instruction level. Languages can do this, and
> languages that do define these things tend to run slowly as the
> compiler has to synthsize the language requirement as series of
> actually vavilable instructions.

Mitch, I don't think we really disagree, I do understand that every 
single instruction should and must be evaluated against how much it will 
cost to implement it vs what kind of speedups it can provide to actual code.

What I'm really interested in here is

How much more expensive is it to provide saturate_at_32 shift counts 
instead of mask_by_31?

I have also noticed that among the latest x86 opcode extensions I can 
find shifts and rotates that don't modify any flags, as well as 
mask-based extract/deposit.

The latter can of course also be used as a very power-hungry way to 
implement any desired shift (but not rotate).

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

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

#4119

On Sunday, October 9, 2011 1:07:33 AM UTC-5, Terje Mathisen wrote:
> What I'm really interested in here is
> 
> How much more expensive is it to provide saturate_at_32 shift counts 
> instead of mask_by_31?

In the case where you have plenty of opcode space to fill up with on-off instructions, the expense is not enough to worry about. In the case where you are already full on opcode space, a lot. This was the case with the 88K, we could not afford the powerful bit-field instructions AND regular shift instructions. We choose to go with the more powerful versions and also to make them available through the shift operators in high level languages.

The 15-30 gates it takes to do saturate-32 versus mask 31 is inconsequential compared to the 1000 gates it takes to do the shifter itself.

> I have also noticed that among the latest x86 opcode extensions I can 
> find shifts and rotates that don't modify any flags, as well as 
> mask-based extract/deposit.

Right, MMX/SSE,... go aout of their way to avoid modifications to a condition code. Whereas I wish we could go back and change the x85 and x86 progenetors.

Mitch

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

#4124

MitchAlsup wrote:
> On Sunday, October 9, 2011 1:07:33 AM UTC-5, Terje Mathisen wrote:
>> What I'm really interested in here is
>>
>> How much more expensive is it to provide saturate_at_32 shift
>> counts instead of mask_by_31?
>
> In the case where you have plenty of opcode space to fill up with
> on-off instructions, the expense is not enough to worry about. In the
> case where you are already full on opcode space, a lot. This was the
> case with the 88K, we could not afford the powerful bit-field
> instructions AND regular shift instructions. We choose to go with the
> more powerful versions and also to make them available through the
> shift operators in high level languages.
>
> The 15-30 gates it takes to do saturate-32 versus mask 31 is
> inconsequential compared to the 1000 gates it takes to do the shifter
> itself.

OK, that was the crucial part of my question!

This means that if the original x86 implementors had simply extended the
mask size from 31 to 63 during the 286->386 transition, it would have
been effectively free.

(It seems to me that having a 63 mask is _very_ _slightly_ cheaper than
a saturate_at_32, because the hw only has to look at a single bit
position (32) instead of OR'ing together the upper bits (32,64,128).)

No crying over spilt milk, right?

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

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

#4126

In article <n5iam8-9pn1.ln1@ntp6.tmsw.no>, "terje.mathisenattmsw.no" says...
>
>MitchAlsup wrote:
>> On Sunday, October 9, 2011 1:07:33 AM UTC-5, Terje Mathisen wrote:
>>> What I'm really interested in here is
>>>
>>> How much more expensive is it to provide saturate_at_32 shift
>>> counts instead of mask_by_31?
>>
>> In the case where you have plenty of opcode space to fill up with
>> on-off instructions, the expense is not enough to worry about. In the
>> case where you are already full on opcode space, a lot. This was the
>> case with the 88K, we could not afford the powerful bit-field
>> instructions AND regular shift instructions. We choose to go with the
>> more powerful versions and also to make them available through the
>> shift operators in high level languages.
>>
>> The 15-30 gates it takes to do saturate-32 versus mask 31 is
>> inconsequential compared to the 1000 gates it takes to do the shifter
>> itself.
>
>OK, that was the crucial part of my question!
>
>This means that if the original x86 implementors had simply extended the
>mask size from 31 to 63 during the 286->386 transition, it would have
>been effectively free.
>
>(It seems to me that having a 63 mask is _very_ _slightly_ cheaper than
>a saturate_at_32, because the hw only has to look at a single bit
>position (32) instead of OR'ing together the upper bits (32,64,128).)
>
>No crying over spilt milk, right?
>

Well, no, what if CL = 65?

Yes, Haswell (or is it Ivy Bridge?) has GP register shift instructions that 
don't modify the flags.  The instruction I wish Intel would include in 
Haswell is the Packed Rotate that is in AMD's BD2 XOP set.

BTW, Burroughs B5000 started with the Bitfield extract/insert (and no shifts) 
in the mid-60's.  The 88000 was neat, but it was late to the party (they 
really should have architected 64 bits).

And to reply to another sub-thread, I think MIPS is still hanging on in lots 
of embedded applications, especially, for some reason, security.

		- Tim

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

#4127

Tim McCaffrey wrote:
> In article<n5iam8-9pn1.ln1@ntp6.tmsw.no>, "terje.mathisenattmsw.no" says...
>> (It seems to me that having a 63 mask is _very_ _slightly_ cheaper than
>> a saturate_at_32, because the hw only has to look at a single bit
>> position (32) instead of OR'ing together the upper bits (32,64,128).)
>>
>> No crying over spilt milk, right?
>
> Well, no, what if CL = 65?

With masking that gives you a count of 1, saturation gives you 32.

With 64-bit regs the mask should not be lower than 127, at which point 
the hw will almost certainly saturate the count at 64 anyway.
>
> Yes, Haswell (or is it Ivy Bridge?) has GP register shift instructions that
> don't modify the flags.  The instruction I wish Intel would include in
> Haswell is the Packed Rotate that is in AMD's BD2 XOP set.

Hmmm, I haven't seen that one...

OK, VPROT[B/W/D/Q] does vector rotates of 8/16/32/64 bit elements, 
without specifying the direction! Left or right?

Since the amounts are specified in another source register, either 0-255 
or -128 to 127, the direction isn't critical as long as it is specified 
somewhere!

For the corresponding shift instructions there's the same problem: Only 
two instructions (logical/arithmetic shifts) with no explicit direction.

This probably indicates that the shift count can indeed be negative, but 
is it positive or negative counts for left shifts?

> And to reply to another sub-thread, I think MIPS is still hanging on in lots
> of embedded applications, especially, for some reason, security.

I seem to remember something about military/space hardened versions of 
MIPS, those might be interesting for security vendors as well.

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

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

#4131

In article <28ibm8-6uo1.ln1@ntp6.tmsw.no>, "terje.mathisenattmsw.no" says...
>
>Tim McCaffrey wrote:
>> In article<n5iam8-9pn1.ln1@ntp6.tmsw.no>, "terje.mathisenattmsw.no" 
says...
>>> (It seems to me that having a 63 mask is _very_ _slightly_ cheaper than
>>> a saturate_at_32, because the hw only has to look at a single bit
>>> position (32) instead of OR'ing together the upper bits (32,64,128).)
>>>
>>> No crying over spilt milk, right?
>>
>> Well, no, what if CL = 65?
>
>With masking that gives you a count of 1, saturation gives you 32.
>
>With 64-bit regs the mask should not be lower than 127, at which point 
>the hw will almost certainly saturate the count at 64 anyway.

Well, I'm thinking of this from a more generic model, where the saturation 
would be correct in all cases, and masking a bigger number would be correct 
in only the "closer to boundary" conditions.

What if your definition of shift (not C's definition) says you need to 
implement saturation? (For some algorithmic reason).  Then no matter how big 
the mask is, it is still a mask and you have to add an explicit check into 
your code to do the saturate check (even only using CL (instead of ECX/RCX) 
is a possible problem.

Well, doesn't matter, nobody is going to change the instruction set now...

>>
>> Yes, Haswell (or is it Ivy Bridge?) has GP register shift instructions 
that
>> don't modify the flags.  The instruction I wish Intel would include in
>> Haswell is the Packed Rotate that is in AMD's BD2 XOP set.
>
>Hmmm, I haven't seen that one...
>
>OK, VPROT[B/W/D/Q] does vector rotates of 8/16/32/64 bit elements, 
>without specifying the direction! Left or right?
<snip>
I don't know, but hopefully if it sees the light of day it will be obvious :)

The fact that it exists lets me get rid of possibly 4 instructions per usage 
(and free a register) vs. SSE3. (2 instructions for AVX).


		- Tim

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch

csiph-web