[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Talking to a rock.
- To: JONL at MIT-MC
- Subject: Talking to a rock.
- From: Alan Bawden <ALAN at MIT-MC>
- Date: Thu, 18 Sep 80 20:30:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 18 September 1980 16:30-EDT
Date: 18 SEP 1980 1618-EDT
From: JONL at MIT-MC (Jon L White)
Date: 18 September 1980 16:02-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: (LDB 0203 Y) versus (LDB X Y)
. . .
(ldb 0203 y) expands into (boole 1 (lsh y -2) 7)
(ldb x y) expands into (*ldb (lsh x 30) y)
I don't see anything that looks like (*ldb ppss_30 ...)
so I don't see
how anything has been saved.
Are you asleep today! How do you think the "7" got generated in the line
"(ldb 0203 y) expands into (boole 1 (lsh y -2) 7)"
What difference does it make where the 7 comes from??
*LDB is not a user-available function -- it exists only as a stop-gap
until the compiler open-codes LDB. (Although it is true now that *LDB is
never handed a "constant" arg, that's not how it was when *LDB was first
coded -- the conversion to BOOLE is a recent innovation -- but the whole
existence of *LDB depends on whether or not the compiler knows how to
open-code LDB). Anyway, why are you worrying about this -- is it slowing
your program down by 0.25%?
I don't have to worry about it. I LAPed up a LDB and a DPB of my own
a long time ago and I still don't have any reason to flush them.
What I am amazed by is the totally hairy "stop gap" measures that
don't gain anything!