Front page | perl.perl6.internals |
Postings from October 2002
Re: C# and Parrot
From: Dan Sugalski
October 21, 2002 10:52
Re: C# and Parrot
Message ID: firstname.lastname@example.org
At 7:21 PM +0530 10/20/02, Gopal V wrote:
>If memory serves me right, Bryan C. Warnock wrote:
>> > It looks like we're going to need 8,16,32,64 bit types...
>> Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe
>> for floating point numbers?
>13 4.1.1 Floating Point
>14 The floating point feature set consists of the user-visible
> floating-point data types float32 and float64, and
>15 support for an internal representation of floating-point numbers.
>Float32 -- Single
>Float64 -- Double
>And,IIRC the same for JVM as well ?.
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.
> > Are we still targeting a middle ground for C? (Enough to be able to
>> parse and handle structs natively, and possibly even make calls
>Hmm... would be thinking of something like PInvoke in C# ?
>(viz a lot like JNI, but marshalls/unmarshalls args automatically,
> and we've managed to wrap parts of X11 with it).
Yeah, I want to do that with parrot, being able to on the fly
generate low-level call frames and call into native routines without
having to explicitly generate and compile C code for it.
It's a portability problem, to be sure, but on the other hand if
we're going to have a JIT most places we're already getting much
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
email@example.com have teddy bears and even
teddy bears get drunk