OpegnGL on OSX PPC
OpegnGL on OSX PPC
Reading the comment on the opengl demo
(http://www.newlisp.org/syntax.cgi?downl ... mo-lsp.txt)
i've read that on ppc i'm not able to see the drawing, and that's true, but could someone explain me why?
It's because float and double are passed correctly only on x86 as i read here?
http://www.newlisp.org/CodePatterns.html#extending
Is there a work around?
(http://www.newlisp.org/syntax.cgi?downl ... mo-lsp.txt)
i've read that on ppc i'm not able to see the drawing, and that's true, but could someone explain me why?
It's because float and double are passed correctly only on x86 as i read here?
http://www.newlisp.org/CodePatterns.html#extending
Is there a work around?
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Actually, I saw on the webpage that trick for doing inline assembly in newlisp.
Lutz, what if you made that more formalized? An officially supported thing instead of a hack? Then we could directly access registers, etc. One thing that held me back from lisp a long time ago was that it seemed too abstract, I didn't see how it could be used to connect directly with the machine. newLisp is the first lisp where I now see that as a possibility.
Now, admittedly, assembly code in newlisp wouldn't be portable. But if an architecture string was put into the binary, you could do conditional assembly based on the platform.
Lutz, what if you made that more formalized? An officially supported thing instead of a hack? Then we could directly access registers, etc. One thing that held me back from lisp a long time ago was that it seemed too abstract, I didn't see how it could be used to connect directly with the machine. newLisp is the first lisp where I now see that as a possibility.
Now, admittedly, assembly code in newlisp wouldn't be portable. But if an architecture string was put into the binary, you could do conditional assembly based on the platform.
cavva:
http://www.agner.org/optimize/calling_conventions.pdf
there is also some general info on this topic on Wikipedia
TedWalther:
this would probably be best written in newLISP, e.g.:
After translating 'body' into the platform assembly language, 'exec' could be used to shell out to the OS and assemble the binary.
This: http://www.newlisp.org/index.cgi?page=Embedded_Binary
could then be used to configure the function as a callable newLISP function.
The same could be done for 'C'. Perhaps that would even be the preferred way to go. In either case you also would have to know the binary object format and calling conventions of the platform OS.
http://www.agner.org/optimize/calling_conventions.pdf
there is also some general info on this topic on Wikipedia
TedWalther:
this would probably be best written in newLISP, e.g.:
Code: Select all
(define-macro (assemble callpattern body)
...
...
)
(assemble (myadd x y) [text]
mov acc, x
add acc, y
ret acc
[/text])
This: http://www.newlisp.org/index.cgi?page=Embedded_Binary
could then be used to configure the function as a callable newLISP function.
The same could be done for 'C'. Perhaps that would even be the preferred way to go. In either case you also would have to know the binary object format and calling conventions of the platform OS.
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
That is probably the best we can do for now. That looks a lot simpler than my concept of separate assembly primitives for each platform and architecture. And yes, the interaction with the outer environment changes with each environment. Yuck. I was thinking of a directive likeLutz wrote:cavva:
http://www.agner.org/optimize/calling_conventions.pdf
there is also some general info on this topic on Wikipedia
TedWalther:
this would probably be best written in newLISP, e.g.:
After translating 'body' into the platform assembly language, 'exec' could be used to shell out to the OS and assemble the binary.Code: Select all
(define-macro (assemble callpattern body) ... ... ) (assemble (myadd x y) [text] mov acc, x add acc, y ret acc [/text])
This: http://www.newlisp.org/index.cgi?page=Embedded_Binary
could then be used to configure the function as a callable newLISP function.
The same could be done for 'C'. Perhaps that would even be the preferred way to go. In either case you also would have to know the binary object format and calling conventions of the platform OS.
Code: Select all
(xorlw r32 r8)
Code: Select all
(asm ...)
Code: Select all
(cdecl ..)
Too much work for now; we'd probably need a government grant to do this. Because really, asm isn't that interesting without a simple and good model for shuttling data out of the registers and into newlisp.
ok, i must admit that i don't have understood the 100% of the replies;
i have little knowledge in C and newlisp, two thing that i'm start using because i want to learn more about programming (right now i'm a java programmer)
So, from the start, what a bridge would look like?
In my mind it would simply a "wrapper", so i've written a little c function to test if i was wrong
(in the include i've removed the "<>", problems with phpbb i think...)
and it doesn't work, probably i'm wrong...
i've also made some test in the area "passing double values" with the tstDouble function, and got strange results... first, the lisp program i'm using:
calling testDouble before glutMainLoop output the correct value, inside 'draw it will output "the number: 16.000000"
have you a little patience for exlain me what's heppening here?
i have little knowledge in C and newlisp, two thing that i'm start using because i want to learn more about programming (right now i'm a java programmer)
So, from the start, what a bridge would look like?
In my mind it would simply a "wrapper", so i've written a little c function to test if i was wrong
Code: Select all
// testlib.c
//
// compiled on OSX with: gcc testlib.c -bundle -o testlib.so -framework OpenGL
#include stdio.h
#import OpenGL/OpenGL.h
#import OpenGL/gl.h
#import OpenGL/glu.h
int testVertex3d(double x, double y, double z)
{
glVertex3d( x, y, z);
return 1;
}
int testDouble(double x)
{
printf("the number: %f\n", x);
return 1;
}
/* eof */
and it doesn't work, probably i'm wrong...
i've also made some test in the area "passing double values" with the tstDouble function, and got strange results... first, the lisp program i'm using:
Code: Select all
(set 'TEST_LIB "/Users/carlo/Desktop/test new lisp C/testlib.so")
(import TEST_LIB "testDouble")
(set 'GLUT_LIB "/System/Library/Frameworks/GLUT.Framework/GLUT")
(import GLUT_LIB "glutInit")
(import GLUT_LIB "glutDisplayFunc")
(import GLUT_LIB "glutCreateWindow")
(import GLUT_LIB "glutMainLoop")
(import GLUT_LIB "glutSwapBuffers")
(set 'argc 0)
(set 'argv1 "")
(set 'argv (pack "lu" argv1))
(define (draw)
(testDouble 1.5)
(print "test")
)
(glutInit (address argc) (address argv))
(set 'id (glutCreateWindow "Test OpenGL"))
(glutDisplayFunc (callback 0 'draw))
(testDouble 1.5)
(glutMainLoop)
have you a little patience for exlain me what's heppening here?
Here is an example how wrap a library for the PPC CPU on older Mac OS X systems, where the normal newLISP FFI does not work because of non cdecl calling conventions:
http://www.newlisp.org/code/wrapper.c
http://www.newlisp.org/code/wrapper.c
thanks a lotLutz wrote:Here is an example how wrap a library for the PPC CPU on older Mac OS X systems, where the normal newLISP FFI does not work because of non cdecl calling conventions:
http://www.newlisp.org/code/wrapper.c