Front page | perl.perl6.internals |
Postings from October 2002
Re: C# and Parrot
Thread Previous
|
Thread Next
From:
Rhys Weatherley
Date:
October 21, 2002 14:02
Subject:
Re: C# and Parrot
Message ID:
3DB46D54.479ACC78@zip.com.au
Dan Sugalski wrote:
> I think so. I'm going to add in some conversion ops for the shorter
> float forms, and for the partial-sized integers. I'm unsure at the
> moment whether I want to commit to full 64 bit integers in I
> registers. On the one hand it means a lot more can be done at the low
> level, on the other it means things are going to be potentially slow
> and emulated on non-64 bit int platforms. Plus it'll waste a fair
> amount of L1 cache for no purpose most of the time.
64-bit integers (both signed and unsigned) are rare enough in C#
(and Java) code that accessing them via PMC operations will not
be a huge burden. Putting them in registers is not necessary
on my account.
As to your other message, where you suggest making INTVAL's 64-bit
all of the time, I really don't like that proposal. It makes the
common case inefficient. You'll also go mad trying to implement
64-bit multiplication and division in the JIT ( :-) ). If you
make it a PMC operation, you can let the compiler do the work.
There are other places in Parrot that assume that an INTVAL is
the same size as a native pointer (e.g. set_addr). Mandating a
fixed size might break these assumptions.
My humble suggestion is to do this:
INTVAL is guaranteed to be 32 bits or higher in size.
FLOATVAL is guaranteed to be 64 bits or higher in precision.
Int64 is added as a new PMC type.
Then use conversion opcodes to re-normalize results to smaller
fixed sizes where necessary. Languages that care about sizes
must do explicit conversion. Other languages can be free-form.
It will be a little annoying to do this in the C# compiler:
add I0, I1, I2
conv_int32 I0, I0
However, the JIT can optimize away the "conv_int32" on a 32-bit
platform, so it isn't really an issue. But it will be an issue
if you make everything 64-bit.
BTW, I've yet to come across a compiler that doesn't have some
way to use 64-bit integers. The names vary: "long" on some,
"long long" on others, and the obnoxious "__int64" on Windows.
But that's just a configuration problem.
Cheers,
Rhys.
P.S. Don't forget the unsigned types. :-)
Thread Previous
|
Thread Next