From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: octal to decimal converter?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 16 Dec 1992 06:30:52 GMT

In article <134349@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> In many instances, the PDP-8 wins hands down on programming for the shortest
>> number of instructions to solve a particular problem, assuming that 12 bits
>> is enough to solve it at all.  In many cases, a highly particularized machine
>
>Are you sure?  I'd have thought it would do well on a word count, but not
>an instruction count.  After all, the whole point of two or three 
>operand orthogonal multiple register architectures like the pdp11, VAX,
>68k etc was to reduce the instruction count by eliminating the load, store
>& register transfer instructions that slowed single operand accumulator
>machines down.  This was quite a win when memories could keep up with CPUs 
>and instruction phases were synchronous, but multiple operand has proven to
>be something of a loser these days when CPU clocks far outstrip memory
>speeds and umpteen things are happening at once in the CPU.  (Large
>orthogonal register files are here to stay however.  Multiple operand hasn't
>gone altogether -- it's still there, as long as the "operands" are registers.)

As I said, this is a general-purpose kind of claim; that eliminates all of 
those advantages, because if you do enough of them, the tricks can't cover all
of the requirements without stumbling around.  The VAX has some instructions
that could take other machines many lines to do, but if you change the
requirement a bit, then it's just as clumsy as others, etc.  In any case, I
think that the alleged overhead is not the biggest cause of problems in a 
more general sense.

>
>Also, doesn't fooling around with the 128 word page size add a bit to the
>instruction count on all but very trivial applications on the PDP-8?

That depends.  Since there is an inherent size boost, then that doesn't seem
to be as important as it first might.  Moreover, the page size just means
that you have to be more efficient at writing the code in the first place,
not that the code can't grow larger out of need.  It is rare that any level
of most problems would be that large.  This just means that a main program
can't call more than about 100 or so subroutines, and each one of them can't
call more than about 100 or so subordinate subroutines, etc.  This of course
assumes that each subroutine can fit in 128 words or less, which is often
the case.  In the rare instance that it can't, there are some tricks to
use to effectively make the code length longer.  This involves such as
page-zero subroutine calls that jump to the body of the routine.  All exits
are no more overhead than the normal return, and there is exactly one JMP I
instruction overhead over the tightest possible code (that *would* have fit
in one page had it been possible).  Such a routine would then be practically
limited to several dozen pages of 128 words if need be.  If page zero locations
are considered too "dear" for this use, then each exit routine can have the
overhead and the call can be made in the normal manner.  Moreover, the
use of page-zero reusable literals for the indirect jump to the routine exit
would save a word on page zero over the former method.  If there really aren't
too many pages to the routine, it would be better to use current-page reusable
literals for the jump pointer, since each could reuse its own copy.  (In the
case of exactly 129-256 word long subroutine, it wouldn't matter.)

Admittedly the original PDP-8 definition of 4096 words total severely cramps
all of this (my proprietary O/S for the -8 runs in this minimal space).  But
all of the newer machines easily get to 32K, and the Omnibus machines can be
expanded to 128K using DEC's memory management unit or 512K using the CESI
version.  (All of these K counts are word counts not bytes, so that's the
same memory as 768K bytes using the CESI method, which is more than the
PC 640K real mode limit.)

Remember, the -8 was meant to be a very small machine; you can run *real*
applications without having gobs of memory.  (Not all, but a surprising amount
of them.)

In any case, the original post was about a 48 word routine or something like
that, so it's not at issue, etc.

cjl

Newsgroups: alt.folklore.computers