[Gcl-devel] Re: Back to July 2: inferring fixnums

[Camm Maguire]

Greetings, and thank you as always for your valuable feedback!

Robert Boyer <address@hidden> writes:

> Here are some rambling thoughts that may be relevant to a remark
> you made of July 2:
> 
> > There is one key area, though, which I feel the compiler should be
> > able to get fixnum declarations by itself, and that is when the var is
> > used as a sequence index (i.e. in aref or nth).  Lisp seems to have
> > this notion of 'safe and 'unsafe code, which I loosely understand as
> > "check everything and signal an error on any type mismatch",
> > vs. "you've written the code correctly so it won't throw an error, now
> > I can make assumptions about your variables".
> 
> I believe that when an ANSI Common Lisp is executing, it can always assume
> that arguments to AREF consist of an array of the right dimensions and of
> fixnums that are within bounds.  Here is why.  In the chapter on arrays,

This is my understanding too from an earlier conversation with Paul
Dietz, though we may not be implementing this at safety level 3 (have
not checked to be sure.) We basically wrap all aref calls in a let
binding of the index with an appropriate declaration  -- the optimizer
does the rest and inlines the reference as c pointer dereference. You
can trace compiler::aref-expander after loading gcl_cmpeval.lsp if you
want to see the internals.

> chapter 15, there are very few references to signaling errors.  Those that
> MUST be caught involve: fill-pointers, vector-pop, and vector-push-extend.
> Those that that SHOULD be caught (that is, at least when safety is 3),
> involve adjustable-array-p, array-dimensions, array-element-type,
> array-has-fill-pointer-p, array-rank, and array-total-size.  Note that aref
> is not among those functions!  This does not mean that all aref calls can be
> super fast.  For one thing in general an array might be displaced, so one
> always has to indirect through a displacement.  svref (or the equivalent (the

I think (from memory only) that GCL overlays the C pointer in the
displaced array structure so that even such references are optimized
in like fashion. 

> simple-vector ...) declaration) means that one may be able to make an array
> reference c-fast, i.e., not worry about the displacement.  Of course, aref is

We also rewrite multi-dimension array references as row_major-aref
calls with the dimension calculated inline in fixnum arithmetic, if
all is working right.  Can trace compiler::array-dimension-expander
and compiler::array-row-major-index expander if interested.

> always possibly slowed down by the fact that the array may hold objects of a
> specialized type, e.g., fixnums, so that some conversion of data going in or
> coming out may be necessary.

Yes -- this is what I was really getting at.  At safety 0, if a
constant binding is used as an aref index, we shuld be able to declare
it appropriately throughout the whole binding.

> 
> So much for ANSI, as I read it.
> 
> Lisp tradition and KCL/GCL go back a lot further than that.
> 
> Perhaps the greatest and most glorious thing about the Lisp machine was that
> it caught every error, period!  Long live the beautiful memory of the Lisp
> machine.  May it come back some day soon.  Doesn't seem likely, though.
> 

It will obviously be quite a while if GCL or the like can ever
approach this level.  At least with the open source model, what ever
is achieved will never go away if a proprietary business model goes
belly up.

> Unfortunately, when Lisp machines were still costing tens of thousands of
> dollars, Motorola and Intel started making cheap chips on which you could run
> a "crummy" Lisp pretty darn fast.
> 
> The sickening consequence of not using a Lisp machine is that one is awash in
> a sea of doubt about precisely when errors are going to be signaled and about
> when time is being spent checking for things that it might be more efficient
> not to check for in certain circumstances.
> 

Agreed -- this is never completely clear to me either.  I hope to
summarize someday after studying the code a bit more.  safety 1
enables argument checking, safety 2 disables inline-unsafe, and safety
three has no c function calling at all, it appears.

> In KCL/GCL, it has been the tradition that if the programmer put in explicit
> declarations that arguments to aref were simple arrays of specific types and
> fixnums, and if safety was 0 and speed was 3, then aref turned into very fast
> in-line C, C which could clobber any part of memory.
> 

Still true I believe, though the guards in the interpreter and
compiler against passing incorrect types might be a bit better now.

> I believe GCL could reasonably be changed so that when SAFETY=0, the compiler
> could assume that indices to arrays are inbound fixnums.  I believe this is
> ANSI complaint.  It just differs from the GCL tradition, which went with the
> tedious but conservative "well the programmer could always put in enough
> declarations to get that effect."
> 

There are actually two separate concepts in the compiler, the variable
type, which is any lisp type, and its kind, which basically refers to
its representation in C.  A variable of type fixnum, can be either of
kind fixnum or of kind T, for example.  The compiler will coerce these
as required given the function call proclamation at hand, etc.

Take care,

> Bob
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah