PDP-8 Story

[pet...@pbear.uucp]

Thanx for the applause. I like it. (your story that is :-).

What I would like to see is a proposal of a "next generation" PDP-8,

Something with say:

16 bit memory
65K fields
256 fields (yields 24Mb memory)
each field broken to 256 256 word pages
direct addressing mode (so arryas and stuff don't have to be paged)
built in extended AU
other goodies.

Oh Yeah, a stack would be quite useful.

This type of architecture would encourage (NOT force) the programmer to
write localized code for his routines. Also language compilers would be
designed to take advantage of this concept.

Also VM overhead would be smaller since the locality of page operations
would keep paging activity lower than say a VAX. In fact I would not
be suprised if this type of architecture could beat a VAX in terms of

(probably fit in less memory and run faster :-)

Any Ideas???

Peter Barada
ima!pbear!peterb
ihnp4!inmet!pbear!peterb

I welcome contructive ideas, but If you are going to flame me for
thinking of such a monstrosity, snuff it!

[pet...@pbear.uucp]

Oops, ED chopped a line out of my previous response.

After "Probably beat a VAX in terms of" add:

Paging overhead and size of workspace.

Sorry for the omission.

Peter Barada / ima!pbear!peterb / ihnp4!inmet!pbear!peterb

[Henry Spencer]

> What I would like to see is a proposal of a "next generation" PDP-8,
>
> Something with say:
>
> 16 bit memory
> 65K fields
> 256 fields (yields 24Mb memory)
> each field broken to 256 256 word pages
> direct addressing mode (so arryas and stuff don't have to be paged)
> built in extended AU
> other goodies.
>
> Oh Yeah, a stack would be quite useful.

To a sloppy first approximation, if you squint a lot, the Intel 8086
meets these specs. Yuck. 16-bit address spaces are the pits, even
if you have lots of them.

> This type of architecture would encourage (NOT force) the programmer to
> write localized code for his routines. Also language compilers would be
> designed to take advantage of this concept.

You mean "language compilers could be designed, at horrendous cost in
pain and effort, to take advantage of this concept". Page boundaries
and field boundaries are the two massive headaches in building a decent
pdp8 compiler; I studied this for a while years ago. "There just ain't
no graceful way."
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry

[Doug Pardee]

> 16 bit memory
> 65K fields
> 256 fields (yields 24Mb memory)
> each field broken to 256 256 word pages
> direct addressing mode (so arryas and stuff don't have to be paged)
> built in extended AU
> other goodies.
>
> Oh Yeah, a stack would be quite useful.

Almost sounds like my recollection of the (mythical) Western Design
Center WDC65SC816, the 16-bit extension of the 6502.

Also, you can treat the NS32000 CPUs pretty much that way, but not with
the standard assembler unless you like to code repetitive options on
every instruction. The assembler was written by an HLL weenie who
couldn't imagine using the registers in any non-HLL, non-relocatable
fashion.
--
Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug
^^^^^--- soon to be CalComp

[Richard Mateosian]

In article <350...@pbear.UUCP> pet...@pbear.UUCP writes:
>
>What I would like to see is a proposal of a "next generation" PDP-8,
>

> 16 bit memory
> 65K fields
> 256 fields (yields 24Mb memory)
> each field broken to 256 256 word pages
> direct addressing mode (so arryas and stuff don't have to be paged)
> built in extended AU
> other goodies.
>
> Oh Yeah, a stack would be quite useful.
>

>Any Ideas???

Sounds a lot like a Z8000 (Z8000 + Z8015, to be precise), except that the
Z8000 also has a decent register set.
--
Richard Mateosian
{allegra,cbosgd,decwrl,hplabs,ihnp4,seismo}!nsc!srm nsc!s...@decwrl.ARPA

[Robert Heiss]

In article <350...@pbear.UUCP> pet...@pbear.UUCP writes:
>

>What I would like to see is a proposal of a "next generation" PDP-8,
>
>Something with say:
>
> 16 bit memory
> 65K fields
> 256 fields (yields 24Mb memory)
> each field broken to 256 256 word pages
> direct addressing mode (so arryas and stuff don't have to be paged)
> built in extended AU
> other goodies.

Look at the 65816 microprocessor. Except for the relative addressing on
short branches, its architecture is similar to your description.

> Oh Yeah, a stack would be quite useful.

But not a *paged* stack. If your hardware can only support a 256 byte
stack, why bother? To support high-level language, you could emulate a
real stack by using indirect addressing (ala PDP-8, NOVA, APPLE ][).

>This type of architecture would encourage (NOT force) the programmer to
>write localized code for his routines. Also language compilers would be
>designed to take advantage of this concept.
>
>Also VM overhead would be smaller since the locality of page operations
>would keep paging activity lower than say a VAX. In fact I would not
>be suprised if this type of architecture could beat a VAX in terms of
>
> (probably fit in less memory and run faster :-)
>

>Peter Barada

I'm intrigued by the VM overhead argument -- a paged-address-space CPU
connected to virtual memory with the same fixed page size -- has this
experiment been performed?

Coming soon: Paged RISC + VM
vs.
MicroVAX II

Any volunteers to write a paged-memory C compiler? :-)

-Robert !ihnp4!trwrb!trwspp!spp2!heiss

[Herb Chong [DCS]]

In article <5...@spp2.UUCP> he...@spp2.UUCP (Robert Heiss) writes:
>I'm intrigued by the VM overhead argument -- a paged-address-space CPU
>connected to virtual memory with the same fixed page size -- has this
>experiment been performed?

i may be misunderstanding what you are suggesting, but doesn't the
IBM S/370 and 370-XA architecture do exactly this? hardware pagesize
is 4K and the "priviledged" instructions for page manipulation work
with 4K pages.

Herb Chong...

I'm user-friendly -- I don't byte, I nybble....

UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie
CSNET: herbie%wat...@waterloo.csnet
ARPA: herbie%watdcsu%waterlo...@csnet-relay.arpa
NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu