gmane.lisp.steel-bank.devel

Re: GSoC 2013 Mentoring - Unicode

Christophe Rhodes — 2013-05-18T21:01:50


I have not come up with a viciously clever indexing scheme for primary
composition; I've contented myself with a fairly simple scheme, and also
not implementing any of the optimizations (obvious or otherwise) in the
normalization area -- not even the various quick-check properties for
the various normalization forms.  I dare say I'll get to them
eventually, but in the absence of substantial impending time I have gone
ahead and merged the normalization work into master.  Still plenty of
low-hanging fruit...

Cheers,

Christophe

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Patch for review: move-to-word/integer and fixnump hack

Douglas Katzman — 2013-05-16T18:33:14

With single-bit fixnum tags, move-to-word/integer can be done in 4 or 5
instructions (including the initial move) versus 7 instructions.
fixnump/signed-byte-64 can be done without use of a constant, sometimes
just 1 instruction, plus the conditional jump or move.
Also fixnump/unsigned-byte-64 could emit 'mov rdx,rdx' or similar because
it used (inst mov tmp value) where it meant (move tmp value).
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Lisp Interface to GC

Alastair Bridgewater — 2013-05-15T23:54:59

If you can guarantee that your memory areas will always have sufficient
space for all of the allocation that you need to do, are willing to run
WITHOUT-INTERRUPTS while allocating into that space, and the space will
contain no external references other than to static space, then I have a
nasty, nasty hack in mind that will run on a stock system (hint: there are
only two words used for the basic allocation and overflow check, and the
region is in a known global location on single-thread systems and in the
thread structure on multi-thread systems, easily poked at via SAP functions
either way).

The requirement to always have sufficient space is so that you don't trip
an allocation overflow "trap" (though they are actually straight calls on
x86oids, but on PPC they are a TWI instruction that the trap handler can
easily recognize).  To alleviate this, we would need to define a way to
hook the overflow trap on a per-region basis to point to the "correct" GC.
Note that it should be plausible to run the trap handler in Lisp with a bit
of care.

The requirement to run WITHOUT-INTERRUPTS is because an interrupt (unix
signal) handler will almost certainly allocate memory, and you don't want
that in your custom memory space.  To alleviate this, modify the interrupt
handling logic to detect that a thread is running with a custom allocation
region, and to somehow bind a normal, empty gencgc region in its place.
And modify your macro to arrange to close the old gencgc region before
setting up your custom region, otherwise the GC could lose track of the old
region. If you also have to enable scavenging of your allocation regions
then this becomes more complex, as you would need to update whatever tracks
the size of the allocated data in your region when binding the gencgc
region into place.

The requirement to not have any pointers to non-static heap data is because
gencgc doesn't know to scavenge your allocation regions.  This should be
straightforward to arrange if you keep track of the regions, by arranging
to scavenge all of the regions at some point after all conservative roots
have been scanned (somewhere near the scavenging of the binding stacks
should suffice; it should be before scavenging newspace).

Depending on which of these restrictions you can live with, this could run
anywhere from an afternoon to a month, as a zero'th order estimate. The
easy restriction to lift is the one about scavenging custom allocation
regions.  I'd actually have to think through the details for the other
two.  There may be a dependency involved (you might need some of the bits
for removing WITHOUT-INTERRUPTS before you can have a lisp-side overflow
handler).

[ snip ]


Now you've got me thinking about pluggable allocation regions and
scavenging strategies... And I already have enough of a project list.

Re: Lisp Interface to GC

Craig Lanning — 2013-05-15T18:41:54

I can give a generic description of what I want to do. I just can't
tell you the specific reason why the application needs to do this.

Basically, the application has a certain object organization that it
needs to be able to keep localized. If we need to drop one of our main
objects so that we can load another one, it would be advantageous to
know that all allocation related to that object is contained within a
known memory block. Then we just declare the block empty and zero it.

I started my Lisp career working on Symbolics Lisp Machines. One thing
that they had was a concept of areas. An area was an allocation block
that could be constrained somehow. For the LispM's some areas held only
cons cells, others held symbol names. Areas could also be excluded from
collection. The aspect I'm interested in is that the user could create
an area, designate whether it should be handled by the GC, what objects
it would hold, and when the contents of the area are no longer needed,
just flush the contents without running any GC.

The "brain-dump" does help. You mentioned a few things that I hadn't
run across yet. I certainly will keep posting info to the list. I'm
interested to run any GC performance tests on whatever I end up
building. I intend to provide the SBCL team with a GC chapter for the
Internals manual at the very least. As I work on the GC changes, any
code that is generally useful, SBCL is welcome to have. I will try to
make sure that any of our "proprietary" changes are really nothing more
than specific configuration of the general GC that I build.

Based on the info from Nikodemus and Alastair, it looks like this will
be a longer term project than I had originally thought. Fortunately,
the application will still work with the existing GC so we're ok for the
time being. Changing the GC would just make the application run more
quickly and more efficiently.

Craig

u are not the intended recipient, please contact the sender by replying to this electronic mail message, along with the destruction of all copies of the original electronic mail message (along with any attachments).

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Lisp Interface to GC

Alastair Bridgewater — 2013-05-15T17:15:20

Are you able to share any details about the sort of changes that you have
in mind?  Or about the use case, even in general terms?


Some years ago (late 2008, maybe), I did some preliminary investigation
into writing parts of the GC in Lisp, although I was mostly focusing on how
to implement things like the dispatch involved in scavenging an object.

If you're planning to implement a GC in Lisp, one of the things to make
sure of is that the code and data that implements the GC is available while
you're running the GC, which is something that seemed very difficult in my
original context, but for what you're doing simply arranging for any data
tables required to be in static space or otherwise pinned and for code
objects to not move would cover the worst of it.  Well, and there are the
FDEFINITION objects to consider, but putting them into static space as well
should work, if you can arrange that (I can think of a couple of approaches
here).

Another aspect to consider is if the GC code itself should be allowed to
allocate memory.  If it shouldn't, then you have to be careful about how
you write the code in order to avoid allocation and you may also want to
figure out how to tell the compiler that any allocation would be an error
(so that you don't backslide during maintenance).

The inline allocation logic itself is actually fairly straightforward,
modulo the overflow handling.  Each thread has an alloc_region (in a
single-threaded system there is a global alloc_region), which contains two
fields of interest to the allocation logic:  the current allocation pointer
and the end of the region.  Everything else in the alloc_region is of
interest to the GC only, and the general layout might well be completely
different for a different GC.

You would also have to deal with the "safepoint" or "pseudo-atomic" logic,
and I haven't really thought overmuch about what would be involved here,
plus there's the whole issue of actually triggering a collection cycle.
And there's the matter of scavenging any interrupt contexts and the various
thread stacks.

And if you're changing the heap layout too drastically, or need to arrange
for certain things to be in certain heap spaces even in the cold-core, you
may well end up modifying genesis (SYS:SRC;COMPILER;GENERIC;GENESIS.LISP),
the program that actually creates the cold-core from a set of
cross-compiled FASLs.

Anyway, I've given the matter a certain amount of thought, and I'm
reasonably confident that I could write SOMETHING that would work, but it
would take a while and I simply don't have a use-case that would make it
worth the effort.

I hope that this brain-dump helps, and would love to be kept "in the loop"
if you decide to go forward with writing a new GC for SBCL in Lisp.  Or
even a new GC for SBCL in C.

Re: Lisp Interface to GC

Attila Lendvai — 2013-05-15T06:01:27


well, it's easy to do it in a system where all that you have is random
access to the underying huge binary number we call memory, and as such
you must manage the object layout yourself.

it's an entirely different story to introduce first class heaps into a
system that also promises transparent memory management for you (GC).

Re: Lisp Interface to GC

Philipp Marek — 2013-05-15T05:32:56

APR has something similar: nested memory pools, and destroying one destroys all nested,
too.

   http://apr.apache.org/docs/apr/1.4/group__apr__pools.html



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

ASDF 3.0.0

Faré — 2013-05-15T05:16:09

Dear SBCL hackers,

I'm proud to announce the release of release ASDF 3.0.0.
Please test it, and include it in SBCL and/or send me patches.
At the request of some #sbcl hackers,
I notably nulled out the *uninteresting-conditions* by default.

I'll have to produce some document explaining the innovations since
ASDF 2.26, 2.000 and/or 1.369, but for now here are just the changes
since 2.33.

As you can see, it's very minor stuff, and ASDF has been mostly stable
these last two months, which is a good sign and the reason why I'm
making an official 3.0.0 release.

I'm also inserting a new digit in the version, so releases will have
three digits:
3.0.0, 3.0.1, etc. will be minor continuations of 3.0. 3.1.0 will be
the next "major"
milestone in a series that preserves backward compatibility, and 4.0 (if ever)
will be the next major release that doesn't.
But I probably won't be there to see it, because I'm moving away from
my Common Lisp job in Cambridge MA
to some new as yet undetermined opportunities in NYC that
are unlikely to see me do Common Lisp for a living, and
I plan to try out different Lisps for a hobby (Racket, Maru, etc.).

* Portability: have *uninteresting-conditions* be empty by default.
Move stuff to *usual-uninteresting-conditions*, unused by default.
Will make the SBCL team happy. Also, fix tests on ABCL.
Fix regression of program-op on ECL, by implicitly linking in UIOP or ASDF.

* UIOP: improvements to slurp-input-stream and thus run-program,
notably accepting T as alias for *standard-output*,
for better backward-compatibility of the deprecated run-shell-command.
New macro with-output-file.

* POIU support enhanced with various tweaks.

* Build cleanup so make and concatenate-source-op create the same asdf.lisp

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]

