Erik Naggum wrote:
> * Erik Naggum
> | (yes, CPU's _do_ have instructions that C compilers don't use.)
> * Donal K. Fellows
> | I take it you don't work in computer hardware design, and haven't even
> | looked at the field for at least 10 or 15 years, since that last
> | statement is plain wrong. Maybe Vaxes had a "Reverse Bit Shift, Cast
> | to Type and Catch Fire if the Programmer is Stupid" instruction (with
> | mnemonic RBSCTCFPS :^) but technology is substantially advanced since
> | then. RISC CPU's have only the instructions that are measured as
> | being needed in practice, and virtually all new designs are RISC (with
> | the notable distiction of the ix86 line of processors). In future, try
> | to check your facts, and especially those that have been contradicted
> | by people (with good reason) for loads of years...
> the SPARC architecture has several instructions that C compilers doesn't
> use, but which are convenient with type-tagged languages. the _fact_ is
> that it has an the instruction, with Sun's recommended mnemonic "taddcctv",
> that is specifically useful in Lisp, and specifically unused in C. other
> instructions are also measurably useful in languages _other_ than C.
Ok, so you found one example on one CPU. Great. Do you have any
Because when you say 'cpu's XXX' it means that most or all cpu's have
feature. But there's more..
> C is _not_ the be-all, end-all of programming languages and C is _not_ the
> universal assembler that some would like it to be. that you cannot even
> put this instruction to use without a lot of prior work that you also have
> a hard time doing in C, shows that the SPARC designers thought of more than
> increasingly myopic C crowd.
I would think it's better to be myopic than to have your eyes shut.
The fact is, most newer chips are not designed for lisp at all. The
operations certianly are not based on type.
Accusing someone of being stupid, and making stupid arguments oneself
does make someone look like a fool though; though it's not who you're
> but to demonstrate the point with a real-life example, take the following
> (silly) function, compiled by Allegro Common Lisp for Unix on a SPARC:
> (defun foo (x y) (declare (fixnum x y)) (+ x y))
> 0: cmp %g3, #x2
> 4: tne %g0, #x13
> 8: taddcctv %g0, %g1, %g0
> 12: sra %o0, #x2, %o0
> 16: sra %o1, #x2, %o1
> 20: add %o0, %o1, %o0
> 24: ld [%g4 + 135], %g2 ; fixnum-or-bignum
> 28: jmp %g2 + 0
> 32: xor %g0, #x1, %g3
> the intelligent reader will recognize that this function sports a few
> features not commonly found in C compiler output: the number of incoming
> arguments is in a register, there are traps to handle error conditions, and
> it concludes with a jump to a function instead of a call and return. (no
> programmer knowledgeable of pipelines RISCs will wonder why the jmp occurs
> before the argument count is stored into %g3.)
Once again, making broad allegations of stupidity doesn't make you look
smart when you say foolish things.
I'm glad that the usual C compiler will not produce the preceeding
I'm glad the usual java compiler will not produce the preceeding code.
First of all, it specifies fixnums, but appears to be performing the
for all types--nice optimization. And testing the number of parameters
necessary due to the structure of lisp--berating C compilers for not
doing this is silly.
Also, it appears that the whole function ought to be compiled to a
single tail-recursive jump or inlined for that matter.
> I welcome suggestions on how to accomplish the _exact equivalent code_ from
> C source code. if this cannot be done, could Donal K. Fellows then accept
> that some CPU's (1) do have instructions that C compilers don't use, and
> (2) that he shot his mouth off? I assume both, so let's return to our
> regular program.
Perhaps you could try counting to 100 before responding to someone
on the net? The time might be used to actually think about what you're
which might work wonders.
> Bastard Sex Therapist from Hell: "Read the F*cking Manual!"
A freudinan message??