On Saturday, January 8, 2022 at 7:54:10 PM UTC-6, EricP wrote:
> MitchAlsup wrote:
> > On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
> >> MitchAlsup wrote:
> >>> On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
> >>>> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
> >>>>
> >>>>> This gets back to the concept that the right hand side of a << or >> operator
> >>>>> needs to be unsigned--as certainly a negative number is simply not portable
> >>>>> there. In effect << and >> are mixed type operators.
> >>> <
> >>>> I'd have to say that's questionable, simply because computers using any
> >>>> representation other than two's complement for integers simply haven't
> >>>> existed for the last several decades.
> >>> <
> >>> So, what does (13 << -7) mean ?
> > <
> >> VAX says it means (13 >> 7)
> > <
> > I happen to be well aware of what VAX said it means.
> > <
> > The question is what should a high level language say it means ?
> What VAX says, of course.
> > And the second question is what should an ISA do when it gets a SL Rd,R13,R-7 ?
> Have you considered VAX compatibility?
<
Yes, I have
<
but what do the 99.999975% of computers out there which do not do it like VAX did do ?

According to MitchAlsup <MitchAlsup@aol.com>:
>> >>> So, what does (13 << -7) mean ?

>but what do the 99.999975% of computers out there which do not do it like VAX did do ?

Um, they do something. I don't think any current computers use a signed shift
count like the VAX did.

IBM zSeries and its predecessors treats the low six bits of the shift
argument as an unsigned integer so (assuming my mental arithmetic is
correct) it'd treat it as a 57 bit left shift.

Intel machines do the same thing, using 5 bits of the shift argument
on 16 or 32 bit operands, six bits for 64 bit opeands.

Squinting at the 8000 page ARM manual, it doesn't have a way to encode
a negative shift count as an immediate value. For a count in a
register, I think it uses the low byte of the register as an unsigned
value, so same result.

Unlesss of course, the compiler helpfully optimized (13 << -7) to (13 >> 7) and
turned it into a constant zero.

I think we can say "Don't Do That."

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 1/8/2022 1:37 PM, MitchAlsup wrote:
> On Saturday, January 8, 2022 at 2:37:50 PM UTC-6, Quadibloc wrote:
>> On Saturday, January 8, 2022 at 10:50:35 AM UTC-7, MitchAlsup wrote:
>>
>>> These rotate a full width register into a full width register by a given
>>> number of bits. no bits are lost, and none gained.
>> Given that, surely they could be referred to as "logical" operations,
>> as distinct from "numerical" operations; that ought to make it
>> sufficiently clear that 'signed' or 'unsigned' are not properly
>> applicable.
> <
> This gets back to the concept that the right hand side of a << or >> operator
> needs to be unsigned--as certainly a negative number is simply not portable
> there. In effect << and >> are mixed type operators.

Or that you have just ROT and the sign of the shift count controls the
direction. Still mixed, just logicalXsigned instead of logicalXunsigned

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
>> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
>>
>> > This gets back to the concept that the right hand side of a << or >> operator
>> > needs to be unsigned--as certainly a negative number is simply not portable
>> > there. In effect << and >> are mixed type operators.
><
>> I'd have to say that's questionable, simply because computers using any
>> representation other than two's complement for integers simply haven't
>> existed for the last several decades.
><
> So, what does (13 << -7) mean ?

Fortran has the ISHFT intrinsic, which takes a signed argument.
Not very well supported by the ISA/compiler combination, as
can be seen from https://godbolt.org/z/xxnxxfzMv .

On 09.01.2022 02:16, MitchAlsup wrote:
> So, what does (13 << -7) mean ?

On 09.01.2022 03:28, MitchAlsup wrote:
>>> The question is what should a high level language say it means ?
>> What VAX says, of course.
>>> And the second question is what should an ISA do when it gets a SL Rd,R13,R-7 ?
>> Have you considered VAX compatibility?
>
> Yes, I have
>
> but what do the 99.999975% of computers out there which do not do it like VAX did do ?

Most CPUs I worked with use shift/rotate amounts modulo their word size,
so on a 64bit CPU:

