Xref: utzoo comp.lang.scheme:1150 comp.lang.lisp:2893 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!orstcs!rutgers!mcdchg!att!cbnewsc!lgm From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka) Newsgroups: comp.lang.scheme,comp.lang.lisp Subject: Re: in defense of C Message-ID: <14236@cbnewsc.ATT.COM> Date: 8 Mar 90 15:49:57 GMT References: <1942@skye.ed.ac.uk> Reply-To: lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) Organization: AT&T Bell Laboratories Lines: 33 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.