PDP11 speed

[Jonathan Harston]

I know the PDP11 didn't have what we'd recognise as a CPU clock, so

you can't really talk about a PDP11 "clocked at 2MHz". Individual instructions

are documented as taking specified times, and individual addressing modes

as taking additional times; the timing being essentially the result of the CPU

module placing signals on the bus and waiting for results from memory, with

hairy R/C networks regulating them.

However, the fastest* instruction timing in the 1979 PDP11 processor

handbook is the MOV/CLR/COM... group with Rn addressing mode at 1.96us.

Could I sorta then sorta call that 0.510MHz (1/1.96us). Other instruction

timings are not nice multiples of anything, we have 2.16us, 2.31us,

0.93us for (Rn), 2.17us for @(Rn)+, etc. But I want to have a base to

compare things, so I can time things and say "ah ha! this is running six

times faster than a 1979 PDP11, it's essentially a 3MHz system".

In a discussion on SlashDot in 2013 it is stated "the pdp11/45 ... a cycle

time of 300ns, so about 3.3MHz" so if we take "cycle time" as the shortest

time to get something from memory, which would be a single instruction

that doesn't access memory - eg MOV R0,R1 - then that's our "base" unit.

We then gloss over that instructions then appear to execute in non-integer-

multiples of cycles. :) ADD r0,r1 is 2.16us which is "1.1 cycles".

So, if I execute a loop decrementing a register from zero back to zero

again and it takes 0.2798437s, then it's functionally a 1979 0.5MHz system.

(*Ok, branch-not-taken is 1.76us.)

jgh

[Johnny Billquist]

I think you are a little mixed up.

There is a clock, as in something driven by a chrystal, on a PDP-11.
It's very much the same story as with any modern machine. Timing depends
on cache, addressing modes, memory speed, and all kind of stuff.

What you're describing do sound a lot like what the PDP-8 is doing, though.

But PDP-11 speed is both different in different models, but also
different implementations. So you can't just say a number for any
operation, addressing mode, or whatever. You'll need to be much more
specific on which machine you are talking about, and so on.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> pidp-11/08808872-f54c-420e-973a-b2d39d4cb89en%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/08808872-f54c-420e-973a-
> b2d39d4cb89en%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Dwain Sims]

This brings up a question in my mind.

When I was in grad school in the early 80s we had a PDP 11/23 that the department ran Unix on and a couple of LSI-11 systems that primarily ran RT-11.  I never really thought about it at the time, but was there much difference in raw performance between the two?  I was not paying attention to that in that time frame (I was just happy to get access to any system.)  We certainly had more peripherals on the 11/23.  I recall that the only storage we had on the LSI-11 systems were 8 inch floppies.

Dwain

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/6244b484-c30d-4644-95a9-c3bc71f373f0%40softjar.se.

[pbi...@gmail.com]

Read the thread https://retrocomputingforum.com/t/the-wide-ranging-performance-of-the-pdp-11/2615 and check out the "Computer Engineering" (and other) references.

[Johnny Billquist]

You got a link to a thread with some information on the performance of
different CPUs already.

But just to answer directly, yes, there is a significant difference
between the LSI-11 and the 11/23. But neither is close to the top of the
performance among PDP-11 models.

And to make another comment on clocks. As with most machines, talking
about the clock frequency is somewhat misleading, as you also need to
know how many clock cycles the CPU requires to do an instruction, which
differs between different architectures, but sometimes also between
different implementations of the same architecture. The PDP-11 is
definitely in that camp, so you need to look at a specific
implementation as well. But for the core clock, here are a couple of models:

11/70: 33.333 MHz
11/73: 15 MHz
11/8x: 18 MHz
11/9x: 18 MHz
11/2x: 26.667 MHz
11/03: 2.5 MHz (but this one is an RC network)

Nut, as mentioned, just talking about the frequency of clocks isn't
really that meaningful.

The classic example is the Z80 vs. 6502 comparisons. The Z80 (classic)
usually ran at 4 MHz, while the 6502 ran at 1 MHz.
However, the minimum number of cycles to do one instruction on the Z80
was 4, while on the 6502 it was 1, so in effect they were comparable for
doing a single instruction.

Johnny

> <mailto:pidp-11%2Bunsu...@googlegroups.com>
> > <mailto:pidp-11+u...@googlegroups.com
> <mailto:pidp-11%2Bunsu...@googlegroups.com>>.

> > To view this discussion visit https://groups.google.com/d/msgid/

> <https://groups.google.com/d/msgid/>
> > pidp-11/08808872-f54c-420e-973a-b2d39d4cb89en%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/pidp-11/08808872-
> f54c-420e-973a- <https://groups.google.com/d/msgid/pidp-11/08808872-
> f54c-420e-973a->
> > b2d39d4cb89en%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?

> utm_medium=email&utm_source=footer>>.
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

> Reading murder books
> pdp is alive!                    ||  tryin' to stay hip" - B. Idol
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/6244b484-c30d-4644-95a9-c3bc71f373f0%40softjar.se <https://
> groups.google.com/d/msgid/pidp-11/6244b484-c30d-4644-95a9-
> c3bc71f373f0%40softjar.se>.
>

[Mark Matlock]

Dwain,

   Below is a comparison of bench marks that I measured and collected from PDP-11 and VAX systems that I have access to or own.

   I just recently acquired a PDP-11/03 and was able to compile the Dhrystone bench mark with RT-11 PDP-11C to compare it to the PDP-11/23 in my MINC-23. The Dhrystone bench mark has no floating point but PDP-11C does generate EIS instructions so I have not got a value yet for the PDP-11/05.

   On Floating point the 11/03 had optional FIS instructions and the 11/23 had FPP instructions either in microcode or as a separate board using bit slice chips as options. Below is microcode value for the 11/23. Also, below the 11/44 does not have the FPP option but used a DECUS FPP instruction trap software. The FIS instructions used the stack to pass floating point input and results and was supported by DEC’s threaded Fortran IV compiler, where DEC’s F77 compiler used the FPP instructions and compiled FPP instructions in-line. This gives the 11/23 a bigger advantage if you compare F77 on the 11/23 to Fortran IV on the 11/03. I’m in the process of evaluating that difference.

   Also, below the PDP-11/70 tests are from Jacob Ritorto’s PDP-11/70 that has some 3rd party performance options. It is the fastest 11/70 I tested hitting 1304 Dhrystones where other PDP-11/70s were more in the 1150 to 1200 range. Also, none of the big VAXes had FPP options since our accounting department didn’t used floating point calculations.

