Re: [Sbcl-devel] bytecode compilation in warm init

[Martin A. <ma...@at...>]

William Harold Newman wrote:
> 
> On Sat, Apr 14, 2001 at 09:11:18PM +0200, Martin Atzmueller wrote:
> > Obviously, if a CALL-NEXT-METHOD call occurs in a byte-compiled method,
> > %FUNCALLABLE-INSTANCE-INFO is called with a CONS as the first argument.
> > This conflicts with the declared argument type in
> > compiler/generic/vm-fndb, so the patch also fixes this.
> >
> > I'm not too sure, if the patch is correct in that respect. It was
> > somewhat difficult to debug this, and I'd appreciate any opinions.
> 
> I merged the patch into 0.6.11.43, just checked in. My lengthy opinion
> follows:-|.
Ok, thanks a lot.

> In general I think that when a repeated bit of code comes up
> again and again, especially if we find we need a comment to explain
> it, it ought to be factored out and given a mnemonic name. I think

[...]

> but that's a little confusing because given the CMU CL tradition
> of flag names like *BREAK-ON-SIGNALS* and *UP-UP-AND-OUT-ALLOWED*
> (instead of *BREAK-ON-SIGNALS-P*, as I sometimes use in new SBCL
> code, or *BREAK-ON-SIGNALS?*, as I use in my own application code)
> it looks as though *OPTIMIZE-BYTE-COMPILE* is a compiler flag
> to enable byte compilation. So I gave up on the idea for now,
> but I'd like to find something eventually.
Actually I like the idea of SB-INT:*OPTIMIZE-BYTE-COMPILATION* and
SB-INT:*OPTIMIZE-EXTERNAL-DESPITE-BYTE-COMPILATION* that you brought
up in your other mail.
So, what's wrong with (declaim #.*OPTIMIZE-BYTE-COMPILATION*)
and (defun external-function ()
      (declare #.*OPTIMIZE-EXTERNAL-DESPITE-BYTE-COMPILATION*)
 ...)
?

> I didn't like the idea of changing the declaration of
> %FUNCALLABLE-INSTANCE-INFO so that it would try to accept CONSes as
> well as funcallable instances, so I tried to find another way.
[...]
Ok. Thanks for your long analysis. Actually I had done something along
those lines myself, but I arrived at the wrong conclusion, because
the macro expansions itself were ok, and I didn't get that the problem
was related to "speed 0", only.

I'll look into the byte-compilation issue in the next few days. I have
a test that catches external interface functions that are byte-compiled.
So, I should be able to send you a patch for current CVS SBCL, such that
all external functions are natively compiled, soon.

-- 
Martin Atzmueller <ma...@at...>