(13 << -7) would be (13 << (-7 & 63) = (13 << 57).

MitchAlsup wrote:
> On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
>> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
>>
>>> This gets back to the concept that the right hand side of a << or >> operator
>>> needs to be unsigned--as certainly a negative number is simply not portable
>>> there. In effect << and >> are mixed type operators.
> <
>> I'd have to say that's questionable, simply because computers using any
>> representation other than two's complement for integers simply haven't
>> existed for the last several decades.
> <
> So, what does (13 << -7) mean ?

It should have meant "13 >> 7", and has done so on at least one
historical computer, but today it means either 13 << (-7+32) or 13 <<
(-7+64), unless it is caught in the compiler or a runtime check.

Terje

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

Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
>>> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
>>>
>>>> This gets back to the concept that the right hand side of a << or >> operator
>>>> needs to be unsigned--as certainly a negative number is simply not portable
>>>> there. In effect << and >> are mixed type operators.
>> <
>>> I'd have to say that's questionable, simply because computers using any
>>> representation other than two's complement for integers simply haven't
>>> existed for the last several decades.
>> <
>> So, what does (13 << -7) mean ?
>
> Fortran has the ISHFT intrinsic, which takes a signed argument.
> Not very well supported by the ISA/compiler combination, as
> can be seen from https://godbolt.org/z/xxnxxfzMv .
>
Interesting!

So the definition of ISHFT(x,n) is something like "shift x (as an
unsigned value) right the number of bits specified by n. If n is
negative, shift left instead. Any shift count with an absolute value
greater than 31 will return zero."

(I might have gotten the default direction mixed up!?)

If you instead did this using Rotate (in default direction) plus a mask,
then you could have made it a bit faster?

I.e. ROR EAX,CL will always rotate right, but if CL is negative, then -1
corresponds to +31, so it is till doing the right thing, you just need
to figure out which bits to mask away.

Terje

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

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Tim Rentsch wrote:
>
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>
>>> The & and | operators normally act on integral data types [...]
>>
>> Please forgive me for bringing up a technical fine point. The
>> operators & and | normally act on integer data types, not
>> integral data types. (In fact C doesn't have "integral" data
>> types.) The distinction is not just rhetorical: a constant such
>> as 3.0 has an integral value, but it does not have an integer
>> value.
>
> "Integral operands" is the words my MS compiler documentation uses,
> and was the words K&R used for bitwise operators,
> meaning either signed or unsigned integer operands.

Yes, historically the word "integral" was used. In fact it was
used in the original C89/C90 standard. (C++ confuses the issue
by using both "integral" and "integer".) This usage changed in
C99, as you next point out:

> For bitwise operators the C99 standard says
> "Each of the operands shall have integer type"

As part of the effort to update C90 to C99, someone must have
realized that "integral" isn't really the right word in this
context, and changed "integral type" to "integer type". Note
that C standards after C90 do also use the word "integral",
but only in contexts where it refers to values, not types.

> which it does not qualify as signed or unsigned
> and therefore means either.

The C standard defines the term "integer type" to mean not just
signed integers and unsigned integers, but also 'char' which
is neither a signed integer type nor an unsigned integer type,
and also enumeration types, which are a distinct category but
in each case compatible with some signed integer type or unsigned
integer type.

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>> On Saturday, January 8, 2022 at 7:07:03 PM UTC-6, Quadibloc wrote:
>>>> On Saturday, January 8, 2022 at 2:37:27 PM UTC-7, MitchAlsup wrote:
>>>>
>>>>> This gets back to the concept that the right hand side of a << or >> operator
>>>>> needs to be unsigned--as certainly a negative number is simply not portable
>>>>> there. In effect << and >> are mixed type operators.
>>> <
>>>> I'd have to say that's questionable, simply because computers using any
>>>> representation other than two's complement for integers simply haven't
>>>> existed for the last several decades.
>>> <
>>> So, what does (13 << -7) mean ?
>>
>> Fortran has the ISHFT intrinsic, which takes a signed argument.
>> Not very well supported by the ISA/compiler combination, as
>> can be seen from https://godbolt.org/z/xxnxxfzMv .
>>
> Interesting!
>
> So the definition of ISHFT(x,n) is something like "shift x (as an
> unsigned value) right the number of bits specified by n. If n is
> negative, shift left instead. Any shift count with an absolute value
> greater than 31 will return zero."

That is what gfortran implements, the intermediate code generated
by the front end is

__result_shft = ABS_EXPR <D.3875> <= 31 ? D.3875 >= 0 ? D.3874
<< ABS_EXPR <D.3875> : (integer(kind=4)) ((unsigned int)
D.3874 >> ABS_EXPR <D.3875>) : 0;

The actual specification from the standard is

# The result has the value obtained by shifting the bits of I by
# SHIFT positions. If SHIFT is positive, the shift is to the left;
# if SHIFT is negative, the shift is to the right; if SHIFT is zero,
# no shift is performed. Bits shifted out from the left or from
# the right, as appropriate, are lost. Zeros are shifted in from
# the opposite end. The model for the interpretation of an integer
# value as a sequence of bits is in 16.3.

> (I might have gotten the default direction mixed up!?)

I usually do :-)

> If you instead did this using Rotate (in default direction) plus a mask,
> then you could have made it a bit faster?

> I.e. ROR EAX,CL will always rotate right, but if CL is negative, then -1
> corresponds to +31, so it is till doing the right thing, you just need
> to figure out which bits to mask away.

Looks like an optimization which could go into gcc's middle end.
Front end maintainers are strongly discouraged from putting
architecture-specific code into the front end :-)

MitchAlsup wrote:
> On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
>> MitchAlsup wrote:
>>> <
>>> So, what does (13 << -7) mean ?
> <
>> VAX says it means (13 >> 7)
> <
> I happen to be well aware of what VAX said it means.
> <
> The question is what should a high level language say it means ?

This question comes down to how a language design deals with
HW behavior that is inherently ISA dependent.

There is no one definition that
(a) satisfies all or most user functional requirements
(b) maps the single >> operator to one instruction on all or most ISA's
so I don't even try. It is trying to do that which winds up where C is,
riddled with the words "implementation dependent" or worse, "undefined".

What programmers want is a guaranteed functional behavior.
Languages and compilers need defined behavior for operators so they can be
used in static, or constant, expressions and evaluated at compile time.

In my hobby language design, Static Expressions are expressions that are
required by the language to evaluate at compile time. These occur various
places mostly to do with type definitions, like bit field size in a struct.

I define Language Intrinsic Functions (LIF) as a set of *named* integer,
float and string functions that are required by the language to be built
into every compiler and can be used in Static Expressions.

Most type-operator pairs map to a single LIF and most LIF are
implemented by a single instruction on almost all ISA.

Shifts seem to be unique in having many functional specs, all reasonable.
So shifts have multiple named LIF functions and a default mapping
of the << >> and |> operators to specific named LIFs.

The definitions for the shift LIFs would include optional limitations that
allow optimizations, but these are guaranteed and documented behavior
not opaque and implementation dependent.

So to answer your question, passing a shift count that is provably a
natural number to the count arg of *any* shift LIF allows it to
optimize away all the code that dealt with negative counts.
When count is not provably a natural number, then the behavior options
seem to be (a) mask to machine size, (b) reverse direction, or (c) trap.
Since all are good options, all are supported in different LIFs.

In this approach the choice is made by the programmer,
not opaquely the compiler.

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> MitchAlsup wrote:
>> On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
>>> MitchAlsup wrote:
>>>> <
>>>> So, what does (13 << -7) mean ?
>> <
>>> VAX says it means (13 >> 7)
>> <
>> I happen to be well aware of what VAX said it means.
>> <
>> The question is what should a high level language say it means ?
>
> This question comes down to how a language design deals with
> HW behavior that is inherently ISA dependent.

Yep. Ideally, the program should provide an abstraction which is
then mapped onto the hardware, more or less efficiently, as the
case may be.

> There is no one definition that
> (a) satisfies all or most user functional requirements
> (b) maps the single >> operator to one instruction on all or most ISA's
> so I don't even try. It is trying to do that which winds up where C is,
> riddled with the words "implementation dependent" or worse, "undefined".
>
> What programmers want is a guaranteed functional behavior.
> Languages and compilers need defined behavior for operators so they can be
> used in static, or constant, expressions and evaluated at compile time.

