Bryan wrote -- >> Ok, I was put in a burlap sack and beaten for my first attempt at >>this; >> hopefully this attempt will go better. Based on everyone's (read: Dan's) >> comments I have changed the patch to NOT move integer constants to the >> constant table. Instead, the assembler dies if you try to make it handle >> an integer constant value larger than 2 ** 31 or smaller than -2 ** 31.
>Well, that obviously should be MAX_whatever and MIN_whatever. >But sufficient for now, since that's probably a configure thing. Yes and No. If our inline constants are always going to be 32 bits then 2 ** 31 should always work (of course I shouldn't do it in such an ugly fastion, but a constant should work ). >> This required a change in two of the integer tests as 0xdeadbeef and >> 0xa0b0c0d0 were both bigger than 2 ** 31. >> Basically, this patch ensures that all code in the pack file is of size >> opcode_t (except the constant table which is in string(char) or double >> format). It also has the (size_t) casts where pointers are converted to >> integers. >FWIW, size_t != size of pointers everywhere. (But you're probably >safe.) No, but it should always be AT LEAST as big as a pointer. That is all that matters, we only have problems when it is smaller. (See below) >> a FLOATVAL constant without having to type 0.0 >> 9.) Changed (INTVAL) casts in memory.c, register.h, and strnative.c to >> (size_t) casts just in case sizeof(INTVAL) < sizeof(void*); >!=, not <. (If you cast back, for instance.) Unless we do something horribly wrong, then the cast back shouldn't be a problem becuase the value cast back will fit in a void*. >> 10.) integer.t had 0xdeadbeef changed to 0xdeadbee and 0xa0b0c0d0 to >> 0xa0b0c0d for signed 32 bit compatability. >> Any and all feedback is appreciated. >> >> NOTE: I apologize if this patch is still not what is wanted; I don't want >> to enforce anything I decide to code on parrot, but I thought it might be >> easier to comment on the patch if it were already coded. If this isn't >> wanted, I will continue to change it until it is :) >I'm still not sure about size_t, but nothing standard had been added >until >recently. It's probably universal enough to be safe, but we may want to >just find a type the same size as a pointer and roll our own just to be >safe. I think size_t will be safe; however, I understand your hesitation. I can replace size_t with a typedefed type ( perhaps ptrcast_t ) and then have it typedefed with size_t to begin with. That way, we can easily change it when we decide what we want to do. Does that sound OK? Thanks for the feedback! Tanton
