[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: in defense of C
In article <firstname.lastname@example.org> 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