12 Dec
2008
12 Dec
'08
4:26 p.m.
[I tried to send this before, but I don't think it went out. My
apologies if you're seeing this a second time.]
According to my reading, the Burroughs B5000 and Manchester Atlas were
both Harvard architecture machines, and the GE-645 was von Neumann. Am
I correct in my interpretation?
Peace... Sridhar
12 Dec
12 Dec
7:04 p.m.
On 12 Dec 2008 at 11:26, Sridhar Ayengar wrote:
According to my reading, the Burroughs B5000 and
Manchester Atlas were
both Harvard architecture machines, and the GE-645 was von Neumann. Am
I correct in my interpretation?
On the B5000, one certainly couldn't call the architecture strict
Harvard, I think it'd be a real stretch to call it modified Harvard.
While descriptors differentiated between code and data, these could
be altered under program control. I'd call it more of a protection
mechanism on a von Neumann machine, although that's even an
oversimplification.
Cheers,
Chuck
10:41 p.m.
Chuck Guzis wrote:
What was the mechanism for transferring data between the stack and the
program space?
Peace... Sridhar
According to
my reading, the Burroughs B5000 and Manchester Atlas were
both Harvard architecture machines, and the GE-645 was von Neumann. Am
I correct in my interpretation?
On the B5000, one certainly couldn't call the architecture strict
Harvard, I think it'd be a real stretch to call it modified Harvard.
While descriptors differentiated between code and data, these could
be altered under program control. I'd call it more of a protection
mechanism on a von Neumann machine, although that's even an
oversimplification.
11:22 p.m.
On 12 Dec 2008 at 17:41, Sridhar Ayengar wrote:
What was the mechanism for transferring data between
the stack and the
program space?
As far as I can remember, there was no prohibition on two entries in
the PRT describing the same physical address space--one as program,
the other as data. That would seem to kill the Harvard Architecture
idea, no?
Cheers,
Chuck
11:41 p.m.
Chuck Guzis wrote:
But, the data could only be operated on from the stack, right? So, if
you wanted to write a self-modifying program, wouldn't you need to have
two entries in the PRT, similarly to what you've suggested, and then
wouldn't you also need to push the elements of the array containing the
program data onto the stack, operate on them, then pop them off the
stack and back into the array space, thereby allowing the code to run?
Or am I missing something?
Peace... Sridhar
What was the
mechanism for transferring data between the stack and the
program space?
As far as I can remember, there was no prohibition on two entries in
the PRT describing the same physical address space--one as program,
the other as data. That would seem to kill the Harvard Architecture
idea, no?
13 Dec
13 Dec
12:08 a.m.
On 12 Dec 2008 at 18:41, Sridhar Ayengar wrote:
But, the data could only be operated on from the
stack, right? So, if
you wanted to write a self-modifying program, wouldn't you need to have
two entries in the PRT, similarly to what you've suggested, and then
wouldn't you also need to push the elements of the array containing the
program data onto the stack, operate on them, then pop them off the
stack and back into the array space, thereby allowing the code to run?
Or am I missing something?
I think we're saying the same thing. In other words, code
modification was certainly possible.
Cheers,
Chuck
12:13 a.m.
Chuck Guzis wrote:
On 12 Dec 2008 at 18:41, Sridhar Ayengar wrote:
But they threw up roadblocks to try to prevent it, right? It sure looks
like the array storage out-of-stack seemed to have been tacked onto the
architecture as an afterthought.
Peace... Sridhar
But, the data could only be operated on from the
stack, right? So, if
you wanted to write a self-modifying program, wouldn't you need to have
two entries in the PRT, similarly to what you've suggested, and then
wouldn't you also need to push the elements of the array containing the
program data onto the stack, operate on them, then pop them off the
stack and back into the array space, thereby allowing the code to run?
Or am I missing something?
I think we're saying the same thing. In other words, code
modification was certainly possible.
12:32 a.m.
On 12 Dec 2008 at 19:13, Sridhar Ayengar wrote:
But they threw up roadblocks to try to prevent it,
right? It sure looks
like the array storage out-of-stack seemed to have been tacked onto the
architecture as an afterthought.
I don't know about the history of the various features, but any
general-purpose computer has to have some way to generate and execute
code to be very useful, no?
Even the (specialized) upper PIC and AVR people figured that one out
eventually.
Cheers,
Chuck
12 Dec
12 Dec
11:32 p.m.
On Fri, Dec 12, 2008 at 11:04:12AM -0800, Chuck Guzis wrote:
On 12 Dec 2008 at 11:26, Sridhar Ayengar wrote:
Similar to I/D on the PDP-11 then?
- Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
According to my reading, the Burroughs B5000 and
Manchester Atlas were
both Harvard architecture machines, and the GE-645 was von Neumann. Am
I correct in my interpretation?
On the B5000, one certainly couldn't call the architecture strict
Harvard, I think it'd be a real stretch to call it modified Harvard.
While descriptors differentiated between code and data, these could
be altered under program control. I'd call it more of a protection
mechanism on a von Neumann machine, although that's even an
oversimplification. 
7:18 p.m.
>Sridhar Ayengar
According to my reading, the
Burroughs B5000 and Manchester Atlas were
both Harvard architecture machines, and the GE-645 was von Neumann. Am
I correct in my interpretation?
<<
Technically none of them can be pure Harvard architecture because the
operating system can write to memory (to load the program) and then start
executing instructions from the same memory.
When the 645 was running Multics (ie its normal status) then, like the other
two, the user programming model had execute (+ read) -only code segments and
thus would have the Harvard principle of non-self-modifying code.
However, the hardware of both the Atlas and the 645 could, in theory, run
with a user-writeable code segment ...
I think that the B5000 would need tags explicitly to be switched to do such
tricks.
Andy
14 Dec
14 Dec
7:15 p.m.
On 12 Dec 2008 at 19:18, Andy Holt wrote:
Technically none of them can be pure Harvard
architecture because the
operating system can write to memory (to load the program) and then start
executing instructions from the same memory.
We agree on that one, even "pure" Harvard isn't what it used to mean.
Pure Harvard architecture used to mean separate stores (and, by
extension, datapaths) for instructions and data. Lower PICs probably
qualify, as the data and program areas are very separate (and not
even of the same word length).
But it's a bit of a stretch to say that a machine with a defeatable
protection scheme is "Harvard" in any sense of the word. By that
logic, an 80286 running in protected mode is a Harvard machine. By
that token upper PICs with software-writable program memory are not
Harvard, even though the data books say the contrary.
Things get more complicated even on the "pure" architectures if off-
line storage (e.g. tape, cards, quipu, guru beads) can be written by
a program and read into either data or program (i.e. executed) space.
Is a machine with separate code and data spaces still considered to
be "Harvard" if the instruction set includes an "execute" instruction
that permits modification of the target instruction operand
specification? (e.g. the S/360 EX instruction).
It's not a simple distinction.
Cheers,
Chuck
15 Dec
15 Dec
5:10 p.m.
>>>> "Sridhar" == Sridhar Ayengar
<ploopster at gmail.com> writes:
Sridhar> [I tried to send this before, but I don't think it went out.
Sridhar> My apologies if you're seeing this a second time.]
Sridhar> According to my reading, the Burroughs B5000 and Manchester
Sridhar> Atlas were both Harvard architecture machines, and the
Sridhar> GE-645 was von Neumann. Am I correct in my interpretation?
I don't know the GE, but the Burroughs mainframes are v.N. Perhaps
you got that interpretation because code is distinguished from data.
But that's not by memory space; code (and for that matter other
non-data things like pointers) is identified by "tag" bits which
are stored in memory along with the data bits of each word. For
example, data has tag 0, while executable code has tag 7. That gives
you some protection. (Indeed, that's about all the protection you
get; OS security in Burroughs mainframe systems did not come from the
hardware, but rather from the fact that creating code files was a
privileged operation, and only compilers were privileged to do that,
and the ESPOL compiler was protected so Joe User couldn't use it.)
You can find more on Bitsavers; there are a bunch of B6700 manuals
there including the system reference manual.
paul
6:14 p.m.
On 15 Dec 2008 at 12:10, Paul Koning wrote:
You can find more on Bitsavers; there are a bunch of
B6700 manuals
there including the system reference manual.
Bitsavers has a couple of B5000 manuals, which may prove to be
useful.
The B5000 could hardly have been Harvard, when one considers the
fucntions of the MCP, which had free access to all areas of core,
including satisfying all "not in core" references.
Cheers,
Chuck
6:37 p.m.
>>>> "Chuck" == Chuck Guzis
<cclist at sydex.com> writes:
Chuck> On 15 Dec 2008 at 12:10, Paul Koning wrote:
> You can find more on Bitsavers; there are a bunch
of B6700 manuals
> there including the system reference manual.
Chuck> Bitsavers has a couple of B5000 manuals, which may prove to be
Chuck> useful.
Right. I was quoting from my memory of the 6700 and the manuals I had
for that machine, on the basis that it's a successor to the 5000
series with the same general architecture.
paul
5859
days inactive
5862
days old
13 comments
5 participants
participants (5)
-
andyh＠andyh-rayleigh.freeserve.co.uk -
cclist＠sydex.com -
db＠db.net -
Paul_Koning＠Dell.com -
ploopster＠gmail.com