Best,

Mark

System          Sieve      Flops      Sieve   Float   Dhrys  Dhrystones

                                       VUPS    VUPS    VUPS     

PDP 11/03                                                 .13      200

PDP 11/23       .881628        10,178     .25     .05     .22      333

PDP 11/24                      11,500             .06

PDP 11/44       .568600        61,473     .39     .33

PDP 11/70       .204102       295,544    1.09    1.58     .87     1304

PDP 11/73       .319948        38,837     .69     .21     .56      833

PDP 11/83       .241563       359,416     .92    1.92     .77     1153

PDP 11/84       .236615       365,645     .94    1.95     .80     1200

M100-04         .218359       382,592    1.02    2.04     .83     1250

VAX 11/780      .222200       187,135    1.00    1.00    1.00     1500

uVAX II         .259100       144,829     .86     .77

VAX 8600        .059300     1,035,673    3.75    5.53

VAX 8700        .044920       885,201    4.95    4.73

VAX 6420        .032160     1,412,804    6.91    7.55   11.43    17141

VAX 6610        .007305     9,230,000   30.42   49.32   44.39    66578

VAX 3500        .084370       525,590    2.63    2.81    3.74     5612

MV3100 10e      .057030       766,470    3.90    4.10    5.89     8834

MV3100 30       .038906     1,132,743    5.71    6.05   10.65    15974

MV3100 80       .022187     1,987,578   10.01   10.62   15.15    22727

VS4000 90A      .007289     9,270,000   30.48   49.54   44.39    66578

Alpha 666Mhz    .000340   204,000,000  653.53    1090    1856  2783964  

[John Hudak]

There are some inaccuracies in your post.  The pdp11 cpu do in fact have clocks. As you point out, the instruction execution time, measured in clocks per instruction (CPI) varies with each instruction. The timing of a specific instruction will vary depending on what CPU is executing it. e.g. a mov mem-reg will be slower on a 11/04 versus an 11/70.  Point is, one needs to look at the processor handbook of the specific CPU to get the right instruction timing. This is due to implementation differences of the underlying hardware to do an instruction fetch, decode, execute.  So it is incorrect to compare cpu performance of two different PDP11s using clock frequency.  The base cpu instruction execution timing is determined without performance enhancements such as cache.  

The attempt to compare cpu performance using clocks of CPU, for example pdp11 to 68K, or 8086 etc. is also incorrect because the fundamental ISA is different.  The PDP11s are more closely aligned to the 8086 (even though it is a segmented architecture) than say the Sparc CPU, ARM or MIPS.  The latter are RISC type architectures designed to execute an instruction in one major clock cycle.  The execution sequence is generally fetch, decode, execute and writeback. 

One method to compare processor performance is to use benchmarking.  SPEC, SPECint, SPECfg (an others).  This approach introduces another set of variables  (e.g. compiler optimizations ) that can influence performance  comparisons between different machine architectures (generally CISC, RISC and specifically a PDP11/93 versus a RS6000. )  The benchmarks are more indicative of performance comparisons within a CPU family, e.g. pdp11/23 vs pdp11/73.   Digital created the VAX Unit of Performance (VUP) as a way to quantify relative performance across machines of the same architecture.  The VUP was essentially useless if used on a non VAX machine.  The rise is Dhrystones, Whetstones, and SPEC benchmarks allowed some better performance comparisons across different architectures.  Having said that, there are a number of ways to slant benchmarking numbers but that is a whole nother discussion.....

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/02BA77A4-93C2-4BDA-B2E5-82A2D3A50084%40matlockfamily.com.

[Jonathan Harston]

I'm not trying to compare PDP11 speed with other CPU speed, but PDP11 speed with

other PDP11 speed, mostly different versions of emulated PDP11s. If MOV R0,R0

executes in 1.96us on a 1979 PDP11/whatever and I can sorta call that "0.5MHz",

and from testing I find that MOV R0,R0 executes in 0.02us on EddiePDP emulator

running on a DT42 system, I can sorta call that "effectively a 20MHz PDP11". (Of

course, a full comparison would be timing a suite of various instructions to get a

spread across different instructions.)

I missed the 2022 thread on retrocomputing and StarDot, it contains useful information.

jgh

[Johnny Billquist]

Thing is, even different PDP-11 models will take different amount of
time for a MOV R0,R0, which is separate from clock speed.

Johnny

>    I just recently acquired a PDP-11/03 and was ableto compile

> <https://groups.google.com/d/msgid/pidp-11/02BA77A4-93C2-4BDA-
> B2E5-82A2D3A50084%40matlockfamily.com?
> utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> e6202d55-6ac9-45e8-b00a-323ebb1818bbn%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/e6202d55-6ac9-45e8-
> b00a-323ebb1818bbn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Tomasz Rola]

On Wed, Jul 08, 2026 at 12:25:36AM -0700, pbi...@gmail.com wrote:
> Read the thread
> https://retrocomputingforum.com/t/the-wide-ranging-performance-of-the-pdp-11/2615
> and check out the "Computer Engineering" (and other) references.

I would also had a look at comments section in the following source:

https://web.archive.org/web/20150123191735if_/http://www.dunnington.u-net.com/public/dhrystone.c

It is just a synthetic benchmark, but on the other hand it offers some
numbers to chew upon.

The computers range from C-64 to various Cray models. And there are
some PDPs and Vaxen, too.

--
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomas...@bigfoot.com **

[terri-...@glaver.org]

On Wednesday, July 8, 2026 at 7:05:34 PM UTC-4 b...@softjar.se wrote:

Thing is, even different PDP-11 models will take different amount of
time for a MOV R0,R0, which is separate from clock speed.

Exactly. And "benchmarks" for a particular PDP-11 model tend to neglect things like memory type (some models could have core or either of two types of semiconductor memory), the 11/70 talked to memory 32 bits at a time, later PDP-11s supported PMI memory, and so on. Add on memory interleave (where appropriate) and speeds can change dramatically as well.

Then you get into optional instruction sets (EIS / FIS / DIS / FPP / CIS) which can help certain benchmarks.

Not to mention operating system overhead, other tasks running, etc.

Clocks on PDP-11s were 'interesting'. As noted in the linked 2022 article, the J-11 used an external crystal running at 4x the actual "system clock" rate. So an "18MHz" J11 was actually a 4.5MHz part. The Intel 8080 did something similar, as did many other microprocessors that existed during the PDP-11's lifespan.

The PDP-11/70 used the M8139, a quad-wide board, to generate most of the processor timing. It is an incredibly complex mixed-signal board notoriously difficult to work on (it won't run reliably on an extender). And the 11/70 is partially synchronous and partially asynchronous.

[pbi...@gmail.com]

What is "DIS"?

EIS = Extended Instruction Set

FIS = Floating Instruction Set

FPP = Floating Point Processor (believe that this varies a bit depending on model/option)

CIS = Commercial Instruction Set

[Jon Callas]

> On Jul 10, 2026, at 23:18, pbi...@gmail.com <pbi...@gmail.com> wrote:
>
> What is "DIS"?
>

DIBOL Instruction Set. It was a "commercial" set with packed decimal, string instructions, and some others.

Jon

[Johnny Billquist]

I've only seen one or two references to that one. And it seemed to have
been a very short lived thing that was only ever available for the
LSI11. And no version of Dibol I've seen even mentions it.
(And hoping I didn't get any details wrong here...)

Johnny

[Anton Lavrentiev]

https://gunkies.org/wiki/KEV11-C_Commercial_Instruction_Set

Looks like just yet another name for what's better known as CIS

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/04088cba-2ba3-45fd-bb63-1f43f4dccbae%40softjar.se.

[Johnny Billquist]

"A subset of CIS".

Johnny

On 2026-07-11 15:48, Anton Lavrentiev wrote:
> https://gunkies.org/wiki/KEV11-C_Commercial_Instruction_Set <https://
> gunkies.org/wiki/KEV11-C_Commercial_Instruction_Set>

>
> Looks like just yet another name for what's better known as CIS
>
> On Sat, Jul 11, 2026, 9:11 AM Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> On 2026-07-11 09:01, Jon Callas wrote:
> >
> >
> >> On Jul 10, 2026, at 23:18, pbi...@gmail.com

> <mailto:pbi...@gmail.com> <pbi...@gmail.com

> <mailto:pbi...@gmail.com>> wrote:
> >>
> >> What is "DIS"?
> >>
> >
> > DIBOL Instruction Set. It was a "commercial" set with packed
> decimal, string instructions, and some others.
>
> I've only seen one or two references to that one. And it seemed to have
> been a very short lived thing that was only ever available for the
> LSI11. And no version of Dibol I've seen even mentions it.
> (And hoping I didn't get any details wrong here...)
>
>    Johnny
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

> Reading murder books
> pdp is alive!                    ||  tryin' to stay hip" - B. Idol
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/04088cba-2ba3-45fd-bb63-1f43f4dccbae%40softjar.se <https://
> groups.google.com/d/msgid/pidp-11/04088cba-2ba3-45fd-
> bb63-1f43f4dccbae%40softjar.se>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> CAAo%3Dyr2fZpa%2B-ConFFjuvfbATu-
> OT%2BdDN5Jwune3QDeM00B1ZQ%40mail.gmail.com <https://groups.google.com/d/
> msgid/pidp-11/CAAo%3Dyr2fZpa%2B-ConFFjuvfbATu-
> OT%2BdDN5Jwune3QDeM00B1ZQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Johnny Billquist]

By the way, the versions of Dibol I've seen (or have) don't even use CIS.
The only product that can generate code for CIS that I've ever seen is
Cobol.

Johnny

[terri-...@glaver.org]

On Saturday, July 11, 2026 at 9:11:55 AM UTC-4 b...@softjar.se wrote:

I've only seen one or two references to that one. And it seemed to have
been a very short lived thing that was only ever available for the
LSI11. And no version of Dibol I've seen even mentions it.
(And hoping I didn't get any details wrong here...) 

 
DEC tried selling a multi-user DIBOL system based on the LSI-11. It was one of those packaged "DECdatasystem" or similar systems. It obviously didn't have enough "oomph"*, even with the DIS option, so DEC transitioned the product to be 11/23 based as soon as the F11 CPU was available.

John Wilson has an LSI-11 DIS chip, I believe. His E11 is a diagnostics-passing PDP-11 emulator that runs on everything from bare x86 metal to Windows / Linux.

* Alpha Micro used the WD1600 (the LSI-11 chipset with different microcode**) to build multi-user systems that sort of looked like RSTS. 16 terminals on LSI-11 class hardware.

** I know of four, possibly five microcode variants for the WD1600:
1) The LSI-11
2) Native WD1600
3) Alpha Micro
4) Pascal MicroEngine
5) A custom one for Western Electric used in early high end stat muxes
Alpha Micro may have used the native instruction set, I'm not sure.

[Jon Callas]

> On Jul 11, 2026, at 06:11, Johnny Billquist <b...@softjar.se> wrote:
>
> On 2026-07-11 09:01, Jon Callas wrote:
>>> On Jul 10, 2026, at 23:18, pbi...@gmail.com <pbi...@gmail.com> wrote:
>>>
>>> What is "DIS"?
>>>
>> DIBOL Instruction Set. It was a "commercial" set with packed decimal, string instructions, and some others.
>
> I've only seen one or two references to that one. And it seemed to have been a very short lived thing that was only ever available for the LSI11. And no version of Dibol I've seen even mentions it.
> (And hoping I didn't get any details wrong here...)

I'm primarily a Vax guy, myself, but rummaging around in things tells me that CIS was only supported on the 11/44, and the F-11 CPUs (11/23, 23+, 11/24), and this was for the 11/03, and was a subset of DIS for the 11/03.

https://gunkies.org/wiki/KEV11-C_Commercial_Instruction_Set
https://gunkies.org/wiki/PDP-11_Commercial_Instruction_Set
https://gunkies.org/wiki/KDF11_CPUs

Jon

[Clem Cole]

below

On Sat, Jul 11, 2026 at 11:42 AM terri-...@glaver.org <terri-...@glaver.org> wrote:

...

** I know of four, possibly five microcode variants for the WD1600:
1) The LSI-11
2) Native WD1600
3) Alpha Micro
4) Pascal MicroEngine
5) A custom one for Western Electric used in early high end stat muxes
Alpha Micro may have used the native instruction set, I'm not sure.

I believe a couple of the Aerospace/DoD folks in Irvine/S. CA, folks like Hughes, Grumman, TRW et al, had projects that used the WD MCP-1600 family.  One of my friends had a summer job with one of them (TRW, I think, but I've long ago forgotten) and did microcoding with that chip for them.  It is possible they were using the WD 9000 [http://pascal.hansotten.com/ucsd-p-system/western-digital-micro-engine/], which was the HW base for the Pascal engine, but with different microcode. I also have no idea what became of those projects.

Also, althought I personally didn't do much with it, as it was just coming up/getting stable around the time I graduated, my brothers and sisters at CMU who were building CM* for the compute nodes used DEC LSI-11 boards (stock quad-height M7264 — KD11-F with KEV11-A/EIS processors).  They used both the stock WD MCP-1600 (original DEC-defined 11/5 emulation/written by WD) ucode and they built a WSC feature that was exploited for certain functions.  Although I may be remembering incorrectly, I don't think all nodes had WSC.  But adding WSC allowed them to replace portions of the standard DEC LSI-11 microcode with custom microprograms to accelerate operating-system primitives (e.g., faster context switching for StarOS and Medusa).  I also don't remember if they added csv/cret instructions like the 11/40Es; but that was a popular hack at CMU in those days if your processor could support it, and with a limited 64K address size, the smaller binary alone made it useful [Note the "Pmap" processor in the Kmaps was AMD 2900 family, however].   ISTR the ucode tools were homegrown, ran on the PDP-10s, and used the same toolset as the 11/40E systems in C.mmp and the UNIX systems IUS and SUS (which had csv/cret - I used to program those systems and a couple of other 11/40Es, and used the tools for them).

[tsyb...@gmail.com]

And another one

https://forum.vcfed.org/index.php?threads/pdp-11-%CF%80-benchmark.56998/

[Jacob Ritorto]

On Wed, Jul 8, 2026 at 07:10 Mark Matlock <ma...@matlockfamily.com> wrote:

  Also, below the PDP-11/70 tests are from Jacob Ritorto’s PDP-11/70 that has some 3rd party performance options. It is the fastest 11/70 I tested hitting 1304 Dhrystones where other PDP-11/70s were more in the 1150 to 1200 range. Also, none of the big VAXes had FPP options since our accounting department didn’t used floating point calculations.

Those “third party performance options” likely responsible for the high ratings are the Setasi PEP-70 and HyperCache. Tom Uban should be noted here as the prior curator of this system — seems it’s a particularly wonderful one and wonderfully preserved due to Tom’s diligence in care.  Thanks again, Tom!

—Jake

[Jonathan Harston]

To get some concrete figures, I patched my emulator to generate a profile of instructions executed

and executed some of the day-to-day code that I use to get a spread of "normal"ish instruction

counts. I then used the instruction and semiconductor memory access timing from the 1979 PDP11

Handbook.

The PDP11/04 timing:

* the top 10 instructions by count averaged 3.57us per instruction, giving 0.28MHz

* the top 10 instructions by timing averaged 3.59us per instruction, giving 0.28MHz

The PDP11/70 timing:

* the top 10 instructions by count averaged 0.79us per instruction, giving 1.26MHz

* the top 10 instructions by timing averaged 0.81us per instruction, giving 1.24MHz

So, for comparing PDP11s, I'm going call the PDP11/04 0.28MHz and the PDP11/70 1.25MHz.

jgh

[Johnny Billquist]

I'm not sure I understood at all what you did.
But I'm also curious where the cache enters the picture on the 11/70 there.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> cafc6619-780e-4113-94d3-89ff61a551c6n%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/
> cafc6619-780e-4113-94d3-89ff61a551c6n%40googlegroups.com?

[Paul Koning]

Historically, clockless machines are extremely rare.  The only one I can think of is the one-off ARRA 1, from around 1950 at the Dutch MC (now CWI).  It was built around relays, by theoretical physicists with no background in electronics, and never really worked.  It was replaced by an entirely different machine, misleadingly called ARRA 2, that is clocked, and was designed by Gerrit Blaauw, a student of Aiken who later became the architect of the IBM 360.

I remember a silicon startup in the 1990s (probably) that had created a set of design tools to allow building unclocked VLSI.  Their plan was to build a RISC processor that way.  I don't believe they delivered, though they did eventually create an Ethernet switch chip using this technology.  It didn't seem to have any real benefits and the tools were sufficiently exotic that no one picked them up.

Back to the PDP-11: the Unibus is indeed clockless.  But the CPUs are not.

[Bradford Miller]

I thought Gene Amdahl was the principal architect of the 360, no?

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/f658faa9-9cbb-4ee6-ab9c-3171db9271den%40googlegroups.com.

[Paul Koning]

Yes, I misquoted Wikipedia, which says he was one of the architects, along with "Fred Brooks, Gene Amdahl, and others".

[Clem Cole]

Right.  At one of my startups a few years back, I got to know Russ Robelen, who was the lead for the Model 50 and the guy who convinced Brooks and Amhadl to use microcoding for the project. It seems that IBM had been experimenting with the microcoding concept in its Hursley, UK, lab.   Russ had spent some time visiting there and brought back the idea. His stories from the time were a lot of fun to hear.   He says that Gene was skeptical of microcode (too much like software), but Brooks and Evans convinced TJ Watson that, at worst, the first few machines (models 30 and 50) could be sold as follow-ons to the 1400 series.  The argument was that the microcode could be written to emulate them, and that the new "Solid Logic Technology" (SLT) Bloch and team had been cooking up (based on earlier "Current Mode Logic" plus some help from Motorola) was cheaper and would be more profitable than building the 1400 series machines.  [By 1962, Moto was already going a different path, calling their implementation Motorola Emitter-Coupled Logic (MECL), and eventually, by MECL III, created a set of DIP packages for it to market to other firms, such as DEC for its KL series]. 

I'm not sure I've mentioned it on this list previously, but Russ also has a great story about how we got an 8-bit byte and the 32-bit fullword.  Gene thought both were wasteful, since ASCII was only 7 bits at that time (and S/360 was targeted to be ASCII - remember IBM and AT&T were two firms pushing what would become ASCII); and Gene didn't think you needed much more than 24 bits "to do useful work." Brooks was the manager for the entire project; he tossed him out of his office and told Gene, "Don't come back until they are a power of two.  It's just too hard to program."   Brooks relented on a 24-bit address, but, in what Gordon Bell would later call the smartest move anyone ever made in the computer field, he had Gene store them in a fullword.  Amdahl thought it was a terrible waste and that it would really hurt them in terms of the cost of manufactured goods when IBM rolled out the S/360.   But that single feature allowed the ISA to outlive every other contemporary and many future ISAs.  

A few years later, Russ would go on to lead the IBM ASC, from which many ideas for modern computers were drawn.  He's still around, BTW, and I was kidding him when we hit the Specter security issue at Intel a couple of winters back.  We all took the idea of branch prediction (and the whole IBM idea of turning a computation into a "data flow" internal to the CPU) from the ASC, and every modern ISA implementation since has had that same issue.  Intel was just the first to have people realize it was a problem.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/34e36f6d-2c7b-4927-99d5-4a18b37e2e01n%40googlegroups.com.

[Johnny Billquist]

Since when did IBM push for ASCII???

Johnny

On 2026-08-09 00:05, Clem Cole wrote:
> Right.  At one of my startups a few years back, I got to know Russ
> Robelen, who was the lead for the Model 50 and the guy who convinced
> Brooks and Amhadl to use microcoding for the project. It seems that IBM
> had been experimenting with the microcoding concept in its Hursley, UK,
> lab.   Russ had spent some time visiting there and brought back the
> idea. His stories from the time were a lot of fun to hear.   He says
> that Gene was skeptical of microcode (too much like software), but
> Brooks and Evans convinced TJ Watson that, at worst, the first few
> machines (models 30 and 50) could be sold as follow-ons to the 1400
> series.  The argument was that the microcode could be written to emulate
> them, and that the new "Solid Logic Technology" (SLT) Bloch and team

> hadbeen cooking up (based on earlier "Current Mode Logic" plus some help

> from Motorola) was cheaper and would be more profitable than building
> the 1400 series machines.  [By 1962, Moto was already going a different
> path, calling their implementation Motorola Emitter-Coupled Logic
> (MECL), and eventually, by MECL III, created a set of DIP packages for
> it to market to other firms, such as DEC for its KL series].
>
> I'm not sure I've mentioned it on this list previously, but Russ also
> has a great story about how we got an 8-bit byte and the 32-bit
> fullword.  Gene thought both were wasteful, since ASCII was only 7bits
> at that time (and S/360 was targeted to be ASCII - remember IBM and AT&T
> were two firms pushing what would become ASCII); and Gene didn't think
> you needed much more than 24 bits "to do useful work." Brooks was the

> manager forthe entire project; he tossed him out of his office and told

> Gene,"Don't come back until they are a power of two.  It's just too hard
> to program."   Brooks relented on a 24-bit address, but, in what Gordon
> Bell would later call the smartest move anyone ever made in the computer
> field, he had Gene store them in a fullword.  Amdahl thought it was a
> terrible waste and that it would really hurt them in terms of the cost
> of manufactured goods when IBM rolled out the S/360.   But that single
> feature allowed the ISA to outlive every other contemporary and many
> future ISAs.
>
> A few years later, Russ would go on to lead the IBM ASC, from which many
> ideas for modern computers were drawn.  He's still around, BTW, and I
> was kidding him when we hit the Specter security issue at Intel a couple
> of winters back.  We all took the idea of branch prediction (and the
> whole IBM idea of turning a computation into a "data flow" internal to
> the CPU) from the ASC, and every modern ISA implementation since has had
> that same issue.  Intel was just the first to have people realize it was
> a problem.
>
> On Sat, Aug 8, 2026 at 4:55 PM Paul Koning <pa0...@gmail.com
> <mailto:pa0...@gmail.com>> wrote:
>
> Yes, I misquoted Wikipedia, which says he was one of the architects,
> along with "Fred Brooks, Gene Amdahl, and others".
>
> On Saturday, August 8, 2026 at 4:50:27 PM UTC-4

> bradford...@gmail.com <mailto:bradford...@gmail.com> wrote:
>
> I thought Gene Amdahl was the principal architect of the 360, no?
>
>> On Aug 8, 2026, at 2:12 PM, Paul Koning <pa0...@gmail.com> wrote:
>>
>> Historically, clockless machines are extremely rare.  Theonly
>> one I can think of is the one-off ARRA 1, from around 1950 at
>> the Dutch MC (now CWI).  It was built around relays, by
>> theoretical physicists with no background in electronics, and
>> never really worked.  It was replaced by an entirely different
>> machine, misleadingly called ARRA 2, that is clocked, and was
>> designed by Gerrit Blaauw, a student of Aiken who later became
>> the architect of the IBM 360.
>> I remember a silicon startup in the 1990s (probably) that had
>> created a set of design tools to allow building unclocked
>> VLSI.  Their plan was to build a RISC processor that way.  I
>> don't believe they delivered, though they did eventually
>> create an Ethernet switch chip using this technology.  It
>> didn't seem to have any real benefits and the tools were
>> sufficiently exotic that no one picked them up.
>> Back to the PDP-11: the Unibus is indeed clockless.  But the
>> CPUs are not.
>>
>> On Thursday, July 16, 2026 at 6:48:26 PM UTC-4 b...@softjar.se

>> <http://softjar.se/>wrote:

>> d/msgid/pidp-11/ <https://groups.google.com/d/msgid/pidp-11/>
>> > cafc6619-780e-4113-94d3-89ff61a551c6n%40googlegroups.com
>> <http://40googlegroups.com/><https://
>> >groups.google.com/d/msgid/pidp-11/ <http://
>> groups.google.com/d/msgid/pidp-11/>
>> > cafc6619-780e-4113-94d3-89ff61a551c6n%40googlegroups.com
>> <http://40googlegroups.com/>?

>> > utm_medium=email&utm_source=footer>.
>>
>> --
>> Johnny Billquist || "I'm on a bus
>> || on a psychedelic trip
>> email:b...@softjar.se|| Reading murder books
>> pdp is alive! || tryin' to stay hip" - B. Idol
>>
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "[PiDP-11]" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email topidp-11+u...@googlegroups.com.
>> To view this discussion visithttps://groups.google.com/d/
>> msgid/pidp-11/f658faa9-9cbb-4ee6-

>> ab9c-3171db9271den%40googlegroups.com <https://
>> groups.google.com/d/msgid/pidp-11/f658faa9-9cbb-4ee6-
>> ab9c-3171db9271den%40googlegroups.com?
>> utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/34e36f6d-2c7b-4927-99d5-4a18b37e2e01n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> pidp-11/34e36f6d-2c7b-4927-99d5-4a18b37e2e01n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> CAC20D2PfkoY7Fp5oBeEBfMp0cKPB5sV%3DjkZXsThLxjOTm4w-Vg%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/
> CAC20D2PfkoY7Fp5oBeEBfMp0cKPB5sV%3DjkZXsThLxjOTm4w-Vg%40mail.gmail.com?

[Ken Hansen]

The story I always heard was IBM was EBCDIC and the industry was starting to coalesce around ASCII, and the federal gov't decided to force the issue - refusing to give federal money for any system that didn't use ASCII. IBM refused to comply, and gov't buyers refused to buy/lease non-IBM systems, so exceptions were granted, until the gov't relented and allowed buying non-ASCII equipment with federal grants.

I don't think I've ever seen/heard of an IBM machine that was ASCII-based before the IBM PC.

Ken

[Bruce Robertson]

Let's not forget the CDC Cyber series and similar with 60 bit words and
6 bit character encoding (BCDIC iirc)... I remember the reason
identifiers in languages like Fortran and assembler were limited to 10
characters was because you could move an entire identifier around in one
60 bit word and one instruction.  That's one way to make your computer
super fast!  Strings?  We don't need no stinkin' strings! And who needs
lower case???

If you wanted ASCII on those machines, you burned two 6 bit bytes.

[Steve Platt]

How about that PDP-10? 36 bit words, usable with 6, 8, or 9 bit bytes.  Yes, 6-character IDs, and classic Adventure was limited to 6-character "words" for user commands. GO SOUTH, KILL DRAGON...

[Johnny Billquist]

The PDP-10 can use bytes the size from 1 bit to 36 bits. But yes,
SIXBIT, as well as 7 bit and 9 bit was pretty common. 8 bit bytes were
used less often, as it wasted more space, or added more complexity. But
the CPU as such have no problems with any byte size up to 36 bits.

And yeah, IBM started out with just BCD, which was just for numeric
stuff and used 4 bits. Then they started doing text (I guess CDC
followed the same idea) with BCDIC which used 6 bits. And then IBM
extended it to 8 bits, where it then stayed.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/20dddcd1-8c22-46d4-9e22-82fb2314a6c4%40comcast.net <https://
> groups.google.com/d/msgid/
> pidp-11/20dddcd1-8c22-46d4-9e22-82fb2314a6c4%40comcast.net?

[Clem Cole]

First off, System/360 featured a dedicated control bit (Bit 12) in the Program Status Word (PSW) known as the ASCII mode bit. When this bit was set to 1, the CPU altered the behavior of its Zoned Decimal (unpacked) mathematical operations. In EBCDIC mode, the high-order nibble for zone characters was formatted as 1111 (0xF).  In ASCII mode, the S/360 automatically generated the high-order nibble as 0101 (0x5) to match the USASCII standard for numeric signs and numeric layouts.

Remember that IBM chaired the ASCII committee.  The plain of record and what IBM had told its customers for S/360 was that it would be ASCII, but OS/360 was horribly behind. Since early IBM systems were BCDIC (6-bit), and different S/360 models supported emulation for BCDIC, BCDIC and the new extended (8-bit) EBCDIC were also supported. In fact, an early instruction (TR) was there to help handle different codes [Programmers loaded a 256-byte translation matrix into memory]. The TR instruction then read a BCDIC or EBCDIC string, used each character’s binary value as an offset into the table, and instantly replaced it with the corresponding ASCII or whatever byte]. 

Which was the whole point.  The reason why AT&T and IBM were pushing for ASCII in the early 1960s was that it was a real problem.  Everybody had their own code (IMO CDC was the worst, they had numerious 6 and 12 vits codes, program on them was often a mess).

Coming back to S/360, the ASCII-based peripherals were also behind.  In fact, so many of IBM's peripherals were not ready for ASCII in time for launch, this hardware bit (PSW 12) went mostly unused.  So IBM management decided to go with EBCDIC.  That decision made a number of IBM folks and customers, including the ASCII committee chair, quite upset at the time.

WRT to bit 12, by the time of the 370, since it was not being used, it was eventually removed. 

You are correct that the first pure ASCII processor for IBM was the Intel 8088 used in the PC; but in the mid-70s, the Series/1 had even more support for ASCII than S/360.  The Series/1 featured special input/output cards with RS-232 serial interfaces. This allowed users to connect to ASCII-based remote terminals (such as the IBM 3101 and 3151) or modems, rather than to traditional coaxial EBCDIC mainframe terminals. 

 

Sent from a handheld; expect more typos than usual

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/0CF588B5-F839-44C0-8116-7B66A5710DDA%40w5fc.org.

[Clem Cole]

On Sat, Aug 8, 2026 at 8:09 PM Bruce Robertson <bru...@gmail.com> wrote:

Let's not forget the CDC Cyber series and similar with 60 bit words and
6 bit character encoding (BCDIC iirc)... I remember the reason
identifiers in languages like Fortran and assembler were limited to 10
characters was because you could move an entire identifier around in one
60 bit word and one instruction.  That's one way to make your computer
super fast!  Strings?  We don't need no stinkin' strings! And who needs
lower case???

If you wanted ASCII on those machines, you burned two 6 bit bytes.

And what was worse was that they could never seem to decide how they would map the 12 bits; "DISPLAY CODE" was the name of one of them.  IIRC, that was the scheme Wirth and Team used with the first Pascal Compiler.   But there were a few of them.   When we were trying to set up the Tektronix network, Stan Smith wrote an IP/TCP for Kronos.  He and I spent way too many hours trying to make that talk properly to the Teklabs 11/70 running 3Com's UNET over a HyperChannel link.

On 8/8/26 3:20 PM, Ken Hansen wrote:
> The story I always heard was IBM was EBCDIC and the industry was starting to coalesce around ASCII, and the federal gov't decided to force the issue - refusing to give federal money for any system that didn't use ASCII. IBM refused to comply, and gov't buyers refused to buy/lease non-IBM systems, so exceptions were granted, until the gov't relented and allowed buying non-ASCII equipment with federal grants.
>
> I don't think I've ever seen/heard of an IBM machine that was ASCII-based before the IBM PC.
>
> Ken
>
>> On Aug 8, 2026, at 17:13, Johnny Billquist <b...@softjar.se> wrote:
>>
>> Since when did IBM push for ASCII???
>>
>>   Johnny

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/84f34668-1a70-4836-be78-0b97b1cd491e%40gmail.com.

[Steve Platt]

Ack, I forgot the 7-bit (full ASCII) breakdown.  Five characters per word, yes, that rings a bell for ADVENT.  Don't know how I slipped to six chars for ADVENT.

8 bits was used for ASCII-plus-parity.  9 bits for 8-bits-plus-parity.

On a side note, the other JSR discussion reminds me of my IBM 360 programming days.  Subroutine calls were by "BALR 14" -- branch and link register -- branch to a new location, saving the old program counter in the listed register.  I still have some green cards somewhere, along with a few keypunch drums and card saw.  EBCDIC was just plain ugly -- the alphabet split up into chunks and all.  At least ASCII has them all in order and in sequence.

Steve

[Johnny Billquist]

I will not claim I know anything about IBM systems, but zoned decimal
packed strings stuff one digit per byte. If you were to play "ascii"
with that, the high nybble should be 3, not 5.
In ascii, a "1" is hex 31, not 51.

Johnny

On 2026-08-09 02:53, Clem Cole wrote:
>
> First off, System/360 featured a dedicated control bit (Bit 12) in the
> Program Status Word (PSW) known as the ASCII mode bit. When this bit was

> set to|1|, the CPU altered the behavior of its Zoned Decimal (unpacked)
> mathematical operations.In EBCDIC mode, the high-order nibble for zone
> characters was formatted as |1111| (|0xF|).In ASCII mode, the
> S/360 automatically generated the high-order nibble as |0101| (|0x5|) to

> match the USASCII standard for numeric signs and numeric layouts.
>
> Remember that IBM chaired the ASCII committee.  The plain of record and
> what IBM had told its customers for S/360 was that it would be ASCII,
> but OS/360 was horribly behind. Since early IBM systems were BCDIC (6-
> bit), and different S/360 models supported emulation for BCDIC, BCDIC
> and the new extended (8-bit) EBCDIC were also supported. In fact, an

> early instruction (TR) was there tohelp handle different codes

> [Programmers loaded a 256-byte translation matrix into memory]. The |TR|
>  instruction then read a BCDIC or EBCDIC string, used each character’s
> binary value as an offset into the table, and instantly replaced it with
> the corresponding ASCII or whatever byte].
>

> Whichwas the whole point.  The reason why AT&T and IBM were pushing for

> ASCII in the early 1960s was that it was a real problem.  Everybody had
> their own code (IMO CDC was the worst, they had numerious 6 and 12 vits
> codes, program on them was often a mess).
>
> Coming back to S/360, the ASCII-based peripherals were also behind. In
> fact, so many of IBM's peripherals were not ready for ASCII in time for
> launch, this hardware bit (PSW 12) went mostly unused.  So IBM
> management decided to go with EBCDIC.  That decision made a numberof

> IBM folksand customers, including the ASCII committee chair, quite
> upsetat the time.

>
> WRT to bit 12, by the time of the 370, since it was not being used, it
> was eventually removed.
>
> You are correct that the first pure ASCII processor for IBM was the
> Intel 8088 used in the PC; but in the mid-70s, the Series/1 had even
> more support for ASCII than S/360.  The Series/1 featured special input/
> output cards with RS-232 serial interfaces. This allowed users to
> connect to ASCII-based remote terminals (such as the IBM 3101 and 3151)
> or modems, rather than to traditional coaxial EBCDIC mainframe terminals.
> Sent from a handheld; expect more typos than usual
>
> On Sat, Aug 8, 2026 at 6:20 PM Ken Hansen <n2...@w5fc.org
> <mailto:n2...@w5fc.org>> wrote:
>
> The story I always heard was IBM was EBCDIC and the industry was
> starting to coalesce around ASCII, and the federal gov't decided to
> force the issue - refusing to give federal money for any system that
> didn't use ASCII. IBM refused to comply, and gov't buyers refused to
> buy/lease non-IBM systems, so exceptions were granted, until the
> gov't relented and allowed buying non-ASCII equipment with federal
> grants.
>
> I don't think I've ever seen/heard of an IBM machine that was ASCII-
> based before the IBM PC.
>
> Ken
>
> > On Aug 8, 2026, at 17:13, Johnny Billquist <b...@softjar.se

> <mailto:b...@softjar.se>> wrote:
> >
> > Since when did IBM push for ASCII???
> >
> >  Johnny
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> pidp-11/0CF588B5-F839-44C0-8116-7B66A5710DDA%40w5fc.org <https://
> groups.google.com/d/msgid/pidp-11/0CF588B5-
> F839-44C0-8116-7B66A5710DDA%40w5fc.org>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> CAC20D2NsJV657T6o1LxKo-WFqNb6tJah35xQ%2B9KbyLzjJB0r_A%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/CAC20D2NsJV657T6o1LxKo-
> WFqNb6tJah35xQ%2B9KbyLzjJB0r_A%40mail.gmail.com?

[Paul Koning]

I don't remember the details, but I remember playing with "ASCII" as implemented in OS/360.  It wasn't.  It look vaguely like it, but the top bits weren't in the right place.  So if you needed to deal with real ASCII, as I did for a utility to print listing files from a tape written by RSTS V5, you still had to translate -- in which case you might as well translate to EBCDIC.  BTW, EBCDIC has lower case, and there were 1403 print chains for that, I used them with that utility.

[Adam Thornton]

The Rice Institute Computer (R1) was clockless.  It was a one-off, one of the last of the big homebrew institutional research machines, and was largely inspired by Von Neumann's MANIAC-II.

https://web.archive.org/web/20080224035658/http://www.princeton.edu/~adam/R1/r1rpt.html

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/f658faa9-9cbb-4ee6-ab9c-3171db9271den%40googlegroups.com.

[Clem Cole]

below

On Sat, Aug 8, 2026 at 10:03 PM 'Steve Platt' via [PiDP-11] <pid...@googlegroups.com> wrote:

Ack, I forgot the 7-bit (full ASCII) breakdown.  Five characters per word, yes, that rings a bell for ADVENT.  Don't know how I slipped to six chars for ADVENT.

8 bits was used for ASCII-plus-parity.  9 bits for 8-bits-plus-parity.

On a side note, the other JSR discussion reminds me of my IBM 360 programming days.  Subroutine calls were by "BALR 14" -- branch and link register -- branch to a new location, saving the old program counter in the listed register. 

These all date back to the original "Wheeler Jump" [ https://en.wikipedia.org/wiki/Wheeler_Jump ]. It's really all about the calling conventions and how much help the hardware/ISA gives the programmer. Modern systems tend to use a hardware stack that grows downward, and old systems used what IBM called the "push down save area."  But even with an ISA like EDSAC's, you can have them. I got a little help here from Google to make a table:

Feature	EDSAC (Wheeler)	PDP-8 (JMS)	IBM 360 (BALR/BASR)	PDP-11 (JSR)
Where is Return Address Kept?	Inside the subroutine's exit instruction.	Inside the subroutine's entry memory cell.	Inside a CPU general register (R14).	Immediately in a link register, while old register data goes onto a hardware stack.
Code Modifies Itself?	Yes. The program rewrites its own instructions.	No. Memory is written to, but it is data slot alteration.	No. Purely read-only code segments (re-entrant capable).	No. Read-only code segments (re-entrant capable).
Nesting Overhead	Destroys previous return address; crashes.	Destroys previous return address; loops infinitely.	Overwrites register; requires manual code to save registers to memory.	None. The hardware automatically increments/decrements the stack pointer.
Primary Structural Focus	Self-Modifying Code	Inline Branch Storage	Link Registers	Centralized Stack Architecture

 

I still have some green cards somewhere, along with a few keypunch drums and card saw.  EBCDIC was just plain ugly -- the alphabet split up into chunks and all. 

EBCDIC and its predecessor, BCDIC, if you look at them from a programming standpoint, but they both make sense from IBM's original business before computers, as Wikpedia puts it: "Herman Hollerith's punched card machines revolutionized data processing in the late 19th century. Long before electronic digital computers, electromechanical "unit record equipment" sorted, counted, and tabulated data using physical cards, laying the direct organizational and technical foundation for IBM."  Here is a picture of the same found via Google of the 64 character BCDIC layout.

The CHM has this picture explaining the positions, which I cribbed much of the info below.

Looking at this a little deeper, you will note that the IBM (Hollerith) Punched Card Standard has 12 horizontal rows  — divided into two distinct regions: the Zone Rows (Top 3 rows): Labeled 12, 11, and 0, and the Numeric Rows (Bottom 9 rows): Labeled 1 through 9.   Historically, an uppercase letter required exactly two punches in a single column: one Zone punch and one Numeric punch.  Because the English alphabet (and IBM's engineers did not care about anything else at that point) has 26 letters, IBM split it mechanically into three chunks across the 9 numeric buttons on a card punch machine: 9 + 9 + 8 = 26.

So for 6-bit BCDIC, the 2 most-significant bits mapped directly to the Zone punches on a card, and the 4 least-significant bits mapped to the Numeric punches. Note that both A-I and J-R fill positions 1–9 perfectly, but S to Z skip position 1.  To punch the letters A through I, you used a 12-zone punch + numeric digits 1 through 9. To punch J through R, you used an 11-zone punch + numeric digits 1 through 9.  For the last group (S through Z), IBM used the 0 zone punch. However, it turned out that the 0 punch was a major mechanical headache. On accounting machines, a single punch in row 0 already meant the number zero.

So if you combined a 0 zone punch with a 1 numeric punch, old mechanical card sorters couldn't easily tell the difference between the letter S and a numeric sequence containing a zero. To prevent errors/miscounts, IBM outlawed the combination of 0 Zone + 1 Numeric.  As a result, the letter S was forced to start at 0 Zone + 2 Numeric. This offset pushed the rest of the alphabet down, ending Z at the numeric value 9.

In 1964, when IBM designed the 8-bit EBCDIC for the System/360, business economics forced the engineers to maintain 100% backward compatibility with billions of paper punch cards already sitting in corporate warehouses. So, EBCDIC simply wrapped a translation layer over the old punch combinations: The upper nibble (MSB) explicitly states which Zone row is punched. The lower nibble (LSB) explicitly states which Numeric row is punched.  If you look at how the upper nibbles (MSB hex values) line up with the Hollerith cards. C in the upper nibble = 12 Zone (Letters A–I), D in the upper nibble = 11 Zone (Letters J–R), E in the upper nibble = 0 Zone (Letters S–Z), F in the upper nibble = No Zone (Pure numbers 0–9). Finally, because hexadecimal nibbles range from 0 to F (16 total), while a punch card has only 9 numeric options (1 to 9), there are 7 empty slots at the end of every row. IBM simply left the binary values A, B, C, D, E, and F unassigned in those alphabetic rows. This is why I (Hex C9) is separated from J (Hex D1) by a massive bunch of unassigned control blocks.

Note: I tried to find pictures of both BCDIC and EBCDIC, but Google failed to find any for the former.  But this is a good one for EBCDIC

At least ASCII has them all in order and in sequence.

It's not that BCDIC and EBCDIC didn't have order; the issue is that their order was no longer important to anyone but IBM. 😱

[Clem Cole]

On Sun, Aug 9, 2026 at 1:44 PM Paul Koning <pa0...@gmail.com> wrote:

I don't remember the details, but I remember playing with "ASCII" as implemented in OS/360.  It wasn't.  

Be careful here.  You are correct in your observation, but what they did at the time was in bounds.   ASA X3.4-1963 was the first version; uppercase only, included 28 unassigned slots. That was IBM's target, and remember it's 7-bit.  ASA X3.4-1965 was an unpublished draft; proposed lowercase letters.   X3.4-1967 was a major revision: added lowercase letters and restructured control codes; X3.4-1968 was a minor revision: standardized text stylization for a few symbols.  My experience, and certainly from our DEC days, is that the 67/68 versions are what most people think of as "ASCII" [I'd have to go back and look at the differences, but they are fairly close].  

I once asked Russ if the problem was that the 360 project was targeting X3.4-1963 and by the time of the full standards in the late 60s, it was no longer interesting to IBM Management.  He said, it was only when they saw so many of the customers were using minicomputers like PDP-11s and DG Novas and front ends that they decided to create the Series/1 and made sure it supported more of the industry-recognized standards, plus they had released the Intel 8085 based 3101 terminal in 1979 and eight years later the 3151 which used a Motorola processor (I think a 6800 family but it might have been 6809).

 

It look vaguely like it, but the top bits weren't in the right place.  So if you needed to deal with real ASCII, as I did for a utility to print listing files from a tape written by RSTS V5, you still had to translate -- in which case you might as well translate to EBCDIC.  BTW, EBCDIC has lower case, and there were 1403 print chains for that, I used them with that utility.  

Right, this maps to Russ's comments.  The ASCII support for S/360 was really killed off.  In fact, the 370 dropped the ASCII bit from the PSW (and, back to the other thread, the 370 had to switch from BALR to the model 67's BASR instruction to avoid wiping out the upper 8 bits).

[PDP11 Processor]

No problem until you have to transfer a mag tape from the CDC6600 to an IBM 360. A confident IBM operator asked for the data on tape and didn't specify a format. Of course using defaults the 360 couldn't read the tape (think it was still KRONOS at that stage). The operator at one stage extended a section of tape to confirm using a liquid that there was a block structure. Then there was the discussion on character sets to force the 360 to read the tape.