23 Oct
2018
23 Oct
'18
4:08 p.m.
From: Ben Bfranchuk
I just can't find a clean simple design yet. ...
The PDP 11 is nice machine, but I am looking for simpler designs
where 16K words is a valid memory size for a OS and small single user
software.
There was a recent discussion about code density (I forget whether here, or
on TUHS), and someone mentioned this paper:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
which shows that for a combo of benchmarks, the PDP-11 had the densest code
out of all the ones they looked at. (They didn't look at the PDP-8, but I
suspect that since it's a single-address design, it's almost ceertainly not
as dense.)
The PDP-11 dates back to the days of core (it went through several generations
before DRAM arrived - e.g. the -11/70 originally shipped with core), and given
core prices, minimizing code size was pretty important - hence the results
above.
So if you want to get the most bang out of 16K buck...
Not the simplest machine to implement, mind - the -8 is a lot simpler. Which
axis is the most important to you?
Noel
23 Oct
23 Oct
4:26 p.m.
On Oct 23, 2018, at 4:08 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> wrote:
For simplicity and reasonable density, you might want to look at J1 (which is
a Forth CPU). It has been implemented in 300 lines of Verilog and the entire
CPU + 16KB of memory fits in a reasonably sized Spartan 3E FPGA (and you
have space for all of the other ?cool? stuff).
Admittedly, you get to write in Forth which may be a minus for some folks. ;-)
I did write a simulator for it (in Forth of course!) but I?m in the process of redoing
it in C so that I can have multiple threads of execution (for the various devices I
want to emulate). For me it was important because I?m using this as the controller
in an FPGA so I wanted to have a better debug environment for developing the
code. ;-)
TTFN - Guy
From: Ben Bfranchuk
I just can't find a clean simple design yet.
...
The PDP 11 is nice machine, but I am looking for simpler designs
where 16K words is a valid memory size for a OS and small single user
software.
There was a recent discussion about code density (I forget whether here, or
on TUHS), and someone mentioned this paper:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
which shows that for a combo of benchmarks, the PDP-11 had the densest code
out of all the ones they looked at. (They didn't look at the PDP-8, but I
suspect that since it's a single-address design, it's almost ceertainly not
as dense.)
The PDP-11 dates back to the days of core (it went through several generations
before DRAM arrived - e.g. the -11/70 originally shipped with core), and given
core prices, minimizing code size was pretty important - hence the results
above.
So if you want to get the most bang out of 16K buck...
Not the simplest machine to implement, mind - the -8 is a lot simpler. Which
axis is the most important to you? 
4:46 p.m.
On Oct 23, 2018, at 7:26 PM, Guy Sotomayor Jr via
cctalk <cctalk at classiccmp.org> wrote:
...
For simplicity and reasonable density, you might want to look at J1 (which is
a Forth CPU). It has been implemented in 300 lines of Verilog and the entire
CPU + 16KB of memory fits in a reasonably sized Spartan 3E FPGA (and you
have space for all of the other ?cool? stuff).
Admittedly, you get to write in Forth which may be a minus for some folks. ;-)
I did write a simulator for it (in Forth of course!) but I?m in the process of redoing
it in C so that I can have multiple threads of execution (for the various devices I
want to emulate). For me it was important because I?m using this as the controller
in an FPGA so I wanted to have a better debug environment for developing the
code. ;-)
I like Forth, I've used it for quite large programs though not recently.
There are versions that support multi-threading. Since it's a stack language,
that's pretty easy to do.
paul
5:03 p.m.
On 10/23/2018 5:26 PM, Guy Sotomayor Jr via cctalk wrote:
I use ALTERA FPGA products so I code in ADHL or use TTL macros.
It is not that I understand VERLOG or VHDL, but they are so VERBOSE that
I don't know just is being defined or compiled.
The FPGA is emulating TTL or 22V10 PAL logic so that I can get a design
tested before I start laying out PCB's.
> On Oct 23, 2018, at 4:08 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org>
wrote:
>
>> From: Ben Bfranchuk
>
>> I just can't find a clean simple design yet. ...
>> The PDP 11 is nice machine, but I am looking for simpler designs
>> where 16K words is a valid memory size for a OS and small single user
>> software.
>
> There was a recent discussion about code density (I forget whether here, or
> on TUHS), and someone mentioned this paper:
>
> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
>
I took a peek at PDF, before supper. "Benchmark in C"
That implies byte addressing, so that is not good test for older
machines with word adressing only.
> which shows that for a combo of benchmarks, the
PDP-11 had the densest code
> out of all the ones they looked at. (They didn't look at the PDP-8, but I
> suspect that since it's a single-address design, it's almost ceertainly not
> as dense.)
>
> The PDP-11 dates back to the days of core (it went through several generations
> before DRAM arrived - e.g. the -11/70 originally shipped with core), and given
> core prices, minimizing code size was pretty important - hence the results
> above.
>
> So if you want to get the most bang out of 16K buck...
Get rid of byte adressing. OK 64K of bytes or 32K words is much the
same, but we all know in hindsight 64KB is just too small for may
applications.
Not the simplest machine to implement, mind - the -8 is a lot simpler. Which
axis is the most important to you?
For simplicity and reasonable density, you might want to look at J1 (which is
a Forth CPU). It has been implemented in 300 lines of Verilog and the entire
CPU + 16KB of memory fits in a reasonably sized Spartan 3E FPGA (and you
have space for all of the other ?cool? stuff).
Admittedly, you get to write in Forth which may be a minus for some folks. ;-)
I did write a simulator for it (in Forth of course!) but I?m in the process of redoing
it in C so that I can have multiple threads of execution (for the various devices I
want to emulate). For me it was important because I?m using this as the controller
in an FPGA so I wanted to have a better debug environment for developing the
code. ;-) TTFN - Guy
5:18 p.m.
Dunno. I'd say that the CDC 6000 seies machines had pretty good code
density, and of course, ran like the wind.
Instructions are 15 or 30 bits and no condition codes to preserve. Most
are 3-address.
And a very simple instruction set.
--Chuck
5:34 p.m.
On 10/23/2018 6:18 PM, Chuck Guzis via cctalk wrote:
Dunno. I'd say that the CDC 6000 seies machines
had pretty good code
density, and of course, ran like the wind.
Instructions are 15 or 30 bits and no condition codes to preserve. Most
are 3-address.
And a very simple instruction set.
--Chuck
With NO GUI and hidden IO, you get speed.
Ben.
24 Oct
24 Oct
5:36 a.m.
On Oct 23, 2018, at 9:47 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
On 10/23/18 6:10 PM, ben via cctalk wrote:
Very different. PPUs are real computers, vaguely like a PDP-8 in fact but quite fast. The
PPUs have major roles in the OS throughout the 6000 series, not just in early versions.
And not always just the OS. Consider PLATO, which in a sense is an application... with a
set of PPU programs to help it. It would drive 1000 terminals (600 logged in
concurrently) running highly interactive text and graphics applications including early
multi-user games, on a pair of 6500 machines. Those are, on good days, roughly 1 MIPS per
CPU. Feeding data to and from the 1000 terminal lines was the job of just a single PPU.
IBM channels are (from the programmer point of view at least) merely hardwired controllers
no different from a DEC UDA50 or for that matter a CDC 7054 disk controller.
The fact that PPUs are general purpose computers means a smart programmer can make the I/O
system do things the manufacturer did not believe possible. CDC used 2 to 1 sector
interleave on its disk drives (844, which is like the DEC RP04) because the PPU could not
keep up with sector data arriving at full speed. But Don Lee at University of Illinois
made that work in the PLATO system by deploying a pair of PPUs controlling the disks
together ("ping" and "pong").
That said, I think Ben is overestimating the impact of the PPUs on the overall system
performance. A lot more comes from the CPU architecture. The instruction set, of course
(arguably the first RISC). And especially the multiple functional unit highly overlapped
design, with some very clever tricks in it. Consider that a 6000 would do a process
context switch with a single instruction, in about 4 microseconds -- in 1964. Part of the
reason that works is that it takes advantage of the properties of core memory in a way
that few other machines do.
paul
The 10 or so PPU units.
Ben.
Early SCOPE and COS also put the operating system in those, leaving the
CPU for real work. But for I/O, not that much different from IBM
"channels", no? 
8:53 a.m.
On 10/24/2018 07:36 AM, Paul Koning via cctalk wrote:
IBM channels are (from the programmer point of view at
least) merely hardwired controllers
Well, no. They actually can do a lot more.
They can do
branching and simple arithmetic. We had a program to deal
with damaged/deteriorating tapes. You could operate sense
switches on the tape control unit to tell it when to give up
on retries on a bad block and go to the next one. This
allowed the operator to copy all the recoverable blocks from
a bad tape. Once started by the CPU, this program ran
entirely in the channel.
The original scheme for disks was that the control unit +
channel would be able to scan a range of disk tracks to find
a record in which a string of bytes matched a pattern. This
turned out to not work so well on larger systems as it could
tie up not only the control unit but the whole channel for
the duration of the search. In 1962-3 or so, when the 360
was designed, IBM had no idea how heavily the systems were
going to depend on the disk drives.
Jon
9:38 a.m.
On 10/24/18 5:36 AM, Paul Koning wrote:
Very different. PPUs are real computers, vaguely like a PDP-8 in
fact but quite fast. The PPUs have major roles in the OS throughout
the 6000 series, not just in early versions.
You obviously haven't spent much time in SSD (Special Systems). I
recall working on a transaction-oriented multiple-CPU system (tied
together with ECS) where the PPs were little more than I/O processors.
*None* of the main operating system code was in the PPUs, save, perhaps
for DSD.
The reason for this was quite simple--PPs are terrible when it comes to
block ECS transfers and having the PPs switch their attention between
tasks whose CM lifetime was measured in milliseconds was impossible. We
had several PPUs dedicated to servicing disk requests for oceans of 844
drives, but they communicated directly with the CM resident OS, not
individual user tasks--no "stack processor"; requests were sorted and
prioritized by the CM OS. We could run traditional batch jobs, but
that was essentially a hack of some SCOPE 3.1.6 code and it did not play
well with the major business of the system. PP0, MTR's resident code
occupied about one printed page--it kept the time of day.
Communications were again handled with a PPU, but even that was
connected to several 1700s.
All of this was an outgrowth of TCM (Time Critical Monitor), done by a
fellow associated with the ROVER project. You needed the CEJ feature
for this all to work. None of this "stick a request in RA+1 and wait
around" stuff--far too slow.
Some of this was evolutionary--Greg and Dave's MACE was considerably
more CPU-oriented than was SCOPE.
You can see the same influence in 7600 SCOPE--there the PPUs are very
different, communicating via fixed memory areas in SCM. There, they
really are nothing more than I/O processors.
Interestingly, when STAR came along, the Twin Cities crowd tried to play
the same game as the old SCOPE people did--put most of the OS into the
stations. LRL didn't agree on that and moved most of the OS to a
message-passing resident CPU based scheme, and it was that system that
became the standard OS--and it was implemented in a variety of LRLTran,
not assembly code.
--Chuck
10 a.m.
On Oct 24, 2018, at 12:38 PM, Chuck Guzis <cclist
at sydex.com> wrote:
On 10/24/18 5:36 AM, Paul Koning wrote:
Actually, no, my 6000 time was at the University of Illinois PLATO project. It runs on
NOS, which has both CPU OS code and substantial quantities of PP resident OS stuff.
PLATO is intensely dependent on ECS, far more than typical CDC software. And in fact,
several of its PPs talk via ECS, not CM. Disk I/O, terminal I/O, these go via ECS.
paul
Very different. PPUs are real computers, vaguely like a PDP-8 in
fact but quite fast. The PPUs have major roles in the OS throughout
the 6000 series, not just in early versions.
You obviously haven't spent much time in SSD (Special Systems). I
recall working on a transaction-oriented multiple-CPU system (tied
together with ECS) where the PPs were little more than I/O processors.
*None* of the main operating system code was in the PPUs, save, perhaps
for DSD.
The reason for this was quite simple--PPs are terrible when it comes to
block ECS transfers and having the PPs switch their attention between
tasks whose CM lifetime was measured in milliseconds was impossible.
23 Oct
23 Oct
4:53 p.m.
On Oct 23, 2018, at 7:08 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> wrote:
Interesting. There are lots of single address machines; it isn't all that obvious
they would be less effective.
It also depends on other instruction set features. Some years ago I learned the
architecture of the Dutch Electrologica X1 and X8 machines. They are single address, with
multiple registers (not many though). But they gain a lot of efficiency by allowing
almost all instructions to optionally set a condition flag, and almost all instructions to
be executed conditionally on that flag. So a lot of code full of branches becomes much
shorter. The fact that the condition flag setting itself is a choice (unlike the setting
of condition codes) helps a lot. For example:
if (x >= 0) { foo (); x += 2; }
else x -= 3;
translates to just 5 instructions:
a=x,p
y,sub(foo)
y,a+2
n,a-3
x=a
since the condition flag is (normally, though it's a choice) preserved by function
call/return.
Pretty efficient.
paul
From: Ben Bfranchuk
I just can't find a clean simple design yet.
...
The PDP 11 is nice machine, but I am looking for simpler designs
where 16K words is a valid memory size for a OS and small single user
software.
There was a recent discussion about code density (I forget whether here, or
on TUHS), and someone mentioned this paper:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
which shows that for a combo of benchmarks, the PDP-11 had the densest code
out of all the ones they looked at. (They didn't look at the PDP-8, but I
suspect that since it's a single-address design, it's almost ceertainly not
as dense.)
24 Oct
24 Oct
6:19 a.m.
On Oct 23, 2018, at 7:08 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> wrote:
...
There was a recent discussion about code density (I forget whether here, or
on TUHS), and someone mentioned this paper:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
which shows that for a combo of benchmarks, the PDP-11 had the densest code
out of all the ones they looked at. (They didn't look at the PDP-8, but I
suspect that since it's a single-address design, it's almost ceertainly not
as dense.)
The PDP-11 dates back to the days of core (it went through several generations
before DRAM arrived - e.g. the -11/70 originally shipped with core), and given
core prices, minimizing code size was pretty important - hence the results
above.
What's interesting is that the paper uses compiled code. The gcc back end for pdp11
is still a work in progress and clearly doesn't deliver best possible code, certainly
not back then.
paul
7:05 a.m.
On 10/24/2018 09:19 AM, Paul Koning via cctalk wrote:
I found that paper to be a not so interesting and more or less
pointless.? For many applications its what's on the
chip and rarely does it focus on architecture.? Engineers need to do
things or produce things that work
and? most of the time it comes down to whats available and price.? With
embedded machines the IO
capability and resident memory are likely deciding factors more so than
if its Harvard or Von, RISC
or CISC.?? The other is the tool chain costs in, acquisition cost,? time
to learn, and apply.
Allison
On Oct 23, 2018, at 7:08 PM, Noel Chiappa via
cctalk <cctalk at classiccmp.org> wrote:
...
There was a recent discussion about code density (I forget whether here, or
on TUHS), and someone mentioned this paper:
http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
which shows that for a combo of benchmarks, the PDP-11 had the densest code
out of all the ones they looked at. (They didn't look at the PDP-8, but I
suspect that since it's a single-address design, it's almost ceertainly not
as dense.)
The PDP-11 dates back to the days of core (it went through several generations
before DRAM arrived - e.g. the -11/70 originally shipped with core), and given
core prices, minimizing code size was pretty important - hence the results
above.
What's interesting is that the paper uses compiled code. The gcc back
end for pdp11 is still a work in progress and clearly doesn't deliver best possible
code, certainly not back then.
paul
2250
days inactive
2251
days old
15 comments
7 participants
participants (7)
-
allisonportable＠gmail.com -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
elson＠pico-systems.com -
ggs＠shiresoft.com -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net