My permanent source of confusion and therefore bugs

Just want to share my experience working with Interpreter/
interpreterProxy api using VMMaker.

Make a guess (and answer quickly, in what direction each of these
methods doing conversion)

positive32BitValueOf:
positive32BitIntegerFor:


got the answer?

These methods along with other xxxIntegerFor: and xxxValueOf:
used most frequently in primitive conversion code.
And i am really sick of such naming..

--
Best regards,
Igor Stasenko AKA sig.

On Fri, May 14, 2010 at 02:41:22AM +0300, Igor Stasenko wrote:
If you think of a positive integer value stored in a 32-bit C variable
as a "positive32BitValue", and an integer object representing values
in the range 0 through 4294967295 as a "positive32BitInteger", then
the naming seems reasonable to me.

Personally, I use MemoryAccess and SlangBrowser to look at things
like this in the browser and figure out what is really going on. This
shows that #positive32BitValueOf: answers an integer value (twos complement
32-bit integer as in C or Fortran), and #positive32BitIntegerFor: answers
an object of type SmallInteger or LargePositiveInteger.


/* Convert the given object into an integer value.
        The object may be either a positive ST integer or a four-byte LargePositiveInteger. */

sqInt positive32BitValueOf(sqInt oop) {
register struct foo * foo = &fum;
    sqInt sz;
    sqInt value;

        if ((oop & 1)) {
                value = (oop >> 1);
                if (value < 0) {
                        return primitiveFail();
                }
                return value;
        }
        assertClassOfis(oop, splObj(ClassLargePositiveInteger));
        if (foo->successFlag) {
                sz = lengthOf(oop);
                if (!(sz == 4)) {
                        return primitiveFail();
                }
        }
        if (foo->successFlag) {
                return (((fetchByteofObject(0, oop)) + ((fetchByteofObject(1, oop)) << 8)) + ((fetchByteofObject(2, oop)) << 16)) + ((fetchByteofObject(3, oop)) << 24);
        }
}



/* Note - integerValue is interpreted as POSITIVE, eg, as the result of
                Bitmap>at:, or integer>bitAnd:. */

sqInt positive32BitIntegerFor(sqInt integerValue) {
register struct foo * foo = &fum;
    sqInt newLargeInteger;

        if (integerValue >= 0) {
                if (
# ifdef SQ_HOST32  // cast to int for 64 bit image on 32 bit host
                        (((((int) integerValue)) ^ ((((int) integerValue)) << 1)) >= 0)
# else
                        ((integerValue >= -1073741824) && (integerValue <= 1073741823))
# endif  // SQ_HOST32
                ) {
                        return ((integerValue << 1) | 1);
                }
        }
        if (BytesPerWord == 4) {

                /* Faster instantiateSmallClass: currently only works with integral word size. */

                newLargeInteger = instantiateSmallClasssizeInBytes(((sqInt) ((((sqInt *) ((sqMemoryBase) + ((foo->specialObjectsOop + BaseHeaderSize) + (ClassLargePositiveInteger << ShiftForWord)))))[0])), BaseHeaderSize + 4);
        } else {

                /* Cant use instantiateSmallClass: due to integral word requirement. */

                newLargeInteger = instantiateClassindexableSize(((sqInt) ((((sqInt *) ((sqMemoryBase) + ((foo->specialObjectsOop + BaseHeaderSize) + (ClassLargePositiveInteger << ShiftForWord)))))[0])), 4);
        }
        ((sqInt) ((((unsigned char *) ((sqMemoryBase) + ((newLargeInteger + BaseHeaderSize) + 3))))[0] = ((((usqInt) integerValue) >> 24) & 255)));
        ((sqInt) ((((unsigned char *) ((sqMemoryBase) + ((newLargeInteger + BaseHeaderSize) + 2))))[0] = ((((usqInt) integerValue) >> 16) & 255)));
        ((sqInt) ((((unsigned char *) ((sqMemoryBase) + ((newLargeInteger + BaseHeaderSize) + 1))))[0] = ((((usqInt) integerValue) >> 8) & 255)));
        ((sqInt) ((((unsigned char *) ((sqMemoryBase) + ((newLargeInteger + BaseHeaderSize) + 0))))[0] = (integerValue & 255)));
        return newLargeInteger;
}

On 14 May 2010 05:07, David T. Lewis <[hidden email]> wrote: That's the point, each time i wasting time on that , to make sure i
using right way of conversion.
I didn't thought about better naming , but i think a more revealing
names would be something like:

positive32BitIntToOop
oopToPositiveInt32

or

uint32ToOop
integerOopToUint32

the 'To' word is a key here, it leaves no options how to interpret the
operation direction.

>

>



--
Best regards,
Igor Stasenko AKA sig.

This might be off topic, but why "To"? Why not "As"? Being ignorant of slang might explain why I'm asking:)




--
Casey Ransberger

On 14 May 2010 06:49, Casey Ransberger <[hidden email]> wrote:
> This might be off topic, but why "To"? Why not "As"? Being ignorant of slang
> might explain why I'm asking:)
>
to clarify, its from given context:
[convert]Uint32ToOop
[convert]IntegerOopToUint32

that's why i used 'To', not 'As'.
But each, with 'convert' prefix omitted, an 'As' is more appropriate.




--
Best regards,
Igor Stasenko AKA sig.

On 14 May 2010 07:11, Igor Stasenko <[hidden email]> wrote: s/each/sure/

>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.