Newsgroups: alt.folklore.computers
Subject: Re: octal to decimal converter?
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 24 Dec 92 00:30:07 GMT
Distribution: world
Organization: The Wolery

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
> But the VAX has to do all sorts of odd-sized instruction fetches that evade
> many forms of optimization while the -8-type form is easily improved on.
> As to whether or not you need to squeeze or not depends on the application.
> Just because there is the potential of a large address space doesn't mean
> that squandering it is useful.  There are no VM -8 systems, as all of the
> address space is quite real.  How much performance lossage is due to the
> excessively large program swapping itself?

> I wouldn't put the -11 and the VAX into that statement above.  I think you'll
> find that the -11 programs are longer; your own examples were -11-ish and you
> had to resort to VAX-specific tricks to keep up with the -8.  MOV instructions
> can be useful in certain places, but if it's the only mechanism available, it
> will often get in the way.

Not really; the programs weren't particularly specific to either architecture.
However, both architectures are hard to bum code the same way as you can on
a PDP-8, because loading an immediate constant is just as long as loading a
constant that happens to also be an instruction.  More bits in the instructions
reduces the chance of a useful constant being found in the instruction 
stream as well.  On a VAX, small literal (<64) operands are a single byte,
however bummed code could potentially get large literals from the code with
a byte offset reference; the problem being finding one.  All pdp11 operands
are words, so there's no scope for operand bumming whatsoever; the best you
can do is put common literals in a register.

The VAX's oddball byte size instructions mean that the most common
instructions (register to register and small constant to register ops, test,
branch etc) fit into two or three bytes; to maintain the same functionality
in a word-oriented 32 bit architecture you'd need 32 bits per instruction. 
It is an attempt to build a 32 bit machine without too much bloat directly
related to the architecture.  (What software types have done with it since
is quite a different matter of course!)

As for odd-sized fetches, yeah, well we know about that.  VAX is optimised
for space, not speed; it gets speed out of fast brute-force silicon these
days. 

Still, if you feel that way inclined, have a squiz at some of the RISC chip
optimisation stuff -- you don't need to bum for space anymore, but going
for speed (which often means keeping the instriction count down) makes for
some fun stuff.  There's a whole chapter in the Alpha book on making code
go fast.

> All that proves is that there are small-scale almost-no peripherals PDP-8's.

No, it was a comparison of electronics density.  The DECmate has equivalents
of most of the VAX's hardware (serial, disk, video), although less of it.
The "equivalent" VAX would have just the CPU and it's onboard 1MB of memory,
a DZQ11, and RQDX3 (losing the video, but the two aren't equivalent anyway).
That's three boards (one quad, two doubles), in an older and more expandable
box.  It'd give five serial ports, and a more flexible (and faster) disk
controller as well.  Try opening a MicroVAX 2000 sometime -- there's not much
more PCB real-estate under the bonnet than on the DECmate, it's in much the
same box and has a few more serial ports & memory than a DECmate.

> All that proves is that DEC didn't put any effort whatsoever in adding the
> stuff onto the -8, not any inherent limitations of the architecture.

Somehow, I don't think anyone would buy a PDP-8station these days.  That
architecture is very difficult to do a decent compiler for.  You've seen
how much folk throw up their hands in horror at the x86's 64k "pages"; now
translate that to 4k pages and smaller offsets in the hands of the same
programmers.....

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Newsgroups: alt.folklore.computers,alt.folklore.science