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 1 of 3  [1] 2 3  Next page →

#4049 — Q: bit shifting

This is an ignorant's question: I remember having long ago read in
a manual of a certain now non-existant hardware that a command to
do bit shifts by an amount n (the hardware had word size of n bits)
was undefined, i.e. the amount being shifted must be less than n.
Could such ever be the case for the modern hardware?

Thanks in advance.

M. K. Shen

[toc] | [next] | [standalone]

#4051

In article <j6mnv4$8rt$1@news.albasani.net>,
Mok-Kong Shen  <mok-kong.shen@t-online.de> wrote:
>
>This is an ignorant's question: I remember having long ago read in
>a manual of a certain now non-existant hardware that a command to
>do bit shifts by an amount n (the hardware had word size of n bits)
>was undefined, i.e. the amount being shifted must be less than n.
>Could such ever be the case for the modern hardware?

In general, it is defined - but insanely!  The reason that shifts
of above the word size are treated like that is because it saved
a few gates, which was important on discrete-logic computers.
Despite that, the ICL 1900 range (mid-1960s) got it right.

Even more ridiculously, it is undefined in almost all programming
languages for that reason, despite the fact that it has been trivial
to fix up since the advent of modern compiler technology (mid-1970s).

So, effectively, the answer is yes.


Regards,
Nick Maclaren.

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

#4056

nmm1@cam.ac.uk wrote:
> In article<j6mnv4$8rt$1@news.albasani.net>,
> Mok-Kong Shen<mok-kong.shen@t-online.de>  wrote:
>>
>> This is an ignorant's question: I remember having long ago read in
>> a manual of a certain now non-existant hardware that a command to
>> do bit shifts by an amount n (the hardware had word size of n bits)
>> was undefined, i.e. the amount being shifted must be less than n.
>> Could such ever be the case for the modern hardware?
>
> In general, it is defined - but insanely!  The reason that shifts
> of above the word size are treated like that is because it saved
> a few gates, which was important on discrete-logic computers.
> Despite that, the ICL 1900 range (mid-1960s) got it right.
>
> Even more ridiculously, it is undefined in almost all programming
> languages for that reason, despite the fact that it has been trivial
> to fix up since the advent of modern compiler technology (mid-1970s).

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...

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

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

#4058

On 10/7/2011 8:35 AM, Terje Mathisen wrote:

snip

> 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.


You're right, of course.  But look at the asymmetry.  If you keep 
dividing a positive number by 2, in the limit, it reaches zero.  But for 
a negative number, the same operation reaches -1!  I guess that is, 
perhaps the only, advantage of ones complement arithmetic.  :-)


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#4059

In article <j6n9ij$ud2$1@dont-email.me>,
Stephen Fuld  <SFuld@Alumni.cmu.edu.invalid> wrote:
>On 10/7/2011 8:35 AM, Terje Mathisen wrote:
>
>> 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.
>
>You're right, of course.  But look at the asymmetry.  If you keep 
>dividing a positive number by 2, in the limit, it reaches zero.  But for 
>a negative number, the same operation reaches -1!  I guess that is, 
>perhaps the only, advantage of ones complement arithmetic.  :-)

Eh?  Despite the fact that there is an equivalence for positive
integers, shifts are NOT multiplication and division by two.
All we are talking about here is the ridiculous masking of the
shift count.


Regards,
Nick Maclaren.

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

#4073

On 10/7/2011 9:16 AM, nmm1@cam.ac.uk wrote:
> In article<j6n9ij$ud2$1@dont-email.me>,
> Stephen Fuld<SFuld@Alumni.cmu.edu.invalid>  wrote:
>> On 10/7/2011 8:35 AM, Terje Mathisen wrote:
>>
>>> 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.
>>
>> You're right, of course.  But look at the asymmetry.  If you keep
>> dividing a positive number by 2, in the limit, it reaches zero.  But for
>> a negative number, the same operation reaches -1!  I guess that is,
>> perhaps the only, advantage of ones complement arithmetic.  :-)
>
> Eh?  Despite the fact that there is an equivalence for positive
> integers, shifts are NOT multiplication and division by two.

Two points.  First, I was mostly being slightly light hearted - 
especially with my reference to ones complement arithmetic.  Second, 
while I certainly defer to your knowledge of mathematics, if shifts are 
not meant to be used as quicker multiply/divide by powers of two, then 
why is there typically a separate instruction for algebraic (i.e. sigh 
preserving) right shifts, than logical right shifts.


> All we are talking about here is the ridiculous masking of the
> shift count.

Sure.  But thread drift is typical.  :-)


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#4079

In article <j6opn1$lpa$1@dont-email.me>,
Stephen Fuld  <SFuld@Alumni.cmu.edu.invalid> wrote:
>
>Two points.  First, I was mostly being slightly light hearted - 
>especially with my reference to ones complement arithmetic.

Yes, I got that!

>Second, 
>while I certainly defer to your knowledge of mathematics, if shifts are 
>not meant to be used as quicker multiply/divide by powers of two, then 
>why is there typically a separate instruction for algebraic (i.e. sigh 
>preserving) right shifts, than logical right shifts.

This is the serious point, and is a very good question.  One answer
is that using right logical shifts on negative numbers makes no
sense in terms any sane programmer can understand.  Another answer
is that left shifts do make sense and it is felt unreasonable to
make right shifts fault if the operand is negative.

But the real answer is the dead hand of history :-)

Back in the days before someone went up a mountain and was told
that the One True Direction for division was towards zero, there
WERE systems where integer division by a power of two was the same
as right shifting.  And, on those systems, it makes perfect sense.
Also, even if they didn't, division was death on performance, so
having even an anomalous alternative could make a major difference.


Regards,
Nick Maclaren.

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

#4096

On Sat, 08 Oct 2011 09:56:42 +0100, nmm1 wrote:
> Back in the days before someone went up a mountain and was told that the
> One True Direction for division was towards zero, there WERE systems
> where integer division by a power of two was the same as right shifting.

Right shifting signed quantities *is* division by powers of two, with 
truncation towards negative infinity.  This is exactly what you want as 
the basis for division by powers of two with round to nearest, because 
you don't have to muck about with sign testing and differently-signed 
rounding biases: just add half the power of two before the shift and 
you're done (neglecting overflow.)

Of course, right-thinking people only ever want round-to-nearest ;-)

Cheers,

-- 
Andrew

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

#4140

In article <j6p38a$dn7$1@gosset.csi.cam.ac.uk>, nmm1@cam.ac.uk says...
>

>
>This is the serious point, and is a very good question.  One answer
>is that using right logical shifts on negative numbers makes no
>sense in terms any sane programmer can understand.  Another answer
>is that left shifts do make sense and it is felt unreasonable to
>make right shifts fault if the operand is negative.
>

Well, right shifts are good for sign extending a signed bitfield:

;
;	signed Bit field in bits 2..5
;
;	
	SHL	EAX,27
	SAR	EAX,29		;Signed bitfield value in EAX

They are also good for a mask based on the sign bit.

Interestingly, the CDC 6000 series only had a signed right shift, and a left 
rotate.  No shift left.  It was probably faster to do a multiply.

		- Tim

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

#4213

Tim McCaffrey <timcaffrey@aol.com> wrote:

> Interestingly, the CDC 6000 series only had a signed right shift, and a left 
> rotate.  No shift left.  It was probably faster to do a multiply.

On a 1's complement machine like the CDC 6000, left rotate multiplies by
2**n.

Sean Case

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

#4271

In article <1018831712340453853.246553seancase-tpg.com.au@news.tpg.com.au>, 
seancase@tpg.com.au says...
>
>Tim McCaffrey <timcaffrey@aol.com> wrote:
>
>> Interestingly, the CDC 6000 series only had a signed right shift, and a 
left 
>> rotate.  No shift left.  It was probably faster to do a multiply.
>
>On a 1's complement machine like the CDC 6000, left rotate multiplies by
>2**n.
>
>Sean Case

Well, if the most significant bit that doesn't match the sign bit isn't 
rotated into the low bits (or into the sign bit).

	- Tim

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

#4060

On Fri, 07 Oct 2011 17:35:42 +0200, Terje Mathisen <"terje.mathisen at
tmsw.no"> wrote:

>nmm1@cam.ac.uk wrote:
>> In article<j6mnv4$8rt$1@news.albasani.net>,
>> Mok-Kong Shen<mok-kong.shen@t-online.de>  wrote:
>>>
>>> This is an ignorant's question: I remember having long ago read in
>>> a manual of a certain now non-existant hardware that a command to
>>> do bit shifts by an amount n (the hardware had word size of n bits)
>>> was undefined, i.e. the amount being shifted must be less than n.
>>> Could such ever be the case for the modern hardware?
>>
>> In general, it is defined - but insanely!  The reason that shifts
>> of above the word size are treated like that is because it saved
>> a few gates, which was important on discrete-logic computers.
>> Despite that, the ICL 1900 range (mid-1960s) got it right.
>>
>> Even more ridiculously, it is undefined in almost all programming
>> languages for that reason, despite the fact that it has been trivial
>> to fix up since the advent of modern compiler technology (mid-1970s).
>
>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...


Next you guys are going to want negative shift counts to be meaningful
too!  *sheesh*

But seriously, yeah, it's a real PITA at times, but it's been a common
approach forever - even S/360 used the mask approach, although they at
least used 6 bits for the count (so you could shift the 32 bit
register as many as 63 positions).  Somewhat perversely, they kept the
6 bit mask for the double wide shifts added on S/370, *and* stuck with
6 bit masks with the 64 bit extensions on zArch.

And as Nick said, one of the saddest things is that weirdness has made
it into a number of languages.

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

#4061

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Fri, 07 Oct 2011 17:35:42 +0200, Terje Mathisen <"terje.mathisen at
> tmsw.no"> wrote:
>
>>nmm1@cam.ac.uk wrote:
>>> In article<j6mnv4$8rt$1@news.albasani.net>,
>>> Mok-Kong Shen<mok-kong.shen@t-online.de>  wrote:
>>>>
>>>> This is an ignorant's question: I remember having long ago read in
>>>> a manual of a certain now non-existant hardware that a command to
>>>> do bit shifts by an amount n (the hardware had word size of n bits)
>>>> was undefined, i.e. the amount being shifted must be less than n.
>>>> Could such ever be the case for the modern hardware?
>>>
>>> In general, it is defined - but insanely!  The reason that shifts
>>> of above the word size are treated like that is because it saved
>>> a few gates, which was important on discrete-logic computers.
>>> Despite that, the ICL 1900 range (mid-1960s) got it right.
>>>
>>> Even more ridiculously, it is undefined in almost all programming
>>> languages for that reason, despite the fact that it has been trivial
>>> to fix up since the advent of modern compiler technology (mid-1970s).
>>
>>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...
>
>
> Next you guys are going to want negative shift counts to be meaningful
> too!  *sheesh*

Of course - you can't a priori know the sign of a computed value, so
negative shift amounts must be a shift in the opposite direction.

We do this on our DSP.

Oh, and shifting with >=wordsize returns 0/-1 too :-)

Kai
-- 
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

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

#4077

Kai Harrekilde-Petersen wrote:
> Robert Wessel<robertwessel2@yahoo.com>  writes:
>
>> On Fri, 07 Oct 2011 17:35:42 +0200, Terje Mathisen<"terje.mathisen at
>>> 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...
>>
>>
>> Next you guys are going to want negative shift counts to be meaningful
>> too!  *sheesh*
>
> Of course - you can't a priori know the sign of a computed value, so
> negative shift amounts must be a shift in the opposite direction.
>
> We do this on our DSP.
>
> Oh, and shifting with>=wordsize returns 0/-1 too :-)

So basically your shifter would have simplified quite a few bit 
twiddling algorithms I have implemented over the years.

BTW, I believe Intel exactly repeated IBM's mistakes, in that they 
implemented the 5-bit mask (i.e. shifts of 0-31 bits) back in the 16-bit 
days, then failed to increase it for the 32-bit extension, making it 
_much_ more painful.

Particularly since that 5-bit limit is even enforced for the double-wide 
(i.e. 64-bit source) shifts. :-(

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

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

#4080

Terje Mathisen <"terje.mathisen at tmsw.no"> writes:

> Kai Harrekilde-Petersen wrote:
>> Robert Wessel<robertwessel2@yahoo.com>  writes:
>>
>>> On Fri, 07 Oct 2011 17:35:42 +0200, Terje Mathisen<"terje.mathisen at
>>>> 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...
>>>
>>>
>>> Next you guys are going to want negative shift counts to be meaningful
>>> too!  *sheesh*
>>
>> Of course - you can't a priori know the sign of a computed value, so
>> negative shift amounts must be a shift in the opposite direction.
>>
>> We do this on our DSP.
>>
>> Oh, and shifting with>=wordsize returns 0/-1 too :-)
>
> So basically your shifter would have simplified quite a few bit
> twiddling algorithms I have implemented over the years.

I can imagine.  But our choices have come out of necessity - to
paraphrase Monty Python: "Every Clock Cycle Is Sacred" in our hearing
aid application.

For power and performance reasons, the DSP is a VLIW/"brainiac" typish
processor, so cramming as much processing into each cycle is important.
Since the complexity of detecting shift direction etc isn't that big, we
chose to add this directly into the instructions instead of having the
programmer to use 10-ish instructions to do the same (memory is tight
too).

Personally, I'd question whether you'd actually *liked* programming the
DSP.  The instruction set isn't exactly orthogonal, but then again you
can do 1-cycle/tap in a FIR filter.  Try that on an x86 or ARM ;-)

Kai
-- 
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

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

#4097

On Sat, 08 Oct 2011 11:28:32 +0200, Kai Harrekilde-Petersen wrote:
> Personally, I'd question whether you'd actually *liked* programming the
> DSP.  The instruction set isn't exactly orthogonal, but then again you
> can do 1-cycle/tap in a FIR filter.  Try that on an x86 or ARM ;-)

Even without going to FFT-based methods, it's not *that* hard to get an 
FIR down to about 1.25 cycles/tap on an ARM, just using the scalar v5TE 
instruction set, so the penalty is not as large as you might think.  You 
can do better with the SIMD features of the newer instruction sets.  Of 
course, it isn't pretty, and not much fun.  I expect that the newer parts 
that have dual issue (so you don't get a pipeline hit for the read and 
write instructions) would be better, but they also usually have NEON SIMD 
extensions too...

Cheers,

-- 
Andrew

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

#4103

On Sat, 08 Oct 2011 10:41:41 +0200, Terje Mathisen <"terje.mathisen at
tmsw.no"> wrote:

>Kai Harrekilde-Petersen wrote:
>> Robert Wessel<robertwessel2@yahoo.com>  writes:
>>
>>> On Fri, 07 Oct 2011 17:35:42 +0200, Terje Mathisen<"terje.mathisen at
>>>> 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...
>>>
>>>
>>> Next you guys are going to want negative shift counts to be meaningful
>>> too!  *sheesh*
>>
>> Of course - you can't a priori know the sign of a computed value, so
>> negative shift amounts must be a shift in the opposite direction.
>>
>> We do this on our DSP.
>>
>> Oh, and shifting with>=wordsize returns 0/-1 too :-)
>
>So basically your shifter would have simplified quite a few bit 
>twiddling algorithms I have implemented over the years.
>
>BTW, I believe Intel exactly repeated IBM's mistakes, in that they 
>implemented the 5-bit mask (i.e. shifts of 0-31 bits) back in the 16-bit 
>days, then failed to increase it for the 32-bit extension, making it 
>_much_ more painful.


Now that you've reminded me of that, I think the history was even more
convoluted.  I think the 8086/8 didn't mask the shift count (in CL) at
all.  The five bit mask was added on the 286, and then not extended on
the 386.  In 2011, one tends to forget about x86 16 bit mode...


>Particularly since that 5-bit limit is even enforced for the double-wide 
>(i.e. 64-bit source) shifts. :-(


*Bleech*  That's right.  We've got only a minimal amount of assembler
in the x86-64 versions of things, but that will change over time.  One
of the future tasks on my plate is optimizing some of our internal
bignum library for x86-64.  We're using our (somewhat slow) pure-C
implementation there, and the shift ugliness is certainly going to
have a negative impact on the code there.

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

#4108

Robert Wessel wrote:
> On Sat, 08 Oct 2011 10:41:41 +0200, Terje Mathisen<"terje.mathisen at
>> BTW, I believe Intel exactly repeated IBM's mistakes, in that they
>> implemented the 5-bit mask (i.e. shifts of 0-31 bits) back in the 16-bit
>> days, then failed to increase it for the 32-bit extension, making it
>> _much_ more painful.
>
> Now that you've reminded me of that, I think the history was even more
> convoluted.  I think the 8086/8 didn't mask the shift count (in CL) at
> all.  The five bit mask was added on the 286, and then not extended on
> the 386.  In 2011, one tends to forget about x86 16 bit mode...

This is exactly right, it provided yet another easy way to detect the 
kind of chip (808x or not, I believe the masking was introduced already 
on the 80186, i.e. well before the 286) you were currently running on:

Do a (CL-counted) shift of 32 (or any 0 mod 32 count) and check if the 
result was zero or not.

Terje

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

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

#4265

Am 09.10.2011 05:57, schrieb Robert Wessel:
> On Sat, 08 Oct 2011 10:41:41 +0200, Terje Mathisen<"terje.mathisen at
> tmsw.no">  wrote:

>> Particularly since that 5-bit limit is even enforced for the double-wide
>> (i.e. 64-bit source) shifts. :-(
>
> *Bleech*  That's right.  We've got only a minimal amount of assembler
> in the x86-64 versions of things, but that will change over time.  One
> of the future tasks on my plate is optimizing some of our internal
> bignum library for x86-64.  We're using our (somewhat slow) pure-C
> implementation there, and the shift ugliness is certainly going to
> have a negative impact on the code there.

I learn that there is a C++ Compiler from AMD working for 64 bits. Do
you happen to have experience with that?

M. K. Shen

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

#4152

On Oct 8, 10:41 am, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:
>
> BTW, I believe Intel exactly repeated IBM's mistakes, in that they
> implemented the 5-bit mask (i.e. shifts of 0-31 bits) back in the 16-bit
> days, then failed to increase it for the 32-bit extension, making it
> _much_ more painful.
>
> 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.

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.

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch

csiph-web