Re: [ooc-compiler] C interface problems
Brought to you by:
mva
Menu
▾
▴
Re: [ooc-compiler] C interface problems
|
From: Stewart G. <sgr...@ii...> - 2004-11-05 23:03:31
|
Hi August,
> Yes, it worked! Thank you. (Not so obvious to use Pascal calling
> convention with a C library).
No, its not obvious. However, Pascal (or "stdcall") conventions are the
norm for almost every public API under Windows. I think this was
originally done to reduce the code size. Having the callee remove the
stack frame reduces the size of a procedure call sequence, but
disallows "C"-style variable parameter lists. Only in situations where
variable parameters are required does Win32 (eg. wsprintf, etc.) use
"C" conventions.
> I also skimmed through your GL.Mod file and noticed that literal
> values are defined for (macro) constants. Isn't it possible for the
> OOC compiler to get the values from the C header file?
This would require OOC to incorporate the front-end of a C compiler
(ie. the preprocessor and declaration parser). Technically, it could be
done but the problem is that there is no unique mapping from C types to
Oberon-2 types. For example, if you see "char * p" in a parameter list,
it could mean "VAR p : CHAR", "p : POINTER TO ARRAY OF CHAR", "p :
ARRAY OF CHAR", "VAR p : ARRAY OF CHAR", or "POINTER TO CHAR" (this one
exists in "C" but has no equivalent in Oberon-2). Different rules apply
for different APIs, so the approach I have used is to have a separate
translator that that processes the "C" files but allows one to do the
relevant tweaks on the generated interfaces. Another issue is that
Oberon-2 disallows type constructors in procedure parameter lists, so
these have to be "rewritten" to use new or existing types. Again, there
are different rules for controlling how this works.
> Moreover I tend to dislike all but the absolutely necessary Oberon-2
> extensions*, so I would prefer to rename all identifiers to valid
> Oberon-2 identifiers (no underscores) that follows the standard naming
> scheme and keep the definitions in three different modules: GL.Mod,
> Glu.Mod and Glut.Mod. The conversion rules are very regular (thanks to
> the regularity of the OpenGL interface):
I agree that separate modules would be a good idea. In the case of
OpenGL things are pretty clear. In general, the difficulty is that the
"C" language has no concept of modules, so its necessary to infer the
module structure and dependencies from analysing the declarations.
Sometimes (eg. Win32) there are hundreds of modules and its
semantically simpler to translate the whole thing as a single module.
For Win32, users normally just do "#include <windows.h>", and are not
aware of which functions come from which modules. Therefore there needs
to be options to control which declarations appear as separate modules,
and which are merged.
It should be possible to rename the identifiers. Potentially, it might
surprise users to find that the names have changed - they would have to
mentally do the translation while coding for the API.
> Constants - Remove the prefix, lower case the first word, capitalize
> the following words (if any) and remove the underscores, e.g.
> GL_COLOR_BUFFER_BIT becomes colorBufferBit. There also exists a
> tradition to use Pascal case (rather than camel case) with exported
> variables and constants. Have not decided which is the best choice.
This might work, providing that it does not introduce a name clash as a
result.
> Types - Remove the prefix and capitalize, e.g. GLclampf becomes Clampf.
>
> Variables - (No exported variables, right?)
>
> Functions - Just remove the prefix, e.g. glutSwapBuffers becomes
> SwapBuffers.
Yes, again its a case of imposing a module namespace where "C" has no
such concept. This should not be a problem. I'll take a look at it.
> *If we want Oberon-2 with lots of extensions then we might as well
> turn to Eiffel.
I guess that depends what you're trying to do. Plain Oberon-2 has a
number of deficiencies which the extensions are designed to fix. I find
them useful, but of course everyone is entitled to use them or not as
they wish. Some of the extensions are source-level compatible with
Oberon-2 (eg. abstract types). If you want interoperability with other
Oberon-2 compilers then you would need to stay clear of certain ones
(eg. exception handling, parameteric types).
I don't know Eiffel well, but it does have some nice concepts in there.
Same goes for Modula-3.
Cheers,
Stewart
>
> ----- Original Message ----- From: "Stewart Greenhill"
> <sgr...@ii...>
> To: "August" <fus...@te...>
> Cc: <ooc...@li...>
> Sent: Thursday, November 04, 2004 1:20 PM
> Subject: Re: [ooc-compiler] C interface problems
>
>
>> Hi August,
>>
>>> One potential problem: the glut functions are defined as "APIENTRY",
>>> which under Windows means that they use the "stdcall" calling
>>> convention rather than "cdecl". Therefore, you should probably
>>> specify "Pascal" rather than "C" as your interface type. That is:
>>> MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB
>>> "opengl32"; END];
>>> I think the same goes for the other GL modules. Presuming that the
>>> linker knows the procedure attributes, that may be why it is giving
>>> the error (ie. the procedure name matches, but the attributes are
>>> wrong).
>>
>> I ran a quick check, and it looks like this is indeed what happens.
>> The following should compile and link fine. It also runs OK, opening
>> a window and correctly calling the display procedure.
>>
>> MODULE Test;
>> IMPORT C, Glut;
>> VAR w: C.int;
>> PROCEDURE Display ["Pascal"];
>> END Display;
>> BEGIN
>> w := Glut.CreateWindow("OpenGL Test");
>> Glut.DisplayFunc(Display);
>> Glut.MainLoop
>> END Test.
>>
>> MODULE Glut [INTERFACE "Pascal"; LINK LIB "glut32"; LIB "opengl32";
>> END];
>> IMPORT C;
>> TYPE
>> DisplayCallback = PROCEDURE;
>>
>> PROCEDURE ["glutCreateWindow"] CreateWindow*(title: ARRAY OF
>> C.char): C.int;
>> PROCEDURE ["glutDisplayFunc"] DisplayFunc*(p: DisplayCallback);
>> PROCEDURE ["glutMainLoop"] MainLoop*;
>> END Glut.
>>
>> Hope this helps.
>>
>> Cheers,
>> Stewart
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>
|
