develooper Front page | perl.perl6.internals | Postings from December 2001

Re: [PATCH] - migrate encodings to UINTVAL

Thread Previous | Thread Next
From:
Bryan C. Warnock
Date:
December 31, 2001 21:08
Subject:
Re: [PATCH] - migrate encodings to UINTVAL
Message ID:
20020101050830.FVZT2213.femail32.sdc1.sfba.home.com@there
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://archive.develooper.com/perl6-internals@perl.org/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
bwarnock@capita.com

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About