Re: Kill the SCM_NIMPs

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 6 Jan 2000, Mikael Djurfeldt wrote:

> Well, I hope it should be clear by now that
[...]

I apologise that my mail sounded as if I wanted to pick on anybody.  It
was not meant that way.  As I see it, the points that you state are well
understood and agreed on.  Maybe (as a non native english speaker) I
should be more careful about trying to be humourous.

> Regarding the difference in efficiency between SCM_NIMP and
> SCM_NNULLP, I don't think it is of any relevance.  Both usually
> generate one instruction.
> 
> (If there is any difference at all, my guess is that SCM_NIMP is
> faster, since SCM_NNULLP needs to read an immediate 32-bit value for
> the comparison while SCM_NIMP uses a smaller value.  I do think
> bitoperations are quite efficient on most CPUs.  In any case they were
> at the time SCM was written.)

Maybe, but for SCM_EOL an immediate 16-bit value should be
sufficient.  However, I have to admit that, again, the performance
implications of the change are not obvious.  Since the change may
potentially cause performance degradation, it would probably be best to
test that first.

> If you think I used SCM_NIMP in order to gain efficiency that's
> definitely not the case.  This is not a time critical part of the
> interpreter.

It was just the very first file that has an example for a place where it
is used the 'wrong' way.  There are probably still a lot of places where
it just can't be replaced sensibly.  However, there seems to be consensus
about the fact that it makes sense to replace SCM_NIMP by macros that
reflect the semantics more appropriately, given that we don't have to pay
for it in terms of performance.

So long,
Dirk Herrmann