From: jmfbahciv on
In article <45f6dd7d$1(a)darkstar>, eugene(a) (Eugene Miya) wrote:
>In article <et647p$8qk_016(a)>,
> <jmfbahciv(a)> wrote:
>>In article <45f59384$1(a)darkstar>, eugene(a) (Eugene Miya) wrote:
>>>In article <esp4dj$8qk_002(a)>,
>>> <jmfbahciv(a)> wrote:
>>>>In article <1173274591.042195.246470(a)>,
>>>> "Quadibloc" <jsavard(a)> wrote:
>>>>>Eugene Miya wrote:
>>>>>> A step backward John.
>>>>>> the S-1 which was supposed to be DEC-10 compatible. Never finished.
>>>>>I was waiting for someone to point out that, yes, the perfect computer
>>>>>*does* have a 36-bit word, and it is the PDP-10.
>>>>I thought your goal was to design a general purpose architecture?
>>>>That is the only kind of architecture that can fulfill the
>>>>stated goal in the subject header of this thread. One of
>>>>the pluses of the PDP-10 architecture is that it was the
>>>>perfect computer for anybody.
>>The key word was "anybody".
>I knew the key word was anybody.
>>This meant that anybody could
>>use the architecture and get something done.
>I know you mean that and mean well, but that's not an app perspective.

Of course not. But it had damned well be from the OS' perspective.
That is the mindset change that has to happen.

>>It was never meant to be a specialized architecture.
>No one said one had to have a specialized architectures. Very few
>people see non-Von Neumann machines or analog machines, etc.
>>TOPS-10 was described
>>as general purpose timesharing. This implies "anybody".
>How long do you want to wait for solution?

But it is not a difficult problem.
>>>>It is against human nature laws to produce a computer that
>>>>is perfect for everybody.
>>>Likely true.
>>There is no likely about it. One man's hell is another man's
>While hell and paradise likely have Dantean depths, the analogy is too

No, it is not. You have to keep that in your head if you design
anything that is going to try to be the "perfect, can work for
anybody" goal.
>>>>I think this is your tradeoff litmus test.
>>>Not bad.
>Means that I think you are likely in the right directions (maybe a
>quadrant) but too binary.

I may be too binary, but I know how to do it. I just can't talk
using the details in my lanaguage. It's a mindset; the technology
falls out.

> Better papers that litmus exist if you insist
>on a chemistry analogy. So I reserve judgment on your fuller analogy
>on nature's laws.

It has more to do with how humans work and think rather than
laws of nature. There is already one guy who is actively
working on this kind of stuff. I've been watching his progress;
his approach will be a part of the solution....or it should be
if people bother to think things through first.


From: jmfbahciv on
In article <mddtzwpgcq7.fsf(a)>,
Rich Alderson <news(a)> wrote:
>jmfbahciv(a) writes:
>> In article <et4hl0$1vlg$1(a)>, johnl(a) (John L) wrote:
>>>> So what was missing in the PDP-10 architecture?
>>> Address bits, the same thing that killed every other old architecture.
>> Address bits with respect to what? I don't see the problem.
>> I'm not a hardware type but a fetch for effective address
>> calculations can be 36-bits wide. Can it not?
>No, it cannot. The largest offset from an index base (the only way to go
>beyond 18 bits of address) is 2^18, and there's no way to get around that.

Why? I still don't understand why you are constraining the index
base to be 18 bits. I'd make it 36 (if we had a 36-bit word
boundary architecture). Those 18 bits is 18 wires, right?

>And there's only one of those per instruction, for most classes of

There are many free instruction number slots left. There are quite
a few device codes left.

I don't see why the instuction set can't be "extended" (a term I
am hesitant to use) to be 72-bits. The KI had already started
tranforming from 36 to 72.

I never understood why this one didn't continue.

>> You don't have to change current instructions. You can
>> add, or extend, existing instructions to manipulate greater
>> than 18-bit addresses.
>> For example, refer to the DECsystem-10 Reference Card, part number
>> DEC-10XSRCA-B-D. Note that the blue print indicated the KI-10
>> only add-ons.
>>> The DEC 20 extended addressing was a clever hack, but it was basically
>>> 286 style segmented addresses which are a nightmare to program.
>> Of course it was a hack. It was a way to provide computing service
>> until the next architecture was in production.
>> I'm not sure that we ever expected regular users to use it.
>Since it is the only way to get a program with large data structures to fit
>more than 256KW of memory, and since large data structures are required for a
>number of modern applications, regular users *have* to use it if thye are
>to program those applications on the PDP-10 architecture.

By "use it", I meant code it. I was assuming that regular everyday
users wouldn't be coding in machine language.


From: jmfbahciv on
In article <45f730c0$0$16659$4c368faf(a)>,
Peter Flass <Peter_Flass(a)> wrote:
>jmfbahciv(a) wrote:
>> In article <et4hl0$1vlg$1(a)>, johnl(a) (John L) wrote:
>>>>So what was missing in the PDP-10 architecture?
>>>Address bits, the same thing that killed every other old architecture.
>> Address bits with respect to what? I don't see the problem.
>> I'm not a hardware type but a fetch for effective address
>> calculations can be 36-bits wide. Can it not?
>> You don't have to change current instructions. You can
>> add, or extend, existing instructions to manipulate greater
>> than 18-bit addresses.
>If I'm doing the math right, this is 64 Giga-*Words*, or 256 Gigabytes
>assuming you pick 9-bit bytes. Should be enough. If you need more,
>change the page-table format (paging makes it a -20, right?)

Wrong. You want to be able to "extend" it without any changes.
Changes imply that something of old would no longer work.

> One adress
>space could still only map 64GW, but you could have lots of address spaces.

You are thinking grom the app up POV. YOu need to also think
from the OS down POV.

For instance why does an app need to know the physical number of
the maximum? YOu have the OS give a number if it thinks it needs

These numbers, in the past, were incorrectly used by code that
had no concept of proper memory management; the code included
both applications and OSes.



From: Stephen Fuld on
jmfbahciv(a) wrote:
> In article <MPG.206078dd61655fc398a0f7(a)>,
> krw <krw(a)att.bizzzz> wrote:
>> In article <et647p$8qk_016(a)>,
>> jmfbahciv(a) says...


>>> Why does everybody keep assuming that PDP-10s have to be limited
>>> to 18-bit addressing? Isn't it simply a small matter of wiring
>>> to fetch more than 18bits for effective address calculations?
>> You have to encode those bits into the ISA somehow, hopefully in a
>> way that doesn't muck up every program ever written.
> Which bits? The indirect bit?

No, the bits needed to address memory. I don't know the PDP 10
architecture, but let's look at a generic example. You have some sort
of load instruction to get the value of a data item into a register. So
it looks something like

Load RegisterId, Address_of_Data_Item

Each of these fields (and any other required, such as the indirect bit
you mentioned) must be encoded into the bits of the instruction. The
number of bits used for each field determines the maximum value for that
field. So if the PDP 10 used 18 bits for the address field, then it can
directly address 2**18 (262,144) things (words or bytes, depending on
the architecture) in memory. If you want to address more memory, you
need to somehow get more bits into the address field.

Presumably, you can't easily add a few bits to the length of the basic
instruction, as that would break existing programs. There are several
solutions involving using multiple instructions to build up a longer
address but they have problems too. In general it is a non-trivial
problem to increase addressing (especially in fixed length instruction
ISAs) without really messing things up.

As has been discussed here before, not allowing enough bits for larger
addressability is one of the major mistakes that computer architects make.

- Stephen Fuld
(e-mail address disguised to prevent spam)
From: Eugene Miya on
>>backward compatibility

In article <et8lva$8qk_003(a)>,
<jmfbahciv(a)> wrote:
>The people I worked with were very, very,very, very,very,
>very good at figuring out backwards compatibility. If you
>want to solve those kinds of problems, you get a group
>of people who have had extensive experience doing that kind
>of thing. At DEC they were the TOPS-10 people who worked
>during the 70s, no later. It's not hard to do but does
>require a lot of thinking _first_.

Well, let's see, when did VAX/VM come out? Some time in the latter 80s?
I'm sure the IBM VM/370 people were grinning at the time.

No I am glad that I didn't have to directly deal with that issue.
That's one of the simpler problems of the high end.