[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