Hi.
<<, >> et al. are done with #bitShift: and a positive or negative value, depending on the direction
These selectors, #>> and #<<, should be deleted from Squeak... or left but the compiler instructed to use a proper #bitShift: instead...
Profiler measure: [4 bitShift: 2] 1mus 739ns Profiler measure: [4 << 2] 3mus 17ns
Andres.
Andres -
<<, >> et al. are done with #bitShift: and a positive or negative value, depending on the direction
These selectors, #>> and #<<, should be deleted from Squeak... or left but the compiler instructed to use a proper #bitShift: instead...
Profiler measure: [4 bitShift: 2] 1mus 739ns Profiler measure: [4 << 2] 3mus 17ns
I put these methods into Squeak to assist code generation for the VM and associated primitives. The C translator has to compile a run-time test for the sign of the shift count in the case of bitShift:, so we use >> and << for speed where this is known (nearly everywhere). Clearly, this information should be documented in those methods, along with the fact that the primitive bitShift: is faster in Squeak.
- Dan
Hi.
These selectors, #>> and #<<, should be deleted from Squeak...
I put these methods into Squeak
Ouch!!!... :) oops, sorry!
to assist code generation for the VM and associated primitives. The C translator has to compile a run-time test for the sign of the shift count in the case of bitShift:, so we use >> and << for speed where this is known (nearly everywhere).
Ahhhhhhh! Yes... now the picture is clear.
Clearly, this information should be documented in those methods, along with the fact that the primitive bitShift: is faster in Squeak.
Hmmmmm... is the JPEG reader converted to C too? Besides >> and <<, today I found a method in the JPEG reader with something like
(aNumber to: someOther by: yetAnother) do: aBlock
.... errr... now I don't know what to say! :)))... another little thing. Would it be ok if Float>>#rounded was rendered into a bytecode? Most FPUs should have a round-to-integer instruction.
Andres.
squeak-dev@lists.squeakfoundation.org