[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiple-value return
- To: Moon@SCRC-TENEX@MIT-MC
- Subject: Re: multiple-value return
- From: Kim.fateman@Berkeley
- Date: Sun, 14 Nov 1982 13:42:00 -0000
- Cc: common-lisp@su-ai
The constant overhead is zero in any reasonable implementation of multiple
values.
We seem to have different ground rules here.
Unless you remove all m-v stuff at compile time, I do not see how you can
write a Lisp that has m-v, which is as fast as a good one without m-v.
Since one can demonstrate the impossibility of total run-time removal,
Lisps with m-v will be slower. And I believe this is whether or not
m-v are used.
If you are arguing that CL, or any "reasonable implementation" of lisp
already pays the run-time cost, that is a different argument.
(E.g. it has been argued that spaghetti stacks are free in interlisp
because the cost has already been paid when implementing other features;
yet overall, interlisp speed suffers somewhat for this generality.)
In summary:
In Franz and probably other VAX Lisps,
compiled access to a value on a stack is implemented
as an addressing mode: PART of a SINGLE INSTRUCTION! If you can show how
to check for multiple-valued-ness without the execution of a single
instruction or the use of any data space, in a language not otherwise
encumbered, I will believe it is free. If it is not free, I suggest
alternatives and justification be considered.
Note, I am not arguing against conceptual simplicity; in fact I
brought up the divide function to make that point. If it is decided
that conceptual simplicity is worth doubling the time to access
values some percent of the time, fine.