[M3devel] C math interop..

[Jay K]

Yes. At least slightly -- int vs. INTEGER. I will fix them.


The case of Cstring.strcat/strcpy is different.
They end up as Type.Addr strcat(Type.Addr dest, Type.Addr source);
I have some leeway in what Type.Addr ends up as, but no
choice is right there. My main choices are char*, unsigned char* and
void*. (At some point, I'm serious about having a K&R option,
so void* will fall out of favor, but I'm using char* now anyway, since
I can do math on it more conveniently. I've run into slightly interesting
K&R compilers twice in the past few years -- on Irix and HPUX.)


It is possible I changed them from int to INTEGER anyway.
Some notion I had of passing "register-sized" things being "better".
I can check.
But at the moment I'm sure using int or whatever ANSI C says, is the way to go.


 - Jay


Subject: Re: [M3devel] C math interop..
From: hosking at cs.purdue.edu
Date: Sun, 9 Sep 2012 22:00:39 -0400
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

I don’t understand.  Are you saying that the M3 declarations of these externals are wrong?


On Sep 8, 2012, at 5:54 AM, Jay K <jay.krell at cornell.edu> wrote:hm. The advantage of not having wrappers, is you can declare things that don't exist.Maybe only on some platforms.So I'll probably fix the declarations.For scaleb/ldexp/sqrt too.(similar to what I did for strcat/strcpy in Cstring.i3 -- no wrappers, to avoid OpenBSD link warning/error)
Later, - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 8 Sep 2012 09:50:19 +0000
Subject: [M3devel] C math interop..

This also occured in FPU.ic
Math.ic.c:217: error: conflicting types for ‘signgam’/usr/include/architecture/i386/math.h:543: error: previous declaration of ‘signgam’ was hereMath.ic.c:298: warning: conflicting types for built-in function ‘cabs’Math.ic.c:302: error: conflicting types for ‘frexp’Math.ic.c:306: error: conflicting types for ‘ldexp’Math.ic.c:310: error: conflicting types for ‘modf’Math.ic.c:329: error: conflicting types for ‘jn’Math.ic.c:339: error: conflicting types for ‘yn’

Generally int vs. INTEGER confusion.To fix these errors, I'm going to provide C wrappers for these functions, and everything else in the file.

This hints at some new way to do interop, fast like the old way, but with static checking,where the generated C #includes the relevant .h files.But this is a bit abstraction bending -- the backend isn't supposed to be doing these checks.The frontend does.You'd have to have changes in the <* extern *> pragma like  - this isn't an actual function signature, necessarily..and the address can'tnecessarily be taken, but something close enough to this will materialize from a C header   - specify the C header 

Imagine a world with a good C backend, and a good other one.Modules that interoperate with C could be sent off to the C backend automatically.

Anyway, just crazy stuff, nothing really happening here beyond I'll add C wrappers. :)

When I get to it, #include <Xlib.h> along with our declarations..it will be interestingto see if things match. And <windows.h>...There will be problems. We have one UINT32 type in the generated C.Win32 has unsigned int and unsigned long used kind of interchangably.There will be clashes.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120910/ff31ea00/attachment-0002.html>