> From: Johnny Billquist <bqt at softjar.se>
> On 10/26/10 04:20, Roger Holmes <roger.holmes at microspot.co.uk> wrote:
>
>>>> From: Mr Ian Primus<ian_primus at yahoo.com>
>>>> And glaringly so. To say that the 11/780 is the first 32 bit machine is just silly. Prime had a 32 bit machine in 1972. And I know that there were others - but the Prime is the machine that I know the best:)
>> I think I'm right saying the Manchester 'Baby' had a 32 bit word in 1948, actually 32 of them on one Williams tube. However as it was a serial machine the data path to memory was actually one bit wide so it depends how you define bit size, but I was taught it was the largest addressable unit of memory and by that definition it had a 32 bit word.
>
> What does "largest addressable unit of memory" means? I totally fail to
> understand that. Sounds like "the largest memory chip that can be
> utilized", but that can hardly be the meaning.
Compare with another thing I was taught. A byte is the smallest addressable unit of memory. By this definition I have worked on machines with bytes sizes of 3, 8, 18, 24, 36 and (I think) 60. In most of the latter ones, a byte was also a word. I guess you exclude memory to memory block move instructions, then consider the instructions which can load and save data and find the one which acts on the largest number of bits. I think by this definition a 68000, a Z8000, and the Manchester Baby all had 32 bit words. The VAX may have had 32 bit of 64 bit words even if it had just a 32 bit data path. My ICT 1301 has 48 bits words and 48 bit bytes even though its mill was only 4 bits wide. The data path from core memory to the 'A' register was 50 bits in parallel (it had two parity bits), but the data path between registers was only 4 bits, or in one case two sets of 4 bits. It was a serial/parallel architecture which allowed the end user price to be kept just below 250,000 pounds for a 5 tape deck mag tape machine with card reader, card punch, line printer, one drum and 2000 (decimal) words of core.
Sorry for rambling and thanks for all who commented on my 41 years of programming experience.
>
>> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
>
> That the PDP-11 influenced the VAX there can be no doubt about.
> The the PDP-11 influenced the 68K seems very probable when looking at
> the architectures, but that is guessing on our part.
>
> William Donzelli<wdonzelli at gmail.com> write:
>>>> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
>> Big microcoded CISC was the dominant thinking in computer architecture
>> at the time, so it is really hard to say that X influenced Y.
>
> Well, the fact that DEC explicitly stated that the VAX would be like the
> PDP-11, but extended to 32 bits seems like an obvious statement that the
> PDP-11 influenced the VAX. Not to mention the fact that they used the
> same peripherial buses, and at VMS V1, most of the applications were
> just the RSX programs moved straight over. Oh, and don't forget the
> compatibility mode in the VAX, which made it execute PDP-11 code. :-)
>
> As for the 68K, we are making more of a guess, but it seems like a
> fairly educated guess that the 68K was inspired by the PDP-11 (although
Agreed.
> I'd say the 68K is way inferior to the PDP-11...)
If you say so, I never used a PDP-11.
>
> Johnny
On 10/25/10 16:53, William Donzelli <wdonzelli at gmail.com> wrote:
>> > Also, the sentence starting "The VAX instruction set well revered would later on influence" needs restructured. The paragraph after the bullet points has more of the same error.
> You could say that the designers of the 68000 were influenced by the
> PDP-11, but I do not think you could say the same thing about the VAX.
> When the 68000 design was started, the VAX was still well under wraps.
> I can see no reason why DEC would have let the Motorola guys see the
> developing architecture.
>
> Anyway, in the mid/late 1970s, heavily microcoded very CISCy
> architectures were pretty much the design route of choice. It was
> everywhere. It is very difficult to pin down influences.
The PDP-11 was in architectural ways more important than the VAX, if
nothing else than just because the VAX was basically just extending the
PDP-11.
However, I also object to the discussion about "Virtual memory" as
something new the VAX brought to the table.
Virtual memory worked just fine on a PDP-11 as well, thank you very
much, as it also worked fine on a bunch of other machines, and had been
doing for quite a while.
VAX stands for "Virtual Address eXtension", note the "extension".
Extension normally means that you modify/extend something that already
exists, in this case the virtual address. On a PDP-11, the virtual
address is 16 bits, the VAX extended it to 32 bits, which is a huge
improvement (and the biggest bottleneck of the PDP-11, as I'm sure all
people know). The physical address on a PDP-11 is 22 bits, while the
physical address on a VAX varies, but on the 11/780 I only think it was
something like 24 bits.
The VAX also introduced demand pageing, compared to the PDP-11, where
you normally didn't do that (and not all models could even possibly do
it), but demand pageing as such wasn't new either. DEC was already doing
it with the PDP-10 running TOPS-20 (and other companies had also done it).
Johnny
I have stacks of duplicate BYTE magazines.
Would it be a sin to have them cut-up to be scanned, page-by-page?
Nothing from the 70's, I would do 80's era only.
Has anyone ever done this?
They wouldn't be posted online, it would be for personal research only.
I would certainly share the info with others if requested.
On 10/26/10 04:20, Roger Holmes <roger.holmes at microspot.co.uk> wrote:
>> > From: Mr Ian Primus<ian_primus at yahoo.com>
>> > And glaringly so. To say that the 11/780 is the first 32 bit machine is just silly. Prime had a 32 bit machine in 1972. And I know that there were others - but the Prime is the machine that I know the best:)
> I think I'm right saying the Manchester 'Baby' had a 32 bit word in 1948, actually 32 of them on one Williams tube. However as it was a serial machine the data path to memory was actually one bit wide so it depends how you define bit size, but I was taught it was the largest addressable unit of memory and by that definition it had a 32 bit word.
What does "largest addressable unit of memory" means? I totally fail to
understand that. Sounds like "the largest memory chip that can be
utilized", but that can hardly be the meaning.
> There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
That the PDP-11 influenced the VAX there can be no doubt about.
The the PDP-11 influenced the 68K seems very probable when looking at
the architectures, but that is guessing on our part.
William Donzelli<wdonzelli at gmail.com> write:
>> > There was talk of the VAX design being the inspiration for the Motorola 68k. Isn't it more likely that the PDP11 influenced the design of both the VAX and the 68k?
> Big microcoded CISC was the dominant thinking in computer architecture
> at the time, so it is really hard to say that X influenced Y.
Well, the fact that DEC explicitly stated that the VAX would be like the
PDP-11, but extended to 32 bits seems like an obvious statement that the
PDP-11 influenced the VAX. Not to mention the fact that they used the
same peripherial buses, and at VMS V1, most of the applications were
just the RSX programs moved straight over. Oh, and don't forget the
compatibility mode in the VAX, which made it execute PDP-11 code. :-)
As for the 68K, we are making more of a guess, but it seems like a
fairly educated guess that the 68K was inspired by the PDP-11 (although
I'd say the 68K is way inferior to the PDP-11...)
Johnny
Hello everyone,
I would like to announce a new podcast series that I have started, and I feel really good about it's potential.
When you can, please consider giving a listen to the Retro Computing Roundtable -
http://web.me.com/dgreelish/Classic_Computing_Podcasts/RCR/RCR.html
I am currently working on its submission to iTunes. This show has Bill Degnan from M.A.R.C.H. & VCFe, Earl Evans from "The Retrobits Podcast" and Carrington Vanston from the "1MHz: The Apple ][ Podcast."
The next show is scheduled in three weeks!
Best,
David Greelish, Computer Historian
Classic Computing
The Home of Computer History Nostalgia
http://www.classiccomputing.com
Classic Computing Blog
Classic Computing Show video podcast
"Stan Veit's History of the Personal Computer" audiobook podcast
Retro Computing Roundtable podcast
Historical Computer Society meeting - first Wednesday of each month.
Classic Computing Expo 1.0 - planned for March 2011!
> From: "Tom Gardner" <thomas.gardner at sbcglobal.net>
>
> On Fri, 22 Oct 2010 11:03:10 +0200 (CEST) Christian Corti wrote:
>
>
>
>> Per definition, a magnetic drum is not random access.
>
>> A random access storage is defined by the fact that addressing
>
>> any arbitrary cell needs the same time.
>
>
> That may be today's definition but if you check the literature of the 50's
> and 60's I am sure u will find drums (along with Williams Tubes, etc)
> categorized as random access devices. Even the first disk drive was the IBM
> RAMAC 350 - as in Random Access Memory! I think IBM invented the term
> Direct Access Storage in the 1960s to distinguish devices whose assess time
> was short but variable; that is, in between core (random) and tape
> (sequential).
>
>
>
> So the historical definition may have been . needs essentially the same
> time.
>
In my ICT 1301 manuals it always uses the term Immediate Access Store (IAS) for the core store, in fact I don't think the word core is used except in the engineers maintenance manuals. My machine also has three drums for storing overlays and data as well as mag tape. The drums also have reserved bands (only writable with an engineers assistance) which hold Initial Orders, the machine's bootstrap, along with three half words which are directly wired into the machine which on pressing a button are forced into the three control registers which then load Initial Orders from drum.
P.S. I expect it was an oversight but please don't include the whole digest in your messages.
I have a low-level pdp-11 question...
I'm confused about writing to the PSW on cpu's which support user &
supervisor mode. My
read of the docs is that in user mode you should not be able to write
the "mode" bits of the PSW.
(or, perhaps more accurately, you should not be able to *clear* any mode
bits from user space)
I have a little diagnostic which doesn't work as I though it should
under simh and I thought I'd
ask what others think...
Basically, simh allows code running in "user mode" to write the PSW even
when (I claim) it
should not. I have not tried this on a real 11/44 or 11/34 yet, but I
can/will.
Should simh allow this? In the test blow the "clr @#PSW" is successful
when run
on simh and I think it should basically be a nop...
(which begs another question - should it be a nop? or a exception?)
A side question might be "the psw is not protected from writes, except
by using
the mmu" - is this true on all models? or just some? The 11/40 manual
implies
that it *is* protected. But 11/73 docs seem to say the opposite and
imply using the mmu.
diagnostic follows:
.TITLE test17
.ASECT
PSW=177776 ;processor status word
.=34
.word 200
.word 0007
.=200
mov #200, r5 ;we should be in kernel mode here
rti
.=500
clr @#PSW ;kernel mode
mov #500,sp ;sp=500 in kernel mode
mov #140000,@#PSW ;user mode
mov #700,sp ;sp=700 in user mode
trap 377 ;should move us to kernel mode
nop
clr @#PSW ;back to kernel mode
nop
halt
I'm writing a little program in H316 assembler, running it in simh
(3.8-1). The usual idiom for returning from a subroutine seems to be an
indirect jump through a pointer. But my indirect jump halts at the
location where the pointer is stored.
The code looks something like this:
...
>from jst subr call the subroutine
...
subr dac **
... do some stuff
jmp* subr
The jst is supposed to drop the address of from+1 into location subr,
and execution continues at subr+1.
The indirect jmp (jmp*) should be the return, getting the target address
>from location subr. There are even examples in some of the H316 docs
showing this kind of thing.
Best I can tell, the assembled code has all the correct bits set -- the
indirect bit is the high order bit in the word, and is set, opcode looks
correct, etc. The correct target address is indeed stored at subr by
the jst.
Obviously this isn't re-entrant, etc. Don't care about that at this
point.
What am I doing wrong?
Thanks,
De
On 10/25/10 00:46, Brad Parker <brad at heeltoe.com> wrote:
> I have a low-level pdp-11 question...
>
> I'm confused about writing to the PSW on cpu's which support user&
> supervisor mode. My
> read of the docs is that in user mode you should not be able to write
> the "mode" bits of the PSW.
>
> (or, perhaps more accurately, you should not be able to*clear* any mode
> bits from user space)
>
> I have a little diagnostic which doesn't work as I though it should
> under simh and I thought I'd
> ask what others think...
>
> Basically, simh allows code running in "user mode" to write the PSW even
> when (I claim) it
> should not. I have not tried this on a real 11/44 or 11/34 yet, but I
> can/will.
>
> Should simh allow this? In the test blow the "clr @#PSW" is successful
> when run
> on simh and I think it should basically be a nop...
>
> (which begs another question - should it be a nop? or a exception?)
>
> A side question might be "the psw is not protected from writes, except
> by using
> the mmu" - is this true on all models? or just some? The 11/40 manual
> implies
> that it*is* protected. But 11/73 docs seem to say the opposite and
> imply using the mmu.
>
> diagnostic follows:
>
> .TITLE test17
> .ASECT
> PSW=177776 ;processor status word
> .=34
> .word 200
> .word 0007
> .=200
> mov #200, r5 ;we should be in kernel mode here
> rti
> .=500
> clr @#PSW ;kernel mode
> mov #500,sp ;sp=500 in kernel mode
> mov #140000,@#PSW ;user mode
> mov #700,sp ;sp=700 in user mode
> trap 377 ;should move us to kernel mode
> nop
> clr @#PSW ;back to kernel mode
> nop
> halt
>
>
The PSW, when regarded as a memory location, is not protected at all.
How could it be?
The PSW is protected, when we talk about the MFPS/MTPS instructions, as
well as the RETI/RETN.
For an operating system, you normally protect the whole I/O page from
user access, since not only the PSW is in there, but all kind of stuff
that you do not want user programs to get access to.
Data in the I/O page follows the same rules as any other memory
essentially. If you have write access to it, you can write to those
locations. The underlying device responding to those writes have no idea
what the PSW is, and cannot enforce any protection. The special case of
the PSW itself is perhaps "odd" since it actually do know what the PSW
is (obviously) but it still follows the same rules as all other devices.
Johnny