medley
medley copied to clipboard
Interlisp
APPLY* vs SPREADAPPLY* vs CL:FUNCALL
What's the difference between these functions?
CL:FUNCALL and SPREADAPPLY* seem to (byte)-compile in the same way: Just the APPLYFN opcode
APPLY* compiles as the sequence CHECKAPPLY* APPLYFN. What does the CHECKAPPLY* do? Is it important?
Of more significance, SPREADAPPLY* does not actually have a function definition, only compiler optimizations. So you can't debug any interpreted code that has a call to SPREADAPPLY* (and FDEVOP and other dispatch macros go to SPREADAPPLY*).
So: Should there be a MOVD somewhere of CL:FUNCALL TO SPREADAPPLY*? Or should SPREADAPPLY* be systematically replaced by CL:FUNCALL everywhere?
I can’t speak to CL:FUNCALL vs SPREADAPPLY* differences.
The CHECKAPPLY* opcode does:
#define OPCHECKAPPLY
do {
register DefCell *defcell;
defcell = (DefCell *)GetDEFCELL68k(TOPOFSTACK & POINTERMASK);
if (!(defcell->ccodep &&
(((TOPOFSTACK & SEGMASK) == 0) || (GetTypeNumber(TOPOFSTACK) == TYPE_NEWATOM)) &&
((defcell->argtype == 0) || (defcell->argtype == 2))))
goto op_ufn;
} while (0)
On Jun 30, 2022, at 7:35 PM, rmkaplan @.***> wrote:
What's the difference between these functions?
CL:FUNCALL and SPREADAPPLY* seem to (byte)-compile in the same way: Just the APPLYFN opcode
APPLY* compiles as the sequence CHECKAPPLY* APPLYFN. What does the CHECKAPPLY* do? Is it important?
Of more significance, SPREADAPPLY* does not actually have a function definition, only compiler optimizations. So you can't debug any interpreted code that has a call to SPREADAPPLY* (and FDEVOP and other dispatch macros go to SPREADAPPLY*).
So: Should there be a MOVD somewhere of CL:FUNCALL TO SPREADAPPLY*? Or should SPREADAPPLY* be systematically replaced by CL:FUNCALL everywhere?
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6DAWOCNUUPCMRZMIQCE5DVRXLFZANCNFSM52KD5NCQ. You are receiving this because you are subscribed to this thread.
The differences seem to be in the handling of Interlisp NLAMBDA spread (NLAMBDA (A B C) ...) and nospread (NLAMBDA U ...) functions. The bytecompiler and relative optimizations around this predate the implementation of common lisp. CL:FUNCALL's definition comes late in the loadup.
I'm not sure how to tell what the UFN is for the CHECKAPPLY* opcode.
It would seem safe to MOVD?(CL:FUNCALL CHECKAPPLY*) when debugging. If the point is to allow interpreted calls to FDEV functions, it's safe to assume that no FDEV operation will be a NLAMBDA Interlisp function so you could change them to call APPLY* (which is defined early in the loadup (but the "fetch" calls require DWIM expressions).
Systematically changing ALL calls to CHECKAPPLY* to CL:FUNCALL might make it more difficult to debug MAKEINIT problems.
With respect to debugging, I think just putting a (MOVD? ‘APPLY* ’SPREADAPPLY*) in LLINTERP is good enough.
If you think it is a bad idea to have that floating around in the released system, it could be in a (DONTCOPY (EXPORTS …)) so it only ends up in EXPORTS.ALL.
On Jul 2, 2022, at 11:29 AM, Larry Masinter @.***> wrote:
The differences seem to be in the handling of Interlisp NLAMBDA spread (NLAMBDA (A B C) ...) and nospread (NLAMBDA U ...) functions. The bytecompiler and relative optimizations around this predate the implementation of common lisp. CL:FUNCALL's definition comes late in the loadup.
I'm not sure how to tell what the UFN is for the CHECKAPPLY* opcode.
It would seem safe to MOVD?(CL:FUNCALL CHECKAPPLY*) when debugging. If the point is to allow interpreted calls to FDEV functions, it's safe to assume that no FDEV operation will be a NLAMBDA Interlisp function so you could change them to call APPLY* (which is defined early in the loadup (but the "fetch" calls require DWIM expressions).
Systematically changing ALL calls to CHECKAPPLY* to CL:FUNCALL might make it more difficult to debug MAKEINIT problems.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/809#issuecomment-1172941409, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJLLDI5BBMSIWRY6OTTVSCC7NANCNFSM52KD5NCQ. You are receiving this because you authored the thread.
There should be a big warning and explanation about why that would be there and under what circumstances it's OK to do that. It doesn't make me feel comfortable.
I’m not sure what the issue is. It’s a function-name that is called only from system code, and it isn’t clear to me why APPLY* or CL:FUNCALL wouldn’t have worked just as well in those internally-defined situations. I am using CL:FUNCALL in the external format interface, should I have been using SPREADAPPLY* ?
But the nuisance problem is that that SPREADAPPLY doesn’t actually have a definition, only a compiler optimizer, and so you can’t debug interpreted code without knowing that you have to define it. Does it matter whether it shares a definition with either APPLY* or CL:FUNCALL, for debugging? It would still compile as it does now?
On Jul 2, 2022, at 12:23 PM, Nick Briggs @.***> wrote:
There should be a big warning and explanation about why that would be there and under what circumstances it's OK to do that. It doesn't make me feel comfortable.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/809#issuecomment-1172948602, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKDBOO6STXJ6CTXXWDVSCJLRANCNFSM52KD5NCQ. You are receiving this because you authored the thread.
cl:funcall's signature is (cl:funcall function-expression arg ...)
cl:apply's signature is (cl:apply function-expression arg ... list-of-args)
in (1988) medley/internal/ABC there's a (P (MOVD? 'APPLY* 'SPREADAPPLY*))
I've been using SYSEDIT and not updating ABC. I'd suggest adding the MOVD? to SYSEDIT and obsoleting ABC
There are a few differences in the variables set up in ABC and SYSEDIT -- we should review them to see exactly what is different and whether we have any understanding of why and which things ought to be set going forward...