If memory serves me right, Nicholas Clark wrote:
> fussy. I presume Rhys is thinking about compiling C code to parrot, and then
> linking through to native C code (such as the native standard C library) via
> parrot.
Nope ... At least for our .NET platorm stuff ,we are planning to compile
glibc into IL so that the "native ABI" is accessed only via the engine.
Most peices of glibc, depend on a few platform functions to run (most
notably some in unistd.h) ... Most of the other peices of glibc can be
directly used like the printf formatting code or file functions , once
these underlying posix calls are in place... this is consistent with design
philosophy of glibc which has been source portability rather than binary.
So get your own glibc-managed.dll according to long,int, and char sizes :)
> without needing a C compiler, but you'd not be able to call out from your
> C code.
We are facing a similar situation, but only that we have PInvoke (like your
NCI) which allows you to define PInvoke methods from Managed C (I'd prefer
the term Micro-Managed :)
But the following does work for some functions :)
extern int puts(const char *s) __attribute__((__pinvoke__("libc.so.6")));
mm... ugly !
Rhys has also been really cool about the data stored via C ... So legacy
code which used fixed size files (otherwise called "records") will be useful.
This allows us to declare 8bit characters and strings of those and all the
stuff we're used to with C like unions ... (C# has 16bit chars, and strings
are UTF8 encoded , IIRC) ...
In short, we will keep similar layouts in memory for structs and unions as
far as possible ... (unions without offset based access to memory boggles
my mind....)
So even with all the type-safety of IL we can run the following code ...
float a=3.14;
int b=*((int*)(&(a)));
> What Rhys is thinking about is potentially far more interesting, as it would
What Rhys is using right now is a custom stdlib which is called pnetC and
was just released ... People *really* curious about what Rhys is doing
(and what those half-a-million lines are doing in DotGNU) should try the
Portable.net C compiler (http://dotgnu.org/downloads/pnet/) .. We have
mirrors on each gnu mirror as /projects/dotgnu ... (since we're likely to
be slashdotted to death soon....)
Very, Very curiously ... I can call C# methods from Managed C, but not the
otherway around :) .. and I can call native methods from Managed C , but
that's dreadfully unportable like you said ...
I'm really working only to get C# compiled to Parrot .... other language
frontends in development like Java or C or JScript can wait a looong time.
Gopal
--
The difference between insanity and genius is measured by success
