8 May
2005
8 May
'05
5:45 p.m.
Subject: Re: Infocom on PDP-11
From: Philip Pemberton <philpem at dsl.pipex.com>
Date: Sun, 08 May 2005 22:06:15 +0100
To: cctalk at classiccmp.org
In message <f4eb766f05050813432f2d277a at mail.gmail.com>
Ethan Dicks <ethan.dicks at gmail.com> wrote:
> One of the events in the timeline mentions a ZIP (Zork Implementaton
> Program - the game engine) for the DECmate. If anyone has ever seen
> an Infocom title for the DECmate, I'd love to play with it. I'd
> expect that it was for an optional 8-bit coprocessor board, not for
> the primary 12-bit 6100 processor, but I'd like to know for sure.
It was for either the Z80 apu running CP/M making its a terminal/media
thing rather than new version.
I'm not sure just how powerful the 6100 is, but I
doubt it would be too
difficult to port one of the simpler Z-machine engines from Linux or BSD to
whatever the DECmate runs (VMS?)
Decmate II/III uses 6120 (PDP-8 with EMA). There is no *nix for the PDP-8
and OS278 is common. FYI: VMS runs on VAX(32bit) and Alpha(64bit).
If you can fit the game format into a 32Kword 12bit machine it's possible.
Generally speaking there isn't a C compiler for PDP-8 I know of and the
4k paged addressing and very minimalist instruction set would be an
interesting challenge. I've seen Fortan, Focal, Basic and even algol
on an 8 but never C.
There is also the VAXmate, a flavor of a 286 clone.
Allison
8 May
8 May
6:17 p.m.
Allison wrote:
Decmate II/III uses 6120 (PDP-8 with EMA). There is no
*nix for the PDP-8
and OS278 is common. FYI: VMS runs on VAX(32bit) and Alpha(64bit).
If you can fit the game format into a 32Kword 12bit machine it's possible.
Generally speaking there isn't a C compiler for PDP-8 I know of and the
4k paged addressing and very minimalist instruction set would be an
interesting challenge. I've seen Fortan, Focal, Basic and even algol
on an 8 but never C.
The lack of local variables makes C very dificult.
There is also the VAXmate, a flavor of a 286 clone.
Allison
.
7:10 p.m.
>>>> "woodelf" == woodelf
<bfranchuk at jetnet.ab.ca> writes:
woodelf> Allison wrote:
> Decmate II/III uses 6120 (PDP-8 with EMA). There
is no *nix for
> the PDP-8 and OS278 is common. FYI: VMS runs on VAX(32bit) and
> Alpha(64bit).
>
> If you can fit the game format into a 32Kword 12bit machine it's
> possible. Generally speaking there isn't a C compiler for PDP-8 I
> know of and the 4k paged addressing and very minimalist
> instruction set would be an interesting challenge. I've seen
> Fortan, Focal, Basic and even algol on an 8 but never C.
>
>
>
woodelf> The lack of local variables makes C very dificult.
Huh?
You're confusing the lack of a hardware stack with the lack of local
variables. They are not at all related.
The IBM 360/370 series doesn't have a stack, and some of its
restrictions are vaguely PDP-8 like. Nevertheless, GCC supports C
(and C++) quite nicely on those machines.
For that matter, Algol had local variables long before C was invented,
and as you pointed out, there's an Algol for the PDP-8. (Then again,
that's not a true compiler -- it compiles to an intermediate form that
looks very much like a subset of the Burroughs 5500 instruction set.)
And Unix originally appeared on the PDP-7, which you can describe
quite reasonably as an 18-bit superset of the PDP-8. (That's
historically nonsense, but as a description it fits.) Did C exist
back then, or did that wait until Unix was ported to the PDP-11? I
don't know.
Finally, CDC 6000s don't have a stack either, but the first Pascal
compiler ran on that machine. Implementing a stack on a non-stack
machine (or non-stack language like Fortran-II) is a nice elementary
Exercise for the Student.
paul
9 May
9 May
1:57 a.m.
Paul Koning wrote:
Huh?
You're confusing the lack of a hardware stack with the lack of local
variables. They are not at all related.
But the IBM does have INDEX registers that makes emulating a stack easy.
The IBM 360/370 series doesn't have a stack, and
some of its
restrictions are vaguely PDP-8 like. Nevertheless, GCC supports C
(and C++) quite nicely on those machines.
But GCC does not need to fit into 4096 words of memory. If you compiled
C into
a P-code type code I am sure you would have no problems but a very tiny
memory
space.
For that matter, Algol had local variables long before
C was invented,
and as you pointed out, there's an Algol for the PDP-8. (Then again,
that's not a true compiler -- it compiles to an intermediate form that
looks very much like a subset of the Burroughs 5500 instruction set.)
And Unix originally appeared on the PDP-7, which you can describe
quite reasonably as an 18-bit superset of the PDP-8. (That's
historically nonsense, but as a description it fits.) Did C exist
back then, or did that wait until Unix was ported to the PDP-11? I
don't know.
C was developed around the time Unix was developed but only one they
ported did they
have a real machine to use. Primeval C ==
http://www.cs.bell-labs.com/who/dmr/primevalC.html
Finally, CDC 6000s don't have a stack either, but
the first Pascal
compiler ran on that machine. Implementing a stack on a non-stack
machine (or non-stack language like Fortran-II) is a nice elementary
Exercise for the Student.
But if you have subscripted varibles, then you can have stacks and other
data structures.
you have to do the work the hard way rather than use hardware.
paul
11:57 a.m.
From: "Allison" <ajp166 at bellatlantic.net>
Decmate II/III uses 6120 (PDP-8 with EMA). There is
no *nix for the PDP-8
and OS278 is common. FYI: VMS runs on VAX(32bit) and Alpha(64bit).
If you can fit the game format into a 32Kword 12bit machine it's possible.
Generally speaking there isn't a C compiler for PDP-8 I know of and the
4k paged addressing and very minimalist instruction set would be an
interesting challenge. I've seen Fortan, Focal, Basic and even algol
on an 8 but never C.
I don't expect to ever see a true C compiler for the PDP-8. The lack of
stacks, etc. are easily gotten around, but the 12 bit word size isn't. On a
PDP-8, a short (or a pointer, for that matter) would have to be 2 words (and
a long would be 3). The C data types just don't fit efficiently into 12 bit
words. So writing a C compiler would be difficult, and the resulting code
would be horrible (at least by PDP-8 standards) :-).
Now a "C-like" language, with 12-bit shorts and ints, would be kinda cool.
(To generate efficient code, it would likely need to have something like
"near" and "far" pointers, though.)
Vince
10 May
10 May
6:50 p.m.
I don't expect to ever see a true C compiler for
the PDP-8. The lack of
stacks, etc. are easily gotten around, but the 12 bit word size isn't. On a
PDP-8, a short (or a pointer, for that matter) would have to be 2 words (and
a long would be 3). The C data types just don't fit efficiently into 12 bit
words. So writing a C compiler would be difficult, and the resulting code
would be horrible (at least by PDP-8 standards) :-).
The C data types only have minimum sizes. Actual sizes are up to the
implementation.
The resulting C data types for a PDP-8 would be 12-bit char, 24 bit
short and int, 36 bit long. As long as limits.h contains the correct
values and the sizeof() operator correctly returns 1, 2 and 3 for the
above. I'd go with 12 bits pointers for a start, you could also make
a "large model" compiler to use more than 4k. I'd put declared autos
in the current page and expand the address to 12 bits if it get stored
in a pointer or the routine gets too large. Passed parameters could be
zero page, and it would be up to the caller to save ones that they
need later. (Yes, there really doesn't need to be a stack. You can
do variable size local allocations on the heap.) All in all, a cross
compiler built from LCC should be a doable task (although there will
be some 32-bit assumption issues). It's certainly easier than
building a mixed-model 8086 compiler (as there is less garbage to deal
with).
Don't ask me to write the floating point library, though...
The only real problem is that too much C code floating around assumes
that CHAR_BIT==8 and that sizeof(void *), sizeof(int) and sizeof(long)
are equal to each other. It would still compile and run, since you
can convert a 12 bit pointer to a 24 bit int and back with no loss.
It wouldn't be efficient, though.
Eric
11 May
11 May
11:10 a.m.
New subject: C on the PDP-8 (was Re: Infocom on PDP-11)
> I don't expect to ever see a true C compiler
for the PDP-8. The lack of
> stacks, etc. are easily gotten around, but the 12 bit word size isn't.
On
a
> PDP-8, a short (or a pointer, for that matter)
would have to be 2 words
(and
> a long would be 3). The C data types just
don't fit efficiently into 12
bit
> words. So writing a C compiler would be
difficult, and the resulting
code
would be
horrible (at least by PDP-8 standards) :-).
The C data types only have minimum sizes. Actual sizes are up to the
implementation. The resulting C data types for a PDP-8 would be
12-bit char, 24 bit
short and int, 36 bit long. As long as limits.h contains the correct
values and the sizeof() operator correctly returns 1, 2 and 3 for the
above. I'd go with 12 bits pointers for a start, you could also make
a "large model" compiler to use more than 4k.
Agreed. But these sizes would lead to bloated PDP-8 code for simple
operations, which in turn would mean you could get almost nothing useful
done in 4Kw. Average data size around 2 words makes this worse, too.
Witness the complexity of the largest Focal 69 programs that can be fit in
4K. There's only so much you can do in the space available. Here the
reason for the space constraints would be different (the co-resident code is
run-time libraries instead of the interpreter), but I suspect the result
would be similar.
I'd put declared autos
in the current page and expand the address to 12 bits if it get stored
in a pointer or the routine gets too large. Passed parameters could be
zero page, and it would be up to the caller to save ones that they
need later. (Yes, there really doesn't need to be a stack. You can
do variable size local allocations on the heap.) All in all, a cross
compiler built from LCC should be a doable task (although there will
be some 32-bit assumption issues). It's certainly easier than
building a mixed-model 8086 compiler (as there is less garbage to deal
with).
I think the challenges would be to determine when recursion is actually
used, etc. Otherwise, the entry and exit from subroutines will be expensive
(especially if you are calling a heap allocator).
I actually think the task is only manageable if you virtualize a processor
that is more amenable to C. Which is also time-inefficient, but could
potentially be at least a little more space-efficient. (Maybe a 24-bit two
operand machine? Or something like a Nova, but 24 bit?)
Don't ask me to write the floating point library,
though...
That shouldn't be that bad; there are plenty of floating point routines
around for the PDP-8.
The only real problem is that too much C code floating
around assumes
that CHAR_BIT==8 and that sizeof(void *), sizeof(int) and sizeof(long)
are equal to each other. It would still compile and run, since you
can convert a 12 bit pointer to a 24 bit int and back with no loss.
It wouldn't be efficient, though.
I think the broken code in the world is either too large for the PDP-8, or
small enough to fix :-).
Vince
12:08 p.m.
New subject: was "C on the PDP-8 (was Re: Infocom on PDP-11)", now "FOCAL source"
"vrs" wrote:
I actually think the task is only manageable if you virtualize a processor
that is more amenable to C. Which is also time-inefficient, but could
potentially be at least a little more space-efficient. (Maybe a 24-bit two
operand machine? Or something like a Nova, but 24 bit?)
heh. I remember puzzling at the the "pushj"'s and "popj"'s in
the FOCAL
source code. This was before I had seen a pdp-11 or dec-10.
Does anyone have the source for FOCAL on line? I used something called
FOCARL and COLPAC also, derivatives created by some smart guys at
Carleton College.
-brad
1:18 p.m.
New subject: was "C on the PDP-8 (was Re: Infocom on PDP-11)", now "FOCAL source"
heh. I remember puzzling at the the
"pushj"'s and "popj"'s in the FOCAL
source code. This was before I had seen a pdp-11 or dec-10.
I spent a summer doing the same thing, but without benefit of source code.
(I still have my reverse-engineered source code for a variety of versions of
PDP-8 Focal.)
Does anyone have the source for FOCAL on line? I used
something called
FOCARL and COLPAC also, derivatives created by some smart guys at
Carleton College.
I found a copy of what looks like the usual version at:
http://www.bitsavers.org/bits/DEC/pdp8/papertapeImages/russ.ucs.indiana.edu…
Vince
2:21 p.m.
New subject: was "C on the PDP-8 (was Re: Infocom on PDP-11)", now "FOCAL source"
"vrs" wrote:
I found a copy of what looks like the usual version at:
http://www.bitsavers.org/bits/DEC/pdp8/papertapeImages/russ.ucs.indiana.edu…
ngs/Focal/Focal1/OS8/
glug. what format is that in? is it a byte-ized version of a 12 bit file
which has 3-chars-per-2-words ?
any idea how I can turn that back into an ascii byte stream?
(at least I'm on topic :-)
-brad
2:38 p.m.
New subject: was "C on the PDP-8 (was Re: Infocom on PDP-11)", now "FOCAL source"
From: "Brad Parker" <brad at heeltoe.com>
/La
Ah. You are probably looking for the version up and over in ../Ascii, if
you want to view it on your non-classic machine :-).
Vince
I found a copy
of what looks like the usual version at:
http://www.bitsavers.org/bits/DEC/pdp8/papertapeImages/russ.ucs.indiana.edu
ngs/Focal/Focal1/OS8/
glug. what format is that in? is it a byte-ized version of a 12 bit file
which has 3-chars-per-2-words ?
any idea how I can turn that back into an ascii byte stream?
(at least I'm on topic :-) 
5:43 p.m.
New subject: What does PUSHJ do? (was Re: was "C on the PDP-8 ... ")
It was thus said that the Great Brad Parker once stated:
heh. I remember puzzling at the the "pushj"'s and "popj"'s
in the FOCAL
source code. This was before I had seen a pdp-11 or dec-10.
What does PUSHJ actually do? I remember reading about it in Steven Levy's
Hackers, but never got what was so special about it.
-spc (Saves the register J, right?)
6:06 p.m.
New subject: What does PUSHJ do? (was Re: was "C on the PDP-8 ... ")
It was thus said that the Great Brad Parker once
stated:
Levy's
heh. I remember puzzling at the the "pushj"'s and "popj"'s
in the FOCAL
source code. This was before I had seen a pdp-11 or dec-10.
What does PUSHJ actually do? I remember reading about it in Steven Hackers, but never got what was so special about it.
PUSHJ does a CALL, using a software implementation of a stack, which allows
the target subroutine to be recursive. JMS stores the return address in the
entry point, so it won't do (without help) for recursive routines.
(Similarly, POPJ is like RET.)
Both are quite odd, if you are used to the PDP-8 calling conventions, and
unfamiliar with stacks. (Once you have used them for a while, they seem
obvious.)
Vince
9 May
9 May
12:22 p.m.
Allison wrote:
Decmate II/III uses 6120 (PDP-8 with EMA). There is no
*nix for the PDP-8
and OS278 is common. FYI: VMS runs on VAX(32bit) and Alpha(64bit).
And the almost dead Intel IA-64 bit line.
If you can fit the game format into a 32Kword 12bit
machine it's possible.
Generally speaking there isn't a C compiler for PDP-8 I know of and the
4k paged addressing and very minimalist instruction set would be an
interesting challenge. I've seen Fortan, Focal, Basic and even algol
on an 8 but never C.
I think that C really needs to have a stack to be useful: recursive
calls, pass by (alterable) value, multiple levels of local variables,
etc. At least it is much easier to implement if you have a stack.
Does there exist a good C compiler for any machine lacking a stack?
There is also the VAXmate, a flavor of a 286 clone.
Allison
12:37 p.m.
>>>> "Kevin" == Kevin Handy
<kth at srv.net> writes:
Kevin> I think that C really needs to have a stack to be useful:
Kevin> recursive calls, pass by (alterable) value, multiple levels of
Kevin> local variables, etc. At least it is much easier to implement
Kevin> if you have a stack.
Kevin> Does there exist a good C compiler for any machine lacking a
Kevin> stack?
There is no "machine lacking a stack".
There are plenty of machines that don't have a "hardware stack" or
stack-oriented instructions, or stack-oriented addressing modes. The
Cyber, IBM S/360 and its successors, many (perhaps all) DSPs, etc. all
come to mind.
But on such machines, creating a stack is just a trivial programming
exercise, and C compilers of course do just that. There's a GCC for
the S/390, just to name one example.
paul
7013
days inactive
7016
days old
14 comments
8 participants
participants (8)
-
ajp166＠bellatlantic.net -
bfranchuk＠jetnet.ab.ca -
brad＠heeltoe.com -
korpela＠gmail.com -
kth＠srv.net -
pkoning＠equallogic.com -
spc＠conman.org -
vrs＠msn.com