Since my last post I've got to the point where I have written a simple
FFI binding to the PTC.
(See: http://sourceforge.net/projects/tinyptc/).
I'm using sbcl and it's sbcl-alien interface to do the binding (I'm
not yet confident enough for the UFFI or to package it with ASDF). i
chose it for blinding simplicity and an ideal starting point.
I have decided I want to tackle writing a simple software rednderer in
lisp as my next educational lisp project - I want to know what fast,
low - level lisp looks like..
I have a number of questions that could probably be solved by perusal
of the manual, but I'd like to get more experienced lispers opinion of
the "right way" to do these things.
Firstly, how do I do low level bit twiddling in LISP: logior / logiand
seem a good way? The PTC gives me a freme buffer of 32 - bit unsigned
ints - how do I make sure they are operating only on 32 bit int's that
represent pixels efficently. I'm planning on having a (defun
make-pixel (red green blue alpha)) (defun get-red/blue/green/aplpa)
that return unsigned 32 bytes and setf'able unsigned bytes
respectively..naively I'd assume something like
(defun make-pixel (red green blue alpha)
(logior red (* green 255) (* blue (* 255 255)) (* green (* 255 255
255) (* (alpha (* 255 255 255 255))))
..but how do I ensure it's optimised for the right types and constant
folding gets done? It'd be nice to inline it - that's (declaim
(make-pixel inline)) isn't it? Or is it (proclaim (make-pixel
inline))? What's the difference?
Secondly - if I have a generic routine that returns and ascii
character can I plug it into the reader part of REPL? I'd like to
create a simple vector fot and capture key presses and feed them into
the repl so I can type lisp into my graphical environment. Is this
possible?
I'm also curious about things I keep seeing in portable lisp code
things like #+sbcl #-cmucl to include and exclude code for specific
lisps? Is this for a lisp preprocessor?
I'm reading the FM and I'll get there eventually: I'm just hoping some
of you experets will take pity on a noobi still wrestling to get free
of the Bjarne Monster :) Please..:->
TIA,
John Connors.
http://badbyteblues.blogspot.com
"Nothing is more inevitable that the mistake that has just happened."
·····@yagc.ndo.co.uk (John Connors) writes:
> Firstly, how do I do low level bit twiddling in LISP: logior / logiand
> seem a good way? The PTC gives me a freme buffer of 32 - bit unsigned
> ints - how do I make sure they are operating only on 32 bit int's that
> represent pixels efficently. I'm planning on having a (defun
> make-pixel (red green blue alpha)) (defun get-red/blue/green/aplpa)
> that return unsigned 32 bytes and setf'able unsigned bytes
> respectively..naively I'd assume something like
>
> (defun make-pixel (red green blue alpha)
> (logior red (* green 255) (* blue (* 255 255)) (* green (* 255 255
> 255) (* (alpha (* 255 255 255 255))))
I'd rather use LDB and DPB.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon <····@mouse-potato.com> writes:
> ·····@yagc.ndo.co.uk (John Connors) writes:
> > Firstly, how do I do low level bit twiddling in LISP: logior / logiand
> > seem a good way? The PTC gives me a freme buffer of 32 - bit unsigned
> > ints - how do I make sure they are operating only on 32 bit int's that
> > represent pixels efficently. I'm planning on having a (defun
> > make-pixel (red green blue alpha)) (defun get-red/blue/green/aplpa)
> > that return unsigned 32 bytes and setf'able unsigned bytes
> > respectively..naively I'd assume something like
> >
> > (defun make-pixel (red green blue alpha)
> > (logior red (* green 255) (* blue (* 255 255)) (* green (* 255 255
> > 255) (* (alpha (* 255 255 255 255))))
>
> I'd rather use LDB and DPB.
Especially as (1) all those 255s should be 256s and (2) green
has been repeated, a fact that might have become obvious if
the bit positions were made explicit :-). (There's a missing
paren, too, but maybe the editor used by John's posting software
doesn't do paren-matching.)
--
Gareth McCaughan
.sig under construc
·····@yagc.ndo.co.uk (John Connors) writes:
> I'm also curious about things I keep seeing in portable lisp code
> things like #+sbcl #-cmucl to include and exclude code for specific
> lisps? Is this for a lisp preprocessor?
See this paper by Christophe Rhodes:
Maintaining Portable Lisp Programs
http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/features.pdf
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
·····@yagc.ndo.co.uk (John Connors) writes:
> Firstly, how do I do low level bit twiddling in LISP: logior / logiand
> seem a good way? The PTC gives me a freme buffer of 32 - bit unsigned
> ints - how do I make sure they are operating only on 32 bit int's that
> represent pixels efficently. I'm planning on having a (defun
> make-pixel (red green blue alpha)) (defun get-red/blue/green/aplpa)
> that return unsigned 32 bytes and setf'able unsigned bytes
> respectively..naively I'd assume something like
Having unsigned 32 byte returns may not really be possible in general.
That is because any value returned by an external interface to a
function would need to be somehow tagged so that its type is manifest.
There really isn't any way around this. Now, some compilers will
optimize functions to provide multiple entry points to allow the
optimization for particular argument types. CMUCL is particularly good
at this.
> (defun make-pixel (red green blue alpha)
> (logior red (* green 255) (* blue (* 255 255)) (* green (* 255 255
> 255) (* (alpha (* 255 255 255 255))))
>
> ..but how do I ensure it's optimised for the right types and constant
> folding gets done?
Well, you really can't ensure this in general -- since Lisp compilers
are free to pick and choose exactly what sorts of optimizations they
do. The best you can do is look at things with DISASSEMBLE and see what
happens with the type declarations.
> It'd be nice to inline it - that's (declaim
> (make-pixel inline)) isn't it? Or is it (proclaim (make-pixel
> inline))? What's the difference?
Actually, that would be (declaim (inline make-pixel))
or (proclaim '(inline make-pixel))
DECLAIM is a macro and doesn't evaluate its argument, PROCLAIM is a
function and does. Also DECLAIM is best used in files for compilation,
since it expands in a way tha insures the declaration is known at
compile time. When possible, always choose DECLAIM.
BTW, the way declarations work is the type or other property being
declared is given first. That allows one to have a single declaration
apply to multiple symbols:
(declaim (inline make-pixel frob-pixel reverse-pixel))
> Secondly - if I have a generic routine that returns and ascii
> character can I plug it into the reader part of REPL? I'd like to
> create a simple vector fot and capture key presses and feed them into
> the repl so I can type lisp into my graphical environment. Is this
> possible?
Well, it's certainly possible, but it would also be pretty easy to write
your own REPL. The tricky part is arranging things with threads so that
you don't hang while reading, waiting to get to the last close paren.
> I'm also curious about things I keep seeing in portable lisp code
> things like #+sbcl #-cmucl to include and exclude code for specific
> lisps? Is this for a lisp preprocessor?
No. It is part of the integrated Lisp reader.
See CLHS sections 2.4.8.17 "Sharpsign Plus" and 24.1.2 "Features".
--
Thomas A. Russ, USC/Information Sciences Institute