Shift operand question

[marcwentink]

I got some question of a free test on the internet and I do not
understand it.


//-------------------
Is the following true or false: A mod (%) 16 is performed on the shift
operand which affects shifts
of more than 16 places for integers.

Answer is incorrect, It is mod 32 that returns the same value for
integers.
A mod 16 is applied for short values that will return the same value,
the modulus
of the size in bits of the type (integer, short, ..) is applied.
//---------------------

It comes from javacertificate.com. I have no idea really what they are
talking about. Could someone give me a hint?

Marc Wentink

 

[Patricia Shanahan]

I got some question of a free test on the internet and I do not
understand it.


//-------------------
Is the following true or false: A mod (%) 16 is performed on the shift
operand which affects shifts
of more than 16 places for integers.

Answer is incorrect, It is mod 32 that returns the same value for
integers.
A mod 16 is applied for short values that will return the same value,
the modulus
of the size in bits of the type (integer, short, ..) is applied.
//---------------------

It comes from javacertificate.com. I have no idea really what they are
talking about. Could someone give me a hint?

Marc Wentink

It relates to one of the rather awkward decisions that was made in Java
to increase the range of processors that can run Java reasonably
efficiently.

The issue is the treatment of shifts of an N bit expression by N or more
bits. Usually, it would be most useful for it to have the same result as
doing the corresponding single bit shift N times. For example, the
integer expression ( 23 >> 100 ) should be zero.

However, the Java developers made a different choice. Instead, they
decided to reduce all shift counts modulo the number of bits in the
expression being shifted.

Thus ( x >> 100 ) is the same as ( x >> ( 100 % 32 ) ) = ( x >> 4 ) for
int x.

and

( y >> 100 ) is the same as ( y >> ( 100 % 64 ) ) = ( y >> 36 ) for long y.

Even on a processor that implements shift differently, this behavior can
be forced by a simple masking step before shifting.

Patricia

 

[marcwentink]

Patricia Shanahan schreef:

It relates to one of the rather awkward decisions that was made in Java
to increase the range of processors that can run Java reasonably
efficiently.

Thank you for your explination. Although I do not know how would
increase the range of processors ... et cetera. But I am not sure I
want to know that. If I come across this question in a test your
explination give me a handle to understand the question. My
appreciation to you.

Marc

 

[Chris Uppal]

Answer is incorrect, It is mod 32 that returns the same value for
integers.
A mod 16 is applied for short values that will return the same value,
the modulus
of the size in bits of the type (integer, short, ..) is applied.

Adding to Patricia's explanation.

That second quoted sentence is extremely unclear, and I don't really know what
it is trying to say. It /might/ be taken to suggest that if you shift a short
by n, then n is taken mod 16, and similarly that the shift of a byte value is
taken mod 8. If that /is/ what it is trying to say, then it is incorrect --
the shift-by values taken mod 32 for ints and all smaller types; mod 64 for
longs.

More accurately, you can't actually shift a short -- its value is always
promoted to an int before the shift, and the result of the expression is an
int, not a short.

-- chris

 

[Patricia Shanahan]

Adding to Patricia's explanation.

That second quoted sentence is extremely unclear, and I don't really know what
it is trying to say. It /might/ be taken to suggest that if you shift a short
by n, then n is taken mod 16, and similarly that the shift of a byte value is
taken mod 8. If that /is/ what it is trying to say, then it is incorrect --
the shift-by values taken mod 32 for ints and all smaller types; mod 64 for
longs.

More accurately, you can't actually shift a short -- its value is always
promoted to an int before the shift, and the result of the expression is an
int, not a short.

Yup. In my experience, practice exams, especially Internet freebies,
tend to be less well thought out than the real ones. Doing this sort of
thing well is very expensive.

DO NOT ASSUME SOMETHING IS TRUE JUST BECAUSE A PRACTICE EXAM QUESTION OR
ANSWER SAYS SO.

Write test programs. Check the JLS and API specifications. Ask questions
here.

Patricia

 

[vahan]

Hi ,
There is interesting example:
System.out.println("...." + (121L >> 100 == 121L >> 4)); // It is
"false"
but
System.out.println("...." + (12L >> 100 == 12L >> 4)); //It is
"true" , why?

Thanks

 

[marcwentink]

Patricia Shanahan schreef:

DO NOT ASSUME SOMETHING IS TRUE JUST BECAUSE A PRACTICE EXAM QUESTION OR
ANSWER SAYS SO.

Well, since I actually do not think I will ever use this in practice
(??), the only thing that matters is: what does the exam creator think
is true. Assuming you want to pass the exam. ;-)

 

[Patricia Shanahan]

Hi ,
There is interesting example:
System.out.println("...." + (121L >> 100 == 121L >> 4)); // It is
"false"
but
System.out.println("...." + (12L >> 100 == 12L >> 4)); //It is
"true" , why?

[The usual convention in this newsgroup is to add new content at the
bottom of a message]

A long shift by 100 is equivalent to a long shift by 100 % 64 = 36.

The bit pattern for 121 is 1111001. Shifting it by 36 gives zero, but
shifting it by 4 gives 111. Not equal.

The bit pattern for 12 is 1100. Shifting it by either 36 or 4 gives
zero. Equal.

In both cases, you are using different shift counts, but shifts by
different counts can give the same result, depending on the input.

Patricia

 

[Patricia Shanahan]

Patricia Shanahan schreef:


Well, since I actually do not think I will ever use this in practice
(??), the only thing that matters is: what does the exam creator think
is true. Assuming you want to pass the exam. ;-)

However, the point I'm trying to make is that the correlation between
what the exam creator thinks is true and the facts is far closer for
"official" tests that go through some level of review and testing than
for free over-the-Internet practice tests.

I'm not saying you will never encounter some wrong assumption in the
actual test, but that it is less likely.

Patricia

 

[John W. Kennedy]

Patricia Shanahan schreef:


Thank you for your explination. Although I do not know how would
increase the range of processors ... et cetera. But I am not sure I
want to know that. If I come across this question in a test your
explination give me a handle to understand the question. My
appreciation to you.

A few processors, given I >> 1000000000, actually will do a
1,000,000,000-digit shift, one bit at a time, with horrible results, up
to and including crashing the operating system.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

A few processors, given I >> 1000000000, actually will do a
1,000,000,000-digit shift, one bit at a time, with horrible results, up
to and including crashing the operating system.

How can that crash the operating system ??

You take a variable with N bits, do some shifting and store
the result in a temporary variable of M bit (I think typical
M=N but ...). No other parts of memory than those N and M bits
should be involved.

Arne

 

[Chris Uppal]

How can that crash the operating system ??

Why shouldn't it crash the OS ?

The processor in question is clearly operating outside its design space, so
there's no telling what bits it'll put where, or (perhaps more important) when.
The OS cannot protect itself against bugs (or other misbehaviour) in the the
processor it is running on, any more than a process can protect itself against
bugs in the OS, or a Java program against bugs in the JVM...

-- chris

 

[John W. Kennedy]

How can that crash the operating system ??

You take a variable with N bits, do some shifting and store
the result in a temporary variable of M bit (I think typical
M=N but ...). No other parts of memory than those N and M bits
should be involved.

Plenty of hardware and software is designed with the assumption "No
single instruction will ever take more than (n) microseconds." Some
processors, however, also assume without checking that bit-shift amounts
will be reasonable, and, given an unreasonable amount, will spin their
wheels for many, many cycles, invalidating the first assumption.
Compilers written for processors with this problem generally put in a
safety feature to ensure that a shift will never be for more than
(register-width) bits. Java, because of its high-portability
requirements, merely puts this safety feature into the defined language
semantics.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Why shouldn't it crash the OS ?

The processor in question is clearly operating outside its design space, so
there's no telling what bits it'll put where, or (perhaps more important) when.

If it is a valid instruction it will execute and only
change the output and possible some flags.

If it is an invalid instruction it may fault/abort/trap
and leave output and possible some flags in an
undefined state.

It should never start storing random data at random
addresses.

And I can not imagine any way of implementing the shift
that should do so.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Plenty of hardware and software is designed with the assumption "No
single instruction will ever take more than (n) microseconds." Some
processors, however, also assume without checking that bit-shift amounts
will be reasonable, and, given an unreasonable amount, will spin their
wheels for many, many cycles, invalidating the first assumption.
Compilers written for processors with this problem generally put in a
safety feature to ensure that a shift will never be for more than
(register-width) bits. Java, because of its high-portability
requirements, merely puts this safety feature into the defined language
semantics.

Hm.

I would say that the processor implementation has not fully
implemented its instruction set.

And it means that it is a piece of cake for any assembler
program to crash the system without any special privileges.

But, then I have a feeling that you are not talking about
multi user systems, but are over in the embedded world.

Arne

 

[John W. Kennedy]

Hm.

I would say that the processor implementation has not fully
implemented its instruction set.

That's a question for the architect. Such a safety feature might be
intentionally omitted from the design for reasons of cost or performance.

And it means that it is a piece of cake for any assembler
program to crash the system without any special privileges.

But, then I have a feeling that you are not talking about
multi user systems, but are over in the embedded world.

Today, yes. (My memory goes back to the discrete-transistor era, when it
was quite simple for an assembler program to crash a mainframe.
XEQ *
on a 7090, for example, would put the hardware into a never-ending
instruction. If you are familiar with the S/360 family, you may require
that the equivalent,
EX 0,*
is forbidden, and trapped. Computer evolution in action, so to speak.)