Re: Lisp Interface to GC

Faré — 2013-05-15T04:26:22

On Tue, May 14, 2013 at 10:53 PM, Attila Lendvai
<attila.lendvai< at >gmail.com> wrote:
The ML-Kit with Region bootstrapped its compiler entirely using such
nested "dynamic extents". Matthew Fluet wrote a nice thesis on the
general topic that generalizes the notion allowing for first-class
such regions.

I'd like to look into it and write a "linear lisp" in the style of
Henry Baker that has some such notion of first-class region. We'll see
after ELS2013. (Admittedly, I said I'd do it after ILC2012, and
instead I wrote ASDF3.)

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There cannot be Ethics without Models of possible behaviors, and Imagination
to explore them. [Corollary: there is no Ethics for an all-knowing God,
but there are Ethics for mostly-ignorant but nevertheless thinking humans]

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Lisp Interface to GC

Attila Lendvai — 2013-05-15T02:53:58

it's somewhat tangential, but it might be worth it in your endeavor to
consider completely reifying heaps as first class objects into the
system.

i think it's much more work than just pluggable GC's, so probably it
will be out of your scope, but nevertheless try to keep this in mind
when shaping the interfaces...

that way the user could have an API to tell that in a dynamic extent
the runtime should use a specific heap, with a potentially different
GC.

or just open a new heap in a dynamic extent and tell the runtime not
to bother with synchronization and GC, because this heap is big enough
for all the allocation that will happen in this dynamic extent, and
can be thrown away in its entirety afterwards.

does anyone know any system that already explored this idea? i guess
the FONC people (Alan Kay, VPRI) have something like this, but very
little info/code is leaking out of them.

Re: Lisp Interface to GC

Craig Lanning — 2013-05-14T22:15:03

Now, that was an eye opener.

Ultimately, what I'd like to do is define a set of functions and global
variables that can be define either in Lisp for a GC implemented in Lisp
or in C for a GC implemented in C (and brought into Lisp via the alien
facility).

The company I work for has a very special use case that I think can be
made easier by rewriting the GC.  I read the opinions about why the GC
is in C instead of Lisp.  I understand them, agree with a few, and
disagree with others.  I think that the changes I need to do to the GC
will be easier to implement if I can do it in Lisp instead of C.

After looking at ALLOCATION/WITH-FIXED-ALLOCATION, it appears that
switching the GC from a C implementation to a Lisp implementation would
be very non-trivial.  Has anyone given any serious thought to what would
need to be done to implement the GC in Lisp?

Craig


 u are not the intended recipient, please contact the sender by replying to this electronic mail message, along with the destruction of all copies of the original electronic mail message (along with any attachments).


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Lisp Interface to GC

Nikodemus Siivola — 2013-05-14T15:09:37

Then the correct answer is ALLOCATION/WITH-FIXED-ALLOCATION; everything
else is more or less negotiable. Ie. the compiler needs to know how to emit
allocation sequences.
On 13 May 2013 19:59, "Craig Lanning" <clanning< at >isc8.com> wrote:

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

SB-GMP status

Stephan Frank — 2013-05-13T21:41:46

Hi everybody,

SB-GMP [1] appears now to be stabilized, so that I'd like to request
comments on what should be changed or expanded for an inclusion as a
contrib. There is already a related interface included in Fricas though
it requires an additional C interface and is not as exhaustive.

There were also a couple of corner cases that popped up during random
testing of which I'm not sure whether/how they are handled by the
Fricas-internal version.

The code has been tested with GMP 5.0.5/5.1 (version 4.x is not
supported) and the latest SBCL on Linux (64 and 32 bit variants). The
DLL-loading case for Windows has not been tested, so I'd appreciate some
feedback on that as well.

Regs,
Stephan

[1] https://github.com/sfrank/sb-gmp

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Lisp Interface to GC

