rmbult01@ulkyvx.BITNET (10/16/90)
A cursory search of some available computer architecture books and some indexes for information on harvard architectures did not yeild much. Could anyone e-mail me some information on harvard architectures, particularly comparing them with non-harvard, implementation issues, etc. Also, perhaps some machines which use(d) harvard architecture. Any sources or bibliographies would be helpful. Thanks in advance. Robert Bultman Speed Scientific School University of Louisville
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (10/16/90)
In article <9010160322.AA13808@lilac.berkeley.edu> rmbult01@ulkyvx.BITNET writes: >A cursory search of some available computer architecture books >and some indexes for information on harvard architectures did not >yeild much. Could anyone e-mail me some information on harvard >architectures, particularly comparing them with non-harvard, >implementation issues, etc. Also, perhaps some machines which >use(d) harvard architecture. Any sources or bibliographies would >be helpful. Our telephone switches are harvard. The NT-40 processor (propietary design) has two buses going to separate memory banks for program and data. The two sides used the same memory cards, but was addressed in different units - 16 bit for data, 8 bit for program. This was mostly for reliability - the program store is safe from errant processes. Of course, this also doubles the memory bandwidth. There may have been some papers published but I wasn't in the area at the time (lat 70's or early 80's). Incidentally, I have always wondered why this busing arrangement is known as "Harvard". Anyone know? Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!uunet!bnrgate!bcarh185!schow (613) 763-2831 ..!psuvax1!BNR.CA.bitnet!schow Me? Represent other people? Don't make them laugh so hard.
haynes@ucscc.UCSC.EDU (99700000) (10/17/90)
In article <3468@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >Incidentally, I have always wondered why this busing arrangement is >known as "Harvard". Anyone know? Yeah. The "von Neumann" architecture is that in which programs and data are stored in the same memory, and specifically allows the processor to operate on the instruction stream. Self-modifying code was a feature. The computer group at Harvard, under Aiken, had built the Mark I electromechanical computer, and then Mark II and III and IV, some of which were electronic and which followed the philosophy of keeping instructions and data in separate memories. Since those early days various things have clouded the distinction between the two architectures. 1) Even in pure "von Neumann" architectures the idea of self-modifying code has become rather passe' 2) The Burroughs machines from the B6500 on have used tag bits to distinguish instructions from data when both are living in the same memory. So it can't fetch instructions from data words. 3) The PDP11/45 and other large 11s had separate sets of memory mapping registers for code and data (and some architectural difficulties where data might be embedded in the code); so you could put code and data in disjoint areas of memory if you wanted to. 4) A lot of microprocessor systems, particularly embedded micros, have absolutely read-only instruction code, with read-write memory used only for data. Although these are in the same address space the code certainly can't modify itself. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle
cliffc@impala.usa (Cliff Click) (10/17/90)
A lot of Forth chips bring out seperate address and data busses for the control stack, data stack AND main memory - yes, 6 32-bit buses. Makes for a hefty bandwidth. Cliff -- Cliff Click cliffc@rice.edu
nurmi@news.funet.fi.tut.fi (Nurmi Jari) (10/17/90)
From article <CLIFFC.90Oct16142600@impala.usa>, by cliffc@impala.usa (Cliff Click): > > A lot of Forth chips bring out seperate address and data busses And don't forget all the DSP processors from TMS 32010 on... Jari Nurmi # Tampere University of Technology, nurmi@tut.fi (nurmi@tut.UUCP)# Signal Processing Laboratory # PO Box 527, SF-33101 Tampere, Finland all opinions above are mine! # tel: +358 31 162 501 fax: 162 913
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/18/90)
In article <7883@darkstar.ucsc.edu> haynes@ucscc.UCSC.EDU.UUCP (Jim Haynes) writes: | Yeah. The "von Neumann" architecture is that in which programs and data | are stored in the same memory, and specifically allows the processor to | operate on the instruction stream. Self-modifying code was a feature. | The computer group at Harvard, under Aiken, had built the Mark I | electromechanical computer, and then Mark II and III and IV, some of | which were electronic and which followed the philosophy of keeping | instructions and data in separate memories. This has been applied "after the fact" in some cases. The old Z80 CPU has only 64k addressing. One hack done by several people in many ways was to use the "M1" bit (opcode fetch) as a bank selector. This allowed 64k code and 64k data. Alas, the popular o/s was CP/M, and it must have messed with its own code, because it wouldn't run that way. I believe that there was a hack to have data store to memory go both banks and read go one or the other, but it didn't buy much. I had a version with the o/s and BIOS in one bank, user in the other, and 64k of track buffer in a third. Ran really well for the times. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
albaugh@dms.UUCP (Mike Albaugh) (10/18/90)
From article <7883@darkstar.ucsc.edu>, by haynes@ucscc.UCSC.EDU (99700000): [ stuff about the "etymology" of Harvard and "Von Neuman" architectures. As originally defined the opposite of Harvard was Princeton, I believe. Of course, Von Neuman was associated with Princeton (or the Institute for Advanced Studies) by then :-) But that's more along the lines of comp.nostalgia. The following _may_ not be :-) > Since those early days various things have clouded the distinction between > the two architectures. > 1) Even in pure "von Neumann" architectures the idea of self-modifying > code has become rather passe' > 2) The Burroughs machines from the B6500 on have used tag bits to > distinguish instructions from data when both are living in the same > memory. So it can't fetch instructions from data words. I'll treat these two together. The machine described in the "Draft report on Edvac", the basis of the term "Von Neuman machine", was, in a sense, a "tagged" machine. Each memory word was to have a bit, settable _only_ by the program loading device, that identified it as program or data. "Storing" to a word tagged as an instruction modified _only_ the address portion of the word, while "executing" a word tagged as data acted as a "load immediate". So, the potential for "self modifying code" was limited to those operations that are now performed by index registers, later invented (like so many things) at the University of Manchester and patented by IBM :-) Note that the favorite "reasons I need self-modifying code" that surface around here could only be done on such a machine by somehow writing out a modified version of the program to the (not really defined) I/O device and "re-booting" the machine. And an un-related midor nit.: > 4) A lot of microprocessor systems, particularly embedded micros, have > absolutely read-only instruction code, with read-write memory used only > for data. Although these are in the same address space the code > certainly can't modify itself. But it _can_ (and many do) write a modified copy of itself into RAM and execute it, if there is but one address space. The original Von Neuman machine could not "create" instructions (other than "Load Immediate") on the fly. > haynes@ucscc.ucsc.edu > "Any clod can have the facts, but having opinions is an Art." > Charles McCabe, San Francisco Chronicle Bring back the Open Channel (for when I lose my Newsfeed :-) Mike | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!pyramid!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)
mshute@cs.man.ac.uk (Malcolm Shute) (10/18/90)
>In article <3468@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >>Incidentally, I have always wondered why this busing arrangement is >>known as "Harvard". Anyone know? In article <7883@darkstar.ucsc.edu> haynes@ucscc.UCSC.EDU.UUCP (Jim Haynes) writes: >Yeah. The "von Neumann" architecture is that in which programs and data >are stored in the same memory [...] >The computer group at Harvard, under Aiken, [...] followed the philosophy >of keeping instructions and data in separate memories. Why, then, was this not called a "Babbage Architecture"??? Just wondering. -- Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (10/19/90)
In article <2773@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: > This has been applied "after the fact" in some cases. The old Z80 CPU >has only 64k addressing. One hack done by several people in many ways >was to use the "M1" bit (opcode fetch) as a bank selector. This allowed >64k code and 64k data. Alas, the popular o/s was CP/M, and it must have >messed with its own code, because it wouldn't run that way. Oops. That seems to be difficult. The M1 signal is asserted during the opcode fetch only, any memory cycles for immediate data or addresses in the instruction can't be distinguished from other data fetches. You have to decode the opcode byte to guess the size of the instruction. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/19/90)
In article <1320@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: | Oops. That seems to be difficult. The M1 signal is asserted during the | opcode fetch only, any memory cycles for immediate data or addresses | in the instruction can't be distinguished from other data fetches. | You have to decode the opcode byte to guess the size of the instruction. Simple opcodes, only 256 and you could determine the length of the instruction from it (may not be true of Z80, don't know). The part used for the lookup in at least one was a small fast PROM. I don't remember that part number, but it was an odd one, 74xx, sounded like 7400 TTL logic chips, but was really a 50ns (or so) memory, available in 16, 64, or 256 bytes flavors. There, I've shown that I'm an old guy... -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (10/22/90)
In article <2777@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <1320@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >| You have to decode the opcode byte to guess the size of the instruction. > > Simple opcodes, only 256 and you could determine the length of the >instruction from it (may not be true of Z80, don't know). The Z80 has some 'prefix' opcodes. Some of the activated the index registers (which might add a displacement byte to the instruction), and some of them switch to another instruction table. There were combinations of these too. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."