Those two points are somewhat orthogonal to each other.

>
> In my hobby language design, Static Expressions are expressions that are
> required by the language to evaluate at compile time. These occur various
> places mostly to do with type definitions, like bit field size in a struct.

Fortran calls these "Constant expressions", but from what I can tell,
they are the same.

> I define Language Intrinsic Functions (LIF) as a set of *named* integer,
> float and string functions that are required by the language to be built
> into every compiler and can be used in Static Expressions.

The terms are a bit different, but the concept certainly sounds familiar
:-) You might want to look at subclause 10.1.12 of
https://j3-fortran.org/doc/year/18/18-007r1.pdf to see how others
have defined this.

Fortran allows you, for example, to declare a constant array
("parameter" is Fortran parlance for what other languages
call a constant)

real, parameter, dimension(*) :: a = [1.,3.,2.,6.]

and then a parameter (aka constant) as

real, parameter :: maxa = maxval(a)

with the intrinsic function maxval, will then be 6.0 in the
example above.

> Most type-operator pairs map to a single LIF and most LIF are
> implemented by a single instruction on almost all ISA.
>
> Shifts seem to be unique in having many functional specs, all reasonable.
> So shifts have multiple named LIF functions and a default mapping
> of the << >> and |> operators to specific named LIFs.
>
> The definitions for the shift LIFs would include optional limitations that
> allow optimizations, but these are guaranteed and documented behavior
> not opaque and implementation dependent.
>
> So to answer your question, passing a shift count that is provably a
> natural number to the count arg of *any* shift LIF allows it to
> optimize away all the code that dealt with negative counts.
> When count is not provably a natural number, then the behavior options
> seem to be (a) mask to machine size, (b) reverse direction, or (c) trap.
> Since all are good options, all are supported in different LIFs.

Why not have a single shift function which covers shifts for
both directions?

Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>>
>> So to answer your question, passing a shift count that is provably a
>> natural number to the count arg of *any* shift LIF allows it to
>> optimize away all the code that dealt with negative counts.
>> When count is not provably a natural number, then the behavior options
>> seem to be (a) mask to machine size, (b) reverse direction, or (c) trap.
>> Since all are good options, all are supported in different LIFs.
>
> Why not have a single shift function which covers shifts for
> both directions?

One could, if one wants to make that decision dynamically,
though the direction of a bit shift is usually
embedded in the algorithm and not decided on the fly.

Note this is not whether there is a run-time routine to do this,
or a compiler has an inline asm expansion for such,
but whether that function can be used in a Static Expression.
A static shift expression would, by definition, have a static value
for the count so the direction would be static.

The decision to support different LIF's is based on commercial
support for particular interpretations, and new definitions can be
added to the language spec if a new interpretation becomes popular.

The difference comes down to implementation on a particular ISA.
"ShiftSignedRightNegativeCount" on VAX expands to a single instruction
while on Intel that expands to an instruction sequence.
"ShiftSignedRightMaskCount" on Intel is a single instruction with implied
mask, but on VAX it expands to ABS, AND, NEG (for right shift), ASH.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>MitchAlsup wrote:
>> On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
>>> MitchAlsup wrote:
>>>> So, what does (13 << -7) mean ?
>> <
>>> VAX says it means (13 >> 7)
>> <
>> I happen to be well aware of what VAX said it means.
>> <
>> The question is what should a high level language say it means ?
>
>What VAX says, of course.

Why?

My experience is that I have programmed with compilers (and machines)
that work differently from the VAX, and have never written any code
where the VAX way would have been better.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> MitchAlsup wrote:
>>> On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
>>>> MitchAlsup wrote:
>>>>> So, what does (13 << -7) mean ?
>>> <
>>>> VAX says it means (13 >> 7)
>>> <
>>> I happen to be well aware of what VAX said it means.
>>> <
>>> The question is what should a high level language say it means ?
>> What VAX says, of course.
>
> Why?
>
> My experience is that I have programmed with compilers (and machines)
> that work differently from the VAX, and have never written any code
> where the VAX way would have been better.
>
> - anton

That had an implied smiley.
Its' function is no better or worse than the others.

Except the VAX possibly trapping left shift - that was just wrong.
If VAX overflow trap flag was enabled then arithmetic left shift
would overflow trap if any bit shifted out was not the same as the sign.
That capability is fine as it emulates a signed multiply with overflow
detect. But an overflow trapping shift should be a separate instruction
rather than enabled/disabled by a status flag because changing the flag
state, shifting, then restoring flag state is a pain in the ass.
(I suspect that is why the C language defines left shift of a
signed integer as "undefined", because on VAX it might trap.
If trapping-shift had been a separate instruction it would
not have been an issue.)

On 1/10/2022 7:00 AM, EricP wrote:
> Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> MitchAlsup wrote:
>>>> On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
>>>>> MitchAlsup wrote:
>>>>>> So, what does (13 << -7) mean ?
>>>> <
>>>>> VAX says it means (13 >> 7)
>>>> <
>>>> I happen to be well aware of what VAX said it means.
>>>> <
>>>> The question is what should a high level language say it means ?
>>> What VAX says, of course.
>>
>> Why?
>>
>> My experience is that I have programmed with compilers (and machines)
>> that work differently from the VAX, and have never written any code
>> where the VAX way would have been better.
>>
>> - anton
>
> That had an implied smiley.
> Its' function is no better or worse than the others.
>
> Except the VAX possibly trapping left shift - that was just wrong.
> If VAX overflow trap flag was enabled then arithmetic left shift
> would overflow trap if any bit shifted out was not the same as the sign.
> That capability is fine as it emulates a signed multiply with overflow
> detect. But an overflow trapping shift should be a separate instruction
> rather than enabled/disabled by a status flag because changing the flag
> state, shifting, then restoring flag state is a pain in the ass.
> (I suspect that is why the C language defines left shift of a
> signed integer as "undefined", because on VAX it might trap.
> If trapping-shift had been a separate instruction it would
> not have been an issue.)

FWIW, Mill left shift supports all four overflow behaviors (modulo,
exception, saturation, widen) just like add and regular multiply. And
Mill right shift supports all rounding modes, so you have true signed
divide available, which it is not on an ISA with the usual -1 >> 1 -> -1.

This doesn't cost much - you have a rounding shifter available already
if you support FP, and the overflow logic is already there for the ALU
anyway. As for encoding, it adds seven models to an ISA set with over a
thousand, a trivial entropy increase.

> So, what does (13 << -7) mean ?

I suspect everyone in this group knows what the above means in
C according to the C standard, but if you're asking what we think it
should mean instead (either in C or in other languages), then my answer
is that it should mean the same as (13 >> 7) because it's the most
intuitive behavior, and the cleanest semantics.

Stefan

On Saturday, January 8, 2022 at 6:16:14 PM UTC-7, MitchAlsup wrote:

> So, what does (13 << -7) mean ?

From the replies, I see that this is a completely different
can of worms. I would tend to favor the VAX interpretation,
but it's unclear to me that it would be worth the extra
run-time overhead that it might imply.

John Savard

On Monday, January 10, 2022 at 9:01:01 AM UTC-6, EricP wrote:
> Anton Ertl wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> >> MitchAlsup wrote:
> >>> On Saturday, January 8, 2022 at 7:26:37 PM UTC-6, EricP wrote:
> >>>> MitchAlsup wrote:
> >>>>> So, what does (13 << -7) mean ?
> >>> <
> >>>> VAX says it means (13 >> 7)
> >>> <
> >>> I happen to be well aware of what VAX said it means.
> >>> <
> >>> The question is what should a high level language say it means ?
> >> What VAX says, of course.
> >
> > Why?
> >
> > My experience is that I have programmed with compilers (and machines)
> > that work differently from the VAX, and have never written any code
> > where the VAX way would have been better.
> >
> > - anton
> That had an implied smiley.
> Its' function is no better or worse than the others.
>
> Except the VAX possibly trapping left shift - that was just wrong.
> If VAX overflow trap flag was enabled then arithmetic left shift
> would overflow trap if any bit shifted out was not the same as the sign.
> That capability is fine as it emulates a signed multiply with overflow
> detect. But an overflow trapping shift should be a separate instruction
> rather than enabled/disabled by a status flag because changing the flag
> state, shifting, then restoring flag state is a pain in the ass.
> (I suspect that is why the C language defines left shift of a
> signed integer as "undefined", because on VAX it might trap.
> If trapping-shift had been a separate instruction it would
> not have been an issue.)
<
VAX overflow detecting was very unkind to code such as:
<
for( i = 1, i ; i << 1 )
<
ran 32 loops and then takes a trap instead of terminating the loop.

According to Stefan Monnier <monnier@iro.umontreal.ca>:
>> So, what does (13 << -7) mean ?
>
>I suspect everyone in this group knows what the above means in
>C according to the C standard, but if you're asking what we think it
>should mean instead (either in C or in other languages), then my answer
>is that it should mean the same as (13 >> 7) because it's the most
>intuitive behavior, and the cleanest semantics.

Intuitive is in the mind of the beholder, and in my mind, if you
want to shift right, you should say so.

I'd rather say that shifts are only defined for values between zero
and the word size, which excludes all negative values.

What's the result of (13 << N) where N is an argument that might
have a negative value? On computers that treat a variable shift
argument as an unsigned number (all of them these days) does the
computer have to generate code to test the sign of N and so forth?

The VAX designers outsmarted themselves (not the only time) when
they had one shift instruction with a signed argument rather than
separate left and right shifts. I can't think of a time I've
done shifting and didn't know when I wrote the code which direction
I wanted to shift, even if the number of shifts was variable.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Monday, January 10, 2022 at 3:03:39 PM UTC-6, John Levine wrote:
> According to Stefan Monnier <mon...@iro.umontreal.ca>:
> >> So, what does (13 << -7) mean ?
> >
> >I suspect everyone in this group knows what the above means in
> >C according to the C standard, but if you're asking what we think it
> >should mean instead (either in C or in other languages), then my answer
> >is that it should mean the same as (13 >> 7) because it's the most
> >intuitive behavior, and the cleanest semantics.
<
> Intuitive is in the mind of the beholder, and in my mind, if you
> want to shift right, you should say so.
>
> I'd rather say that shifts are only defined for values between zero
> and the word size, which excludes all negative values.
<
AND THUS: the right side operand SHOULD be unsigned !!!
<
>
> What's the result of (13 << N) where N is an argument that might
> have a negative value? On computers that treat a variable shift
> argument as an unsigned number (all of them these days) does the
> computer have to generate code to test the sign of N and so forth?
<
s/computer/compiler/
<
>
> The VAX designers outsmarted themselves (not the only time) when
> they had one shift instruction with a signed argument rather than
> separate left and right shifts. I can't think of a time I've
> done shifting and didn't know when I wrote the code which direction
> I wanted to shift, even if the number of shifts was variable.
<
Unlike and ADD, SUB,... one has a direction in mind when one uses a shift
operator.
<
Consider an ADD instruction where one has a parameter to perform the
carry from the bottom to the top or vice versa (FFT indexing uses the
versa part). Would you want a 3rd parameter to the ADD instruction to
specify the direction of carry ???
<
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On 1/10/2022 1:03 PM, John Levine wrote:
> According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>> So, what does (13 << -7) mean ?
>>
>> I suspect everyone in this group knows what the above means in
>> C according to the C standard, but if you're asking what we think it
>> should mean instead (either in C or in other languages), then my answer
>> is that it should mean the same as (13 >> 7) because it's the most
>> intuitive behavior, and the cleanest semantics.
>
> Intuitive is in the mind of the beholder, and in my mind, if you
> want to shift right, you should say so.
>
> I'd rather say that shifts are only defined for values between zero
> and the word size, which excludes all negative values.
>
> What's the result of (13 << N) where N is an argument that might
> have a negative value? On computers that treat a variable shift
> argument as an unsigned number (all of them these days) does the
> computer have to generate code to test the sign of N and so forth?
>
> The VAX designers outsmarted themselves (not the only time) when
> they had one shift instruction with a signed argument rather than
> separate left and right shifts. I can't think of a time I've
> done shifting and didn't know when I wrote the code which direction
> I wanted to shift, even if the number of shifts was variable.
>

Perhaps VAX followed the semantics of ADD? After all, 13 + -7 is 6, not
some very large number - so there is really no reason for SUB to be in
the ISA.

On Monday, January 10, 2022 at 3:53:20 PM UTC-6, Ivan Godard wrote:
> On 1/10/2022 1:03 PM, John Levine wrote:
> > According to Stefan Monnier <mon...@iro.umontreal.ca>:
> >>> So, what does (13 << -7) mean ?
> >>
> >> I suspect everyone in this group knows what the above means in
> >> C according to the C standard, but if you're asking what we think it
> >> should mean instead (either in C or in other languages), then my answer
> >> is that it should mean the same as (13 >> 7) because it's the most
> >> intuitive behavior, and the cleanest semantics.
> >
> > Intuitive is in the mind of the beholder, and in my mind, if you
> > want to shift right, you should say so.
> >
> > I'd rather say that shifts are only defined for values between zero
> > and the word size, which excludes all negative values.
> >
> > What's the result of (13 << N) where N is an argument that might
> > have a negative value? On computers that treat a variable shift
> > argument as an unsigned number (all of them these days) does the
> > computer have to generate code to test the sign of N and so forth?
> >
> > The VAX designers outsmarted themselves (not the only time) when
> > they had one shift instruction with a signed argument rather than
> > separate left and right shifts. I can't think of a time I've
> > done shifting and didn't know when I wrote the code which direction
> > I wanted to shift, even if the number of shifts was variable.
> >
> Perhaps VAX followed the semantics of ADD? After all, 13 + -7 is 6, not
> some very large number - so there is really no reason for SUB to be in
> the ISA.
<
My 66000 ISA does not have a SUB instruction !!
It has instructions with sign control over the operands prior to calculations.
<
So, it can encode:
<
d = -a + -b;
<
in a single instruction.

John Levine wrote:
> According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>> So, what does (13 << -7) mean ?
>> I suspect everyone in this group knows what the above means in
>> C according to the C standard, but if you're asking what we think it
>> should mean instead (either in C or in other languages), then my answer
>> is that it should mean the same as (13 >> 7) because it's the most
>> intuitive behavior, and the cleanest semantics.
>
> Intuitive is in the mind of the beholder, and in my mind, if you
> want to shift right, you should say so.
>
> I'd rather say that shifts are only defined for values between zero
> and the word size, which excludes all negative values.
>
> What's the result of (13 << N) where N is an argument that might
> have a negative value? On computers that treat a variable shift
> argument as an unsigned number (all of them these days) does the
> computer have to generate code to test the sign of N and so forth?

It could have both left and right shift instructions
where a positive count is in the instructions' direction,
and a negative count is the reverse direction for both.
Symmetry!

Now question #2: what does it mean when N >= data operand bit-size?

On Monday, January 10, 2022 at 2:03:39 PM UTC-7, John Levine wrote:

> The VAX designers outsmarted themselves (not the only time) when
> they had one shift instruction with a signed argument rather than
> separate left and right shifts.

I'll definitely agree that this is a very unusual instruction. However
nice it might seem to have such an instruction, and to define the
<< and >> operators in the way it makes feasible, in the real world
this isn't needed, as you say.

In fact, while I would not have been surprised to hear that the
PDP-10 had such a shift instruction, I'm rather amazed that
this was done with the VAX.

John Savard

On Monday, January 10, 2022 at 2:31:20 PM UTC-7, MitchAlsup wrote:
> On Monday, January 10, 2022 at 3:03:39 PM UTC-6, John Levine wrote:

> > I'd rather say that shifts are only defined for values between zero
> > and the word size, which excludes all negative values.

> AND THUS: the right side operand SHOULD be unsigned !!!

That does not follow. While C does have an unsigned integer type,
many languages see no need to bother with such a thing, and for
functions and operators to admit of a DOMAIN ERROR condition
when used improperly is nothing strange.

John Savard