lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/05/90)
[I have added comp.lang.lisp to the newsgroup list.] In article <1903@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >Besides, since when does Lisp make such checks. Sure, most Lisps >probably check array bounds, but most do not check whether CAR and >CDR are really being applied to conses (just for example). On Lisp-directed processor architectures, dynamic type checks are (typically) uniformly applied, often in parallel with the computation of the most-common-case result. On conventional (C- and Fortran-directed) architectures, Common Lisp vendors typically offer a range of safety/efficiency tradeoffs. One can then choose a tradeoff according to the needs, or the stage of development, of one's application. One of the most important quality measures of a Common Lisp compiler is the level of safety it supports without an undue sacrifice in execution speed. The better CL implementations score quite highly on this scale, especially on newer processor architectures such as SPARC. For example, the better compilers indeed ensure that CAR and CDR are only applied to lists, without a loss of execution speed and even though a CL implementation must permit one to apply CAR and CDR to the symbol NIL. >As GJC notes, Lisp programmers have developed ways to deal with >this, as have C programmers. I venture to say that generally, Common Lisp programmers compile unsafe code only when they have to (e.g., when the absolute maximum execution speed is called for, or when forced by circumstances to use an inferior CL compiler), not because they like it. Unsafe code is not an integral part of the culture or a badge of pride as, one might say, it seems to be for C. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
jeff@aiai.ed.ac.uk (Jeff Dalton) (03/07/90)
In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes: >One of the most important quality measures of a Common Lisp >compiler is the level of safety it supports without an undue >sacrifice in execution speed. The better CL implementations score >quite highly on this scale, especially on newer processor >architectures such as SPARC. For example, the better compilers >indeed ensure that CAR and CDR are only applied to lists, without >a loss of execution speed and even though a CL implementation must >permit one to apply CAR and CDR to the symbol NIL. You say this as if it were typical of better compilers on machines other than SPARCs, such as, maybe, 68020s. Can they really have safe CARs and CDRs, without loss of speed, on a 68020? If so, I would expect that safety to remain even if I set saftey=0, but that doesn't seem to be what happens. Moreover, how many of the SPARC compilers can do this? I suspect it's only one or two of them. -- Jeff
pepke@gw.scri.fsu.edu (Eric Pepke) (03/08/90)
In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes: > You say this as if it were typical of better compilers on machines > other than SPARCs, such as, maybe, 68020s. Can they really have safe > CARs and CDRs, without loss of speed, on a 68020? I don't know about the internals of any LISP system other than the ones I have written. In the one I am now writing for the 680x0, one can have safe CARs and CDRs without loss of speed. One has to test to see if it is (1) a valid list, or (2) NIL, anyway. So, one just makes that a test for (1) a valid list, or (2) anything else. In my system, that's testing a single bit. In case 1, do the job. In case 2, return NIL. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/08/90)
In article <1942@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <14112@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes: > >One of the most important quality measures of a Common Lisp > >compiler is the level of safety it supports without an undue > >sacrifice in execution speed. The better CL implementations score > >quite highly on this scale, especially on newer processor > >architectures such as SPARC. For example, the better compilers > >indeed ensure that CAR and CDR are only applied to lists, without > >a loss of execution speed and even though a CL implementation must > >permit one to apply CAR and CDR to the symbol NIL. > >You say this as if it were typical of better compilers on machines >other than SPARCs, such as, maybe, 68020s. Can they really have safe >CARs and CDRs, without loss of speed, on a 68020? If so, I would >expect that safety to remain even if I set saftey=0, but that doesn't >seem to be what happens. Moreover, how many of the SPARC compilers >can do this? I suspect it's only one or two of them. You may be right. The particular compilation "trick" I've seen relies on the processor hardware to trap a fullword-size reference to a machine address not aligned on a fullword boundary. But if, as I think is true, the 68020 silently satisfies unaligned pointer references, this particular technique will indeed be ineffective on that architecture. All the more reason to upgrade to a RISC-based computer... Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
moore%cdr.utah.edu@cs.utah.edu (Tim Moore) (03/09/90)
In article <542@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes: >In article <1942@skye.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes: >> You say this as if it were typical of better compilers on machines >> other than SPARCs, such as, maybe, 68020s. Can they really have safe >> CARs and CDRs, without loss of speed, on a 68020? > >I don't know about the internals of any LISP system other than the ones I >have written. In the one I am now writing for the 680x0, one can have >safe CARs and CDRs without loss of speed. One has to test to see if it is >(1) a valid list, or (2) NIL, anyway. So, one just makes that a test for >(1) a valid list, or (2) anything else. In my system, that's testing a >single bit. In case 1, do the job. In case 2, return NIL. > That's the loss of speed that Jeff is talking about. If you assume that the argument to CAR or CDR is a cons cell or NIL and you have a low-tags type scheme, then those operations are 1 instruction long on a 680x0 (or even less: a base-displacement addressing mode). The NIL case can be handled with a bit of symbol table trickery. A "safe" C{A,D}R that checks its argument is going to be slower. >Eric Pepke INTERNET: pepke@gw.scri.fsu.edu >Supercomputer Computations Research Institute MFENET: pepke@fsu >Florida State University SPAN: scri::pepke >Tallahassee, FL 32306-4052 BITNET: pepke@fsu > Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters
gateley@m2.csc.ti.com (John Gateley) (03/09/90)
In article <542@fsu.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes: |In the one I am now writing for the 680x0, one can have |safe CARs and CDRs without loss of speed. |So, one just makes that a test for |(1) a valid list, or (2) anything else. In my system, that's testing a |single bit. In case 1, do the job. In case 2, return NIL. |Eric Pepke INTERNET: pepke@gw.scri.fsu.edu But this is NOT safe: consider the following code: (defun foo () (if (car 3) (tear-down-the-berlin-wall) (bomb-the-soviets))) Your implementation will bomb the soviets! I understand that your implementation will not crash due to garbage pointers, but I don't think "safe" is a good term to apply here. John gateley@m2.csc.ti.com
pepke@gw.scri.fsu.edu (Eric Pepke) (03/09/90)
Sorry; I misunderstood the controversy. I feel like Emily Latella. "Never mind!" Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.