Re: C# and Parrot

[Dan Sugalski]

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?

IL (Ecma-335)
--------------
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
 natively?)

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 grubbier.

--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk