From: Mark McConnell
Subject: "declare" newbie questions
Date: 
Message-ID: <2vouve$gia@coils.cims.nyu.edu>
I have never used (declare ...) before, and I have some elementary
questions.  I am using Austin Kyoto Common Lisp.

(1) My programs use a lot of arithmetic on arrays of fixnum's modulo
a prime p.  Will it speed them up if I declare them to be
(simple-array fixnum), and declare p to be fixnum?  ...I imagine the
answer is "Of course!"  But I got confused by this passage from
Steele's book (2nd ed.):
     One may think of a type declaration (declare (type face bodoni))
     as implictly changing every reference to  bodoni  ...to (the face
     bodoni); ...and implictly executing (the face bodoni) every time
     execution enters the scope of the declaration.
I thought the form (the ...) was intended, at least morally, to check
for errors rather than to promote efficiency.  I don't want my program
to stop and check whether p is a fixnum every time it uses it.

(1') My arrays are part of a structure.  If I declare within the def'n
of the structure that they are (simple-array fixnum), must I also
declare them so in every function that uses them?  I expect the answer
is "yes".

(2) When should you declare something inline ?  I imagine mod should
be inline for my many calls (mod (+ a (* b c)) p) .  Or functions like
ceiling and floor (when should they _not_ be inline?)

My address is ········@coils.cims.nyu.edu .  Thanks for your help!

From: Ken Anderson
Subject: Re: "declare" newbie questions
Date: 
Message-ID: <KANDERSO.94Jul11155129@wheaton.bbn.com>
In article <··········@coils.cims.nyu.edu> ········@coils.cims.nyu.edu (Mark McConnell) writes:

   Path: info-server.bbn.com!news2.near.net!MathWorks.Com!yeshua.marcam.com!zip.eecs.umich.edu!panix!cmcl2!thecourier.cims.nyu.edu!nobody
   From: ········@coils.cims.nyu.edu (Mark McConnell)
   Newsgroups: comp.lang.lisp
   Date: 10 Jul 1994 10:01:18 -0400
   Organization: Courant Institute, New York University
   Lines: 27
   Distribution: world

   I have never used (declare ...) before, and I have some elementary
   questions.  I am using Austin Kyoto Common Lisp.

   (1) My programs use a lot of arithmetic on arrays of fixnum's modulo
   a prime p.  Will it speed them up if I declare them to be
   (simple-array fixnum), and declare p to be fixnum?  ...I imagine the

In addition to what Barmar said in response, you may not want a
(simple-array fixnum) if fixnum's are immediate objects.  This is because
you may get an array of type (simple-array (signed-byte 32) *) instead.
When operating on fixnum stored in such arrays you will wind up doing more
shifting (to convert between fixnum and (signed-byte 32) than you would
otherwise.

k
--
Ken Anderson 
Internet: ·········@bbn.com
BBN ST               Work Phone: 617-873-3160
10 Moulton St.       Home Phone: 617-643-0157
Mail Stop 6/4c              FAX: 617-873-3776
Cambridge MA 02138
USA
From: Barry Margolin
Subject: Re: "declare" newbie questions
Date: 
Message-ID: <2vrsagINNje3@early-bird.think.com>
In article <··········@coils.cims.nyu.edu> ········@coils.cims.nyu.edu (Mark McConnell) writes:
>I have never used (declare ...) before, and I have some elementary
>questions.  I am using Austin Kyoto Common Lisp.
>
>(1) My programs use a lot of arithmetic on arrays of fixnum's modulo
>a prime p.  Will it speed them up if I declare them to be
>(simple-array fixnum), and declare p to be fixnum?  ...I imagine the
>answer is "Of course!"  But I got confused by this passage from
>Steele's book (2nd ed.):
>     One may think of a type declaration (declare (type face bodoni))
>     as implictly changing every reference to  bodoni  ...to (the face
>     bodoni); ...and implictly executing (the face bodoni) every time
>     execution enters the scope of the declaration.
>I thought the form (the ...) was intended, at least morally, to check
>for errors rather than to promote efficiency.  I don't want my program
>to stop and check whether p is a fixnum every time it uses it.

No, a THE form is simply a declaration that only refers to the value of a
single form.  The *effect* of a declaration depends on the implementation.

In some implementations, the interpreter always checks type declarations,
while the compiler uses them for optimizations.  In others, the interpreter
always adds checking code for THE forms.  A compiler might do these if you
compile with a high SAFETY setting.  With a low SAFETY setting and high
SPEED setting, a compiler that added declaration checking code would be
considered quite inferior.

>(1') My arrays are part of a structure.  If I declare within the def'n
>of the structure that they are (simple-array fixnum), must I also
>declare them so in every function that uses them?  I expect the answer
>is "yes".

If all references to array elements are of the form

	(aref (struct-slot structure) ...)

then *ideally* you should only need the declaration of the structure slot;
however, I suspect that several implementations ignore structure slot type
declarations.

But if you do:

	(my-func (struct-slot structure))

then you will definitely need a declaration inside MY-FUNC.  This is
because the compiler won't realize that all calls to MY-FUNC get the array
from STRUCT-SLOT, so it can't put such an assumption into MY-FUNC's
generated code.

>(2) When should you declare something inline ?  I imagine mod should
>be inline for my many calls (mod (+ a (* b c)) p) .  Or functions like
>ceiling and floor (when should they _not_ be inline?)

You don't need to declare built-in functions inline -- the implementation
does that automatically for those functions that it knows how to open-code.
You can declare them NOTINLINE if you want to force function calls for
these functions (this is generally only necessary while debugging, e.g. so
you can trace them).

Note that if you declare MY-FUNC inline in the above example, a good
compiler should be able to make use of the STRUCT-SLOT declaration, and you
wouldn't need to re-declare the argument in the MY-FUNC definition.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

······@think.com          {uunet,harvard}!think!barmar