From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: Is there a PDP-11 (or 8, or...) Emulator?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 15 Sep 1992 08:11:09 GMT

In article <1992Sep9.200035.24633@news.uiowa.edu> dsiebert@icaen.uiowa.edu (Doug Siebert) writes:
>In article <1992Sep09.113100.23379@tpki.toppoint.de> kris@tpki.toppoint.de (Kristian Koehntopp) writes:
>>In <7264@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>>>Eh?
>>>	switch(codeword) {
>>>	case 0:
>>>	    ...
>>>	case 4095:
>>>	    ...
>>>	}
>>
>>Will be a table lookup on many compilers. You might even code
>>this directly:
>>
>>	psw = (func[codeword])();
>
>Heh!  You guys have finally succeeded where cjl failed many times -- you have
>provided a concrete example of a case where assembly will always produce more
>efficient code than C, no matter how good the compiler!  There would overhead
>for a function call to do this, even if the overhead was small, such as on a
>RISC machine with register windows.  But in assembly, one could set it up such
>that the codeword is multiplied and added to a base address, and that address
>is indirectly jumped to.  If you multiply by, say, 32 (you would of course
>shift left five places if this was more efficient, right cjl? ;-) ), you have
>32 words in which to do any calculation necessary to complete the instruction.
>Some space will be wasted, but it'd be damn fast and memory is cheap these
>days.
>
>I can't imagine a C compiler would compile a switch or jump table into
>something like that, no matter how good the optimizer.  But I'd be interested
>to see someone prove me wrong!

Yes, because of the volume of sophomoric posts that have to be dealt with that
side-step the issues, we never get into the more substantive issues.  However,
I won't agree with you, because I myself believe that it's possible for
a compiler to equal good assembly on this specific point.  As a point of fact
however, I'm certain many do a poorer job than the one instruction necessary
to do this on a decent architecture.  (I am assuming that the instruction to
be simulated has been fetched from simulator memory stored in an optimal way
to avoid rotates, which might waste memory which is totally unimportant
because the whole thing fits in 64K space anyway.  The instruction is now
stored into some place used as an offset to provide the proper place to
indirectly branch to, etc.)

A related issue for x86 machines:

The C-based model of the simulator when compiled for 286-only runs faster
on 286, 386, 486 than does the same files compiled for 386 on either 386 or
486.  Some people have made sweeping (and uninformed) generalizations about
how they would assume that 386 mode is "faster" :-).  (Yes, the 286 runs the
286 version faster than the 386 runs the 386 version while the 386 runs the
286 version a little faster than the 286 runs the 286 version.  The 486 runs
both versions faster, but the 286 version significently faster than it runs the
386 version.  BTW, both versions are small enough to fit into the cache memory
of all machines (the 286 doesn't have/need a cache because it has zero-wait
state memory).

cjl