On Monday 31 December 2001 11:57 pm, Boris Tschirschwitz wrote: > I really don't see what UINTVALS are good for.
Here are reflections on my stance.... http:[EMAIL PROTECTED]/msg06913.html > I wonder if making the interpreter so much bigger (with all the > unsigned counterparts of int arithmetic functions) just for being able to > use native ints instead of bigints a little longer (*2) wouldn't cost more > than it gains. That's not what they are used for. Ops involving generic numbers (like adding two numbers) will always be done with signed values. Anything larger than 31/63 bits will use a BIGINT PMC. Ops involving fixed, unsigned internal entities - like string sizes - will either be coded as such, or be cast appropriately. So we shouldn't have two versions of anything. > If it is for type checking, I doubt that Parrot is the place to worry > about types, that ought to be done in the language compiled down to > parrot. Internal type checking is one reason, yes. It's supposed to be an extra-level of protection, but I'm sure there are a myriad examples of where we'll still go wrong. The occasional bit-shifting (with masks, etc) also need protection from high-bit propogation. > For optimization issues, an optimizer should either check the high level > source or, perhaps preferrable, the compiler could write an extra file > with more language independent optimization hints to be used by an > optimizer, when optimization is required. -- Bryan C. Warnock [EMAIL PROTECTED]