Craig Lanning — 2013-05-13T16:58:53

I'm trying to make of list of all the functions and variables that
someone would need to implement if they wanted to create a new garbage
collector.  Sort of a GC API.

Craig


 u are not the intended recipient, please contact the sender by replying to this electronic mail message, along with the destruction of all copies of the original electronic mail message (along with any attachments).


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

SBCL texinfo documentation and texinfo version5

Christoph Egger — 2013-05-12T16:55:16

Hi folks!

  Seems sbcl's documentation does not work so well with texinfo 5
[0]. Are there plans to get this fixed soonish? I have only the newer
version available for building the debian packages and would love to
update sbcl in usntable and keep the documentation ;-)

    Christoph

[0] http://paste.faui2k9.de/f/ba5a7caaa8b8ed55ad6f9d5850969f04c5c67bb7efd97fe07d190bca5d964af2

Struct groveling

Josh Elsasser — 2013-05-12T15:58:35

Currently a number of C structure definitions are hardcoded in
src/code/unix.lisp. Most notable is struct timeval, which has three
different definitions hiding behind various reader
conditionals.

Rather than make this situation even worse to add support for
OpenBSD's upcoming switch to a 64-bit time_t, I think these structure
definitions should just be groveled like the various C types are:

https://github.com/jre/sbcl/commit/5b10a6c33bf4bb48de0cb4be5a24eaf3b926692e

It's not the ideal solution, but is much better than translating C
into lisp by hand at least :)

I believe that groveler change is correct for all the unixes, but I
wouldn't care to guess what headers one would need to include on win32
to get timeval and timespec headers. Input and testing from win32
users would be appreciated.

Unless there are any objections I'd like to go ahead and commit it
after someone can confirm that it doesn't break windows.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Lisp Interface to GC

Nikodemus Siivola — 2013-05-11T09:53:26

It's a fuzzy boundary; what do you want the list for?

You're missing at least WITH-PINNED-OBJECTS and its machinery.

You're also missing the lisp-side parts of the allocation and
pseudo-atomic machinery (see eg. WITH-FIXED-ALLOCATION in
src/compiler/x86-64/macros.lisp)... but I don't know if that really
belongs on your list or not.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Bad effect of FOLD-INDEX-ADDRESSING

Paul Khuong — 2013-05-11T03:25:36

[frob any cast to take the offset into account ...]

That doesn't look right: other transforms might already have fired based 
on the asserted INDEX type.

I think what we should do is:
1. let DATA-VECTOR-FOO-WITH-OFFSET accept any signed-word as input;
2. insert range checks if necessary.

For 2, I think the best way would be to determine at IR2-conversion-time 
whether we need to check bounds.  It's probably easiest to use an 
IR2-CONVERT optimized to splice in something like a 
DATA-VECTOR-FOO-WITH-OFFSET/CHECK VOP: doing it all in a single VOP 
makes it easier to check for overflow (if necessary) and check bounds.

Paul Khuong

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Re: Bad effect of FOLD-INDEX-ADDRESSING

Nathan Froyd — 2013-05-11T00:51:52

The problem here is that the AREF gets converted to:

(SB-KERNEL:DATA-VECTOR-REF-WITH-OFFSET <array> V <offset>)

and the compiler doesn't know that V's type (which has been asserted
to be an array index) can actually vary based on the value of OFFSET
(31 in this case).

I think the right thing to do here is a DEFOPTIMIZER for
DATA-VECTOR-REF-WITH-OFFSET that looks something like:

(in-package :sb-c)
(defoptimizer (data-vector-ref-with-offset optimizer) ((array index
offset) node)
  (let ((did-something nil))
    (do-uses (n index)
      (when (and (cast-p n)
         (eq (cast-type-check n) t)
         (constant-lvar-p offset)
         (numeric-type-p (cast-asserted-type n))
         (numeric-type-p (cast-type-to-check n)))
    (let* ((value (lvar-value offset))
           (upper-array-limit (1- sb!xc:array-dimension-limit))
           (actual-index-type (modified-numeric-type (cast-type-to-check n)
                             :low (- value)
                             :high (min upper-array-limit
                                    (- upper-array-limit value)))))
      (setf (cast-asserted-type n) actual-index-type
        (cast-type-to-check n) actual-index-type
        (cast-reoptimize n) t
        did-something t))))
    did-something))

But this is getting into parts of IR1 that I don't know very well,
hence the overzealous checking.  I haven't tried bootstrapping with
this, but it does have the expected effect on the assembly:

; 0621799C:       40F6C601         TEST SIL, 1                ;
no-arg-parsing entry point
;       A0:       752A             JNE L0
;       A2:       488BCE           MOV RCX, RSI
;       A5:       4883F9C2         CMP RCX, -62
;       A9:       7C21             JL L0
;       AB:       488BCE           MOV RCX, RSI
;       AE:       4883F93E         CMP RCX, 62
;       B2:       7F18             JNLE L0
;       B4:       488BCE           MOV RCX, RSI
;       B7:       488B0572FFFFFF   MOV RAX, [RIP-142]         ; #(0 0 0 0
                                                              ;   ...)
;       BE:       488B9488F9000000 MOV RDX, [RAX+RCX*4+249]

Those more experienced in IR1...does the above look plausible?  Are
there better ways to express what we want to do here?

-Nathan

On Fri, May 10, 2013 at 5:31 PM, Douglas Katzman <dougk< at >google.com> wrote:

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

Bad effect of FOLD-INDEX-ADDRESSING

Douglas Katzman — 2013-05-10T21:31:15

Hi developers,

Below is a minimized version of some code which elicits a compiler bug
preventing access to half of this constant array.
-31 to -1 are good arguments to FOO - they should index the zeroth element
of the array onward.

* (defun compute-my-array () (make-array 63))

* (defun foo (v)

  (if (typep v '(integer -31 31))

      (let ((index (+ v 31)))

        (aref #.(compute-my-array) index))

      (error "Bad val: ~S" v)))

* (foo -31)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {10029F94B3}>:
  The value -31 is not of type (MOD 4611686018427387901).

The disassembly is illuminating:

; disassembly for FOO
; 02AB99EC:       F6C301           TEST BL, 1                 ;
no-arg-parsing entry point
;      9EF:       7543             JNE L1
;      9F1:       488BCB           MOV RCX, RBX
;      9F4:       4883F9C2         CMP RCX, -62
;      9F8:       7C3A             JL L1
;      9FA:       488BCB           MOV RCX, RBX
;      9FD:       4883F93E         CMP RCX, 62
;      A01:       7F31             JNLE L1
;      A03:       488BCB           MOV RCX, RBX
;      A06:       4883F900         CMP RCX, 0
;      A0A:       7C18             JL L0
;      A0C:       488BCB           MOV RCX, RBX
;      A0F:       488B056AFFFFFF   MOV RAX, [RIP-150]         ; #(0 0 0 0
...)
;      A16:       488B9488F9000000 MOV RDX, [RAX+RCX*4+249]

The optimization of using the SIB addressing mode to fold in the constant
offset of 31 has not informed the bound check that the valid range of the
index (register RCX) is -31 to 31 - and the explicit typep check has
already concluded that that it is exactly in that range.  The "CMP RCX, 0 /
JL L0" is bogus.  (L0 is the label for the error trap)

I haven't yet checked how this affects SVREF in the latest code which
bypasses some parts of the AREF transforms.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Faster FIND and POSITION in unsafe code

Douglas Katzman — 2013-05-08T23:41:31

to answer two of my own questions:

1) In the deftransform of eql it's a mistake to use COMMUTATIVE-ARG-SWAP to
perform the switching of x,y since the latter might call give-up.
Probably better to write out the should-args-be-swapped test by hand:

diff --git a/src/compiler/srctran.lisp b/src/compiler/srctran.lisp
index f6369e6..89b2f5a 100644
--- a/src/compiler/srctran.lisp
+++ b/src/compiler/srctran.lisp
< at >< at > -3715,10 +3715,10 < at >< at >
         ((and (csubtypep x-type char-type)
               (csubtypep y-type char-type))
          '(char= x y))
-        ((or (fixnum-type-p x-type) (fixnum-type-p y-type))
-         (commutative-arg-swap node))
         ((or (eq-comparable-type-p x-type) (eq-comparable-type-p y-type))
-         '(eq x y))
+ (if (and (constant-lvar-p x) (not (constant-lvar-p y)))
+     '(eq y x)
+     '(eq x y)))
         ((and (not (constant-lvar-p y))
               (or (constant-lvar-p x)
                   (and (csubtypep x-type y-type)

2) the index variable isn't actually elided in the fast code, it's that (a)
I left out an INCF and (b) you no longer see a call to GENERIC-+
That's what I get for testing only with calls that don't need the index...


On Wed, May 8, 2013 at 5:54 PM, Douglas Katzman <dougk< at >google.com> wrote:

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________
Sbcl-devel mailing list
Sbcl-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel