[Openmcl-devel] DEFTRAP / DEFTRAP-INLINE

Gary Byers gb at clozure.com
Wed Nov 29 01:40:25 PST 2006


I'd vote for skipping the whole thing and using the existing FFI 
infrastructure; I was going to try to explain what DEFTRAP and
DEFTRAP-INLINE were, but I got a bad headache that only went away
when I stopped thinking about them.

(Briefly: on the 68K, instructions consisted of one or more 16-bit
words.  Words whose high nibble was #xA were not defined by the 68K
hardware, and Apple used the illegal instruction exception handler for
these "A-traps" to provide a mechanism to concisely (if slowly) call
into the OS and UI Toolbox.  After about 10 years, (with the move to
the PPC), Apple introduced shared library technology and the old
A-trap mechanism faded into history.  MCL's mechanism for defining the
operand and result type of "traps" was extended to deal with named
foreign functions; even though it's probably been 10 years or so since
anyone has defined a "trap" interface, the mechanisms used to define
foreign functions were never renamed.)


E.g., something like:

(use-interface-dir :gl) ; should define OpenGL/GLU/AGL/CGL/GLUT stuff

(defun glutcreatewindow (name)
   (with-cstrs ((c-name name))
     (#_glutCreateWindow c-name)))

or perhaps

(defun glutcreatewindow (name)
   (with-cstrs ((c-name name))
     (external-call "_glutCreateWindow" :address c-name :int)))

It might be easier to automatically translate into the latter.

What John Wiseman's MCL translation did sort of combined the
two ideas; the construct

(require-trap 'traps::foo ...)

basically caused the read-time effects of reading #_foo to occur
at (IIRC) macroexpand-time.  There isn't anything analogous in
OpenMCL, though there probably should be (even though the need
for the construct is fairly obscure.)  If you have enough information
to generate the EXTERNAL-CALL forms, that approach would avoid
the issue of what happens at read time and what doesn't.


On Tue, 28 Nov 2006, Brent Fulgham wrote:

> The MCL code for the Open Agent Engine (specifically the MCL-translation for 
> Allegro CL forms) makes use of a form called "DEFTRAP-INLINE" (see the 
> attached file for details).  I'm not sure how best to map this to OpenMCL's 
> internals, or if it would be better to skip the whole thing and just use 
> OpenMCL's existing FFI infrastructure.  On the one hand it would be nice to 
> stay as close as possible to the existing code; on the other, it may be more 
> trouble than it's worth.
>
> The basic idea is (from John Wiseman's comments in his sources):
>
> ========================================================================
> Example expansion #1:
>
> (foreign-function glutcreatewindow ((POINTER CHAR)) INT
>                   "glutCreateWindow")
>
> ==>
>
>
> (PROGN
>   (DEFTRAP-INLINE (_GLUTCREATEWINDOW "_glutCreateWindow")
>     ((ARG1 :POINTER))
>     :LONG
>     'NIL)
>   (DEFUN GLUTCREATEWINDOW (ARG1)
>     (WITH-CSTRS ((#:G2122 ARG1))
>       (REQUIRE-TRAP TRAPS::_GLUTCREATEWINDOW #:G2122)))
>   (EXPORT 'GLUTCREATEWINDOW))
>
>
> Example expansion #2:
>
> (foreign-function glclearindex (FLOAT) VOID "glClearIndex")
>
> ==>
>
> (PROGN
>   (DEFTRAP-INLINE (_GLCLEARINDEX "_glClearIndex")
>     ((ARG1 :SINGLE-FLOAT))
>     NIL
>     'NIL)
>   (DEFUN GLCLEARINDEX (ARG1)
>     (REQUIRE-TRAP TRAPS::_GLCLEARINDEX (FLOAT ARG1 0.0S0)))
>   (EXPORT 'GLCLEARINDEX))
> ========================================================================
>
> Thanks,
>
> -Brent
>
>



More information about the Openmcl-devel mailing list