The Trunk: Kernel-eem.885.mcz

Eliot Miranda uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-eem.885.mcz

==================== Summary ====================

Name: Kernel-eem.885
Author: eem
Time: 19 November 2014, 3:33:32.003 pm
UUID: 6e239e5b-b957-4ff6-a3ce-bb3ee10cf826
Ancestors: Kernel-eem.884

Steal the Smalltalk-80 V2 definition of SmallInteger>>
digitAt: which doesn't assume max digit length.

=============== Diff against Kernel-eem.884 ===============

Item was changed:
  ----- Method: SmallInteger>>digitAt: (in category 'system primitives') -----
  digitAt: n
+ "Answer the value of an apparent byte-indexable field in the receiver,
+ analogous. to the large integers, which are organized as bytes."
+
+ n = 1 ifTrue: "Negate carefully in case the receiver is SmallInteger minVal"
+ [self < 0 ifTrue:
+ [^-256 - self bitAnd: 255].
+ ^self bitAnd: 255].
+ self < 0 ifTrue:
+ [^(-256 - self bitShift: -8) + 1 digitAt: n - 1].
+ ^(self bitShift: 8 - (n bitShift: 3)) bitAnd: 255!
- "Answer the value of an indexable field in the receiver.  LargePositiveInteger uses bytes of base two number, and each is a 'digit' base 256.  Fail if the argument (the index) is not an Integer or is out of bounds."
- n>4 ifTrue: [^ 0].
- self < 0
- ifTrue:
- [self = SmallInteger minVal ifTrue:
- ["Can't negate minVal -- treat specially"
- ^ #(0 0 0 64) at: n].
- ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF]
- ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF]!

On Wed, Nov 19, 2014 at 11:33:41PM +0000, [hidden email] wrote:
Interesting. The 32-bit optimization in digitAt: has been in Squeak since
1999, but it seems to have very little performance benefit on my system
(measured on a somewhat random combination of AMD Ubuntu with 64 bit image
and interpreter VM to prevent any misleading optimizations).

Assuming that the 1999 optimizations were important for at least some
platforms, I tried to adapt that method to accommodate 32 and 64 bit integer
sizes. The result was slower than any of the previous implementations.

So +1 for adopting the unoptimized Smalltalk-80 V2 definition of SmallInteger>>digitAt:

Dave

On 20.11.2014, at 03:08, David T. Lewis <[hidden email]> wrote:
Yes, although IMHO the recursive call to digitAt: is trying to be too clever. I don't see why it couldn't use a bitShift: and bitAnd: directly.

- Bert -