 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2006Shift operand question
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 > I got some question of a free test on the internet and I do not > understand it. [quoted text clipped - 15 lines] > > 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 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 > Patricia Shanahan schreef: > [quoted text clipped - 7 lines] > 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.  SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" > 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 > > 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 ?? 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 >>> 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 [quoted text clipped - 5 lines] > 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 >> A few processors, given I >> 1000000000, actually will do a >> 1,000,000,000-digit shift, one bit at a time, with horrible results, [quoted text clipped - 6 lines] > 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. SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" > Plenty of hardware and software is designed with the assumption "No > single instruction will ever take more than (n) microseconds." Some [quoted text clipped - 6 lines] > 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 >> Plenty of hardware and software is designed with the assumption "No >> single instruction will ever take more than (n) microseconds." Some [quoted text clipped - 11 lines] > 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.) SignatureJohn W. Kennedy "The blind rulers of Logres Nourished the land on a fallacy of rational virtue." -- Charles Williams. "Taliessin through Logres: Prelude" > 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 >> Answer is incorrect, It is mod 32 that returns the same value for >> integers. [quoted text clipped - 14 lines] > 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 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 > >> Answer is incorrect, It is mod 32 that returns the same value for > >> integers. [quoted text clipped - 26 lines] > > Patricia > Hi , > There is interesting example: [quoted text clipped - 3 lines] > 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 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 schreef: > [quoted text clipped - 4 lines] > (??), 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.