Wilco Dijkstra wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message 
> news:45ed941f$0$24599$8404b019@news.wineasy.se...
> 
>> We are using a significantly different definition of "Harvard" and "von 
>> Neumann".  With your definition, i.e., that it depends entirely on whether 
>> the core has a single memory bus (von Neumann) or separate code and data 
>> buses (Harvard), then what you wrote above is correct.
>>
>> With the definition that I use, and many others here agree on, it is a 
>> different matter.  That is to say, the differentiator is whether the core 
>> uses a single address space for data and code, or whether it uses two 
>> separate spaces.
> 
> No that differentiates between the 2 types of Harvard, not between
> Harvard and Von Neumann. You can have a CPU with a shared code
> and data bus which uses separate memory spaces for code and data.
> Is it Von Neumann or Harvard or both?
> 
> There are two types of Harvard: pure and modified.
> 
> A pure Harvard uses separate code and data memories and separate
> code and data spaces. The memories can be different sizes. In its purest
> form there is no connection at all between the code and data memories,
> but there are typically ways to read/write program memory.
> 
> A modified Harvard uses separate code and data memories but has
> a single address space. A common layout is separate instruction and
> data caches which are fed by a unified main memory. DSPs often allow
> data accesses to code memory to get 2 data accesses per cycle in loops.
> 
>> Historically, the definitions overlapped (as indicated by wikipedia). With 
>> modern designs, it's a different matter - most cpus have a single address 
>> space but may have more than one bus, while some small processors (or 
>> other more specialised cores) have separate address spaces.
> 
> Yes. I think it's a shame the definitions (H&P, wikipedia) don't clearly
> separate the two variants. Most people mean modified Harvard when
> they say Harvard (ARM calls its cores Harvard, and even the 68030 is
> called Harvard by Freescale, etc). But that's the way it is...
> 

It looks like "Harvard" and "von Neumann" are another set of terms that 
must be consigned to the dustbin of inconsistency.  You call the 68030 
"modified Harvard", Freescale calls it "Harvard", while programmers like 
myself would call it "von Neumann".  As you say, that's the way it is.



> Wilco 
> 
> 

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:45ed941f$0$24599$8404b019@news.wineasy.se...

> We are using a significantly different definition of "Harvard" and "von 
> Neumann".  With your definition, i.e., that it depends entirely on whether 
> the core has a single memory bus (von Neumann) or separate code and data 
> buses (Harvard), then what you wrote above is correct.
>
> With the definition that I use, and many others here agree on, it is a 
> different matter.  That is to say, the differentiator is whether the core 
> uses a single address space for data and code, or whether it uses two 
> separate spaces.

No that differentiates between the 2 types of Harvard, not between
Harvard and Von Neumann. You can have a CPU with a shared code
and data bus which uses separate memory spaces for code and data.
Is it Von Neumann or Harvard or both?

There are two types of Harvard: pure and modified.

A pure Harvard uses separate code and data memories and separate
code and data spaces. The memories can be different sizes. In its purest
form there is no connection at all between the code and data memories,
but there are typically ways to read/write program memory.

A modified Harvard uses separate code and data memories but has
a single address space. A common layout is separate instruction and
data caches which are fed by a unified main memory. DSPs often allow
data accesses to code memory to get 2 data accesses per cycle in loops.

> Historically, the definitions overlapped (as indicated by wikipedia). With 
> modern designs, it's a different matter - most cpus have a single address 
> space but may have more than one bus, while some small processors (or 
> other more specialised cores) have separate address spaces.

Yes. I think it's a shame the definitions (H&P, wikipedia) don't clearly
separate the two variants. Most people mean modified Harvard when
they say Harvard (ARM calls its cores Harvard, and even the 68030 is
called Harvard by Freescale, etc). But that's the way it is...

Wilco 

"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes:

> My point was that a separate memory space is not an indication of a
> Harvard, two or more memory buses for code and data is. Harvards may
> also have separate memory spaces, but this is not popular anymore.

> Harvard is used for most architectures today.

How do you quantify "most"?  Number of processor families?
Number of processor variants?  Number actually made?  Are
the numbers different for 4-bit, 8-bit,..., 64+ bit processors?

> Few pure Harvards exist indeed
> nowadays, the vast majority uses a unified address space.

Wilco Dijkstra wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message 
> news:45ed2274$0$24598$8404b019@news.wineasy.se...
>> Grant Edwards wrote:
>>> On 2007-03-04, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
>>>
>>>> Have you a refernce for that definition?  All the definitions I've found 
>>>> refer to separate addres spaces for code and data as being the key 
>>>> distinction for a Harvard architecture.
> 
> See Hennessy&Patterson Computer Architecture - A Quantitative Approach.
> Or wikipedia (although their definition is a bit vague).
> 
>> The number of ports for accessing the data spaces does not change a von 
>> Neumann architecture into a Harvard one, or vice versa.  Historically, 
>> there was a match in the number of ports, since Harvard architectures have 
>> separate code and data spaces and have two ports, and v.N. architectures 
>> have a single address space and need only one port - multiple ports to the 
>> same address space were difficult and expensive in times past.
> 
> Harvard was revived by RISC and the key goal was performance by
> using 2 ports to access code and data simultaneously. Some RISCs
> used traditional pure Harvard (eg. Sparc) but most used a unified
> memory architecture with separate data caches.
> 
>> The great majority of modern processors have a unified address space, 
>> i.e., they are von Neumann.
> 
> Correct. They use a Harvard architecture with Von Neumann unified
> memory, so are neither pure Harvard nor pure Von Neumann.
> 
>> They might have a separate IO space, but that does not make them Harvard 
>> any more than a "core register space" does.
> 
> My point was that a separate memory space is not an indication of a
> Harvard, two or more memory buses for code and data is. Harvards may
> also have separate memory spaces, but this is not popular anymore.
> 
>> They are likely to have more than one bus internally - that's 
>> implementation optimisation.  Since cache memories became common, the speed 
>> advantages of Harvard designs (with their dual buses) disappeared,
> 
> Cached cores are typically Harvard...
> 
>> and Harvard is now only used for small micros (which have no cache, but 
>> may have distinct requirements for flash and ram areas) or specialised 
>> architectures.
> 
> Harvard is used for most architectures today. Few pure Harvards exist indeed
> nowadays, the vast majority uses a unified address space.
> 
> Wilco 
> 
> 

We are using a significantly different definition of "Harvard" and "von 
Neumann".  With your definition, i.e., that it depends entirely on 
whether the core has a single memory bus (von Neumann) or separate code 
and data buses (Harvard), then what you wrote above is correct.

With the definition that I use, and many others here agree on, it is a 
different matter.  That is to say, the differentiator is whether the 
core uses a single address space for data and code, or whether it uses 
two separate spaces.

Historically, the definitions overlapped (as indicated by wikipedia). 
With modern designs, it's a different matter - most cpus have a single 
address space but may have more than one bus, while some small 
processors (or other more specialised cores) have separate address spaces.

The number of internal buses is, of course, totally irrelevant except 
for performance reasons, and is therefore a useless way to distinguish 
between architectures.  The number of address spaces, on the other hand, 
is highly visible to the programmer, and often makes the difference 
between a C-friendly architecture and an unfriendly one.

"Paul Keinanen" <keinanen@sci.fi> wrote in message 
news:o4dqu297t1c8ppapk6qdeh74e20l4e9cb9@4ax.com...
> On Tue, 06 Mar 2007 08:20:16 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>>> The issue about higher level languages is more the question if the
>>> architecture includes a call stack at all and were it is located
>>> (internal registers/data space RAM) and if it is accessible from the
>>> data space.
>>
>>You don't need to access the call stack in C, it is perfectly possible
>>to use separate stacks for data and return addresses. If the hardware
>>doesn't allow any access to the call stack the only issue is setjmp/
>>longjmp, but they are not that useful anyway.
>
> If you want to pass function pointers as arguments to a subroutine and
> later execute the routine, you need some method to load the program
> counter. One way is to put the address in the return address stack and
> issue a return instruction.

Yes, if you don't have an indirect branch then that would be the only option
(switch statements become a nightmare). If you do have an indirect branch
then calling a helper function that does the branch is an alternative.

Wilco 

On Tue, 06 Mar 2007 08:20:16 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>> The issue about higher level languages is more the question if the
>> architecture includes a call stack at all and were it is located
>> (internal registers/data space RAM) and if it is accessible from the
>> data space.
>
>You don't need to access the call stack in C, it is perfectly possible
>to use separate stacks for data and return addresses. If the hardware
>doesn't allow any access to the call stack the only issue is setjmp/
>longjmp, but they are not that useful anyway.

If you want to pass function pointers as arguments to a subroutine and
later execute the routine, you need some method to load the program
counter. One way is to put the address in the return address stack and
issue a return instruction.

Paul

"Grant Edwards" <grante@visi.com> wrote in message 
news:12ukjp9b6dr1u3b@corp.supernews.com...
> On 2007-03-03, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>>>> The classic Harvard architecture has separate instruction and
>>>> data buses accessing different memories
>>>
>>> So you're saying it has nothing to do with the number of
>>> address spaces?
>>
>> Indeed. The original goal was to allow simultaneous access to
>> both code and data memories. How they fit in the memory map is
>> a different matter. The early pure Harvards didn't allow data
>> access to instruction memory at all, but few (if any) of these
>> exist today.
>
> The "Harvard Architecture" I learned about in grad school meant
> separate address spaces for code and data.  You claim it merely
> means multiple physical memory busses -- so a processor with 3
> busses is "Harvard" even though there's only one address space
> and code/data can be fetched from any bus?

No, I'd call it Harvard when there are separate, dedicated instruction
and data memories which can be accessed simultaneously via
dedicated buses. There may be more buses to connect the memories
(eg. to a unified main memory) but that doesn't stop it being a Harvard.

Wilco 

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:45ed2274$0$24598$8404b019@news.wineasy.se...
> Grant Edwards wrote:
>> On 2007-03-04, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
>>
>>> Have you a refernce for that definition?  All the definitions I've found 
>>> refer to separate addres spaces for code and data as being the key 
>>> distinction for a Harvard architecture.

See Hennessy&Patterson Computer Architecture - A Quantitative Approach.
Or wikipedia (although their definition is a bit vague).

> The number of ports for accessing the data spaces does not change a von 
> Neumann architecture into a Harvard one, or vice versa.  Historically, 
> there was a match in the number of ports, since Harvard architectures have 
> separate code and data spaces and have two ports, and v.N. architectures 
> have a single address space and need only one port - multiple ports to the 
> same address space were difficult and expensive in times past.

Harvard was revived by RISC and the key goal was performance by
using 2 ports to access code and data simultaneously. Some RISCs
used traditional pure Harvard (eg. Sparc) but most used a unified
memory architecture with separate data caches.

> The great majority of modern processors have a unified address space, 
> i.e., they are von Neumann.

Correct. They use a Harvard architecture with Von Neumann unified
memory, so are neither pure Harvard nor pure Von Neumann.

>They might have a separate IO space, but that does not make them Harvard 
>any more than a "core register space" does.

My point was that a separate memory space is not an indication of a
Harvard, two or more memory buses for code and data is. Harvards may
also have separate memory spaces, but this is not popular anymore.

>They are likely to have more than one bus internally - that's 
>implementation optimisation.  Since cache memories became common, the speed 
>advantages of Harvard designs (with their dual buses) disappeared,

Cached cores are typically Harvard...

> and Harvard is now only used for small micros (which have no cache, but 
> may have distinct requirements for flash and ram areas) or specialised 
> architectures.

Harvard is used for most architectures today. Few pure Harvards exist indeed
nowadays, the vast majority uses a unified address space.

Wilco 

Grant Edwards wrote:
> On 2007-03-04, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
> 
>> Have you a refernce for that definition?  All the definitions I've found 
>> refer to separate addres spaces for code and data as being the key 
>> distinction for a Harvard architecture.
> 
> That's the definition in all the books and articles I've ever
> seen.
> 

I agree with that.

The number of ports for accessing the data spaces does not change a von 
Neumann architecture into a Harvard one, or vice versa.  Historically, 
there was a match in the number of ports, since Harvard architectures 
have separate code and data spaces and have two ports, and v.N. 
architectures have a single address space and need only one port - 
multiple ports to the same address space were difficult and expensive in 
times past.

The great majority of modern processors have a unified address space, 
i.e., they are von Neumann.  They might have a separate IO space, but 
that does not make them Harvard any more than a "core register space" 
does.  They are likely to have more than one bus internally - that's 
implementation optimisation.  Since cache memories became common, the 
speed advantages of Harvard designs (with their dual buses) disappeared, 
and Harvard is now only used for small micros (which have no cache, but 
may have distinct requirements for flash and ram areas) or specialised 
architectures.

>> None refer to simply having multiple data paths to the same
>> address space that way much less refer to multiported ram as
>> Harvard (as ST does). 
> 

"Paul Keinanen" <keinanen@sci.fi> wrote in message 
news:kquku2tajt013lv7nitj84ght90mnckdca@4ax.com...
> On Sat, 03 Mar 2007 23:13:03 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>>
>>"Grant Edwards" <grante@visi.com> wrote in message
>>news:12ujjmesqcijscb@corp.supernews.com...
>>> On 2007-03-03, Everett M. Greene <mojaveg@mojaveg.lsan.mdsg-pacwest.com>
>>> wrote:
>>>> Grant Edwards <grante@visi.com> writes:
>>>>> On 2007-03-03, Robert Adsett <sub2@aeolusdevelopment.com> wrote:

>>>> The classic Harvard architecture has separate instruction and
>>>> data buses accessing different memories
>
> At least architectures with different instruction word and data word
> length must be harvard architecture. It would be hard to efficiently
> put e.g. 14 bit instruction words and 8 data words in the same address
> space or even into a unified memory array.

They would likely be Harvard indeed. They could have a unified
address space, for example it would be possible to allow 8-bit and
16-bit reads to a 14-bit instruction memory.

> Any other systems with equal addressability granulation in both spaces
> but with different logical or physical (memory banks) address spaces
> would be on the borderline (harvard or not).

If there are different memory banks and buses to them, then it is a
Harvard. If there is one bus to multiple memories then it is not.

>>> So you're saying it has nothing to do with the number of
>>> address spaces?
>>
>>Indeed. The original goal was to allow simultaneous access to
>>both code and data memories. How they fit in the memory map
>>is a different matter. The early pure Harvards didn't allow data
>>access to instruction memory at all, but few (if any) of these exist
>>today.
>
> Why would instruction space data access be required in the early
> systems (except for self modifying code, which became more or less
> redundant after addition of index registers) ?

You need access to instuction memory to program it. The early
machines were programmed by hand...

> Moving data from instruction space to data space has become an issue
> with non-volatile data memory and especially in micro controllers, in
> which you do not have a program/data loader. The obvious solution
> would be to have a data-space initial image in a non-volatile memory
> with same word length as the data space. However, this would not be
> cost effective, since only a small part of data-memory needs to be
> initialised with non-zero values, so a program loader reading with
> some special instructions from instruction space would be required.
> But after the initial data space loading, there should not be much
> need to access the instruction space.

That's not true. A significant proportion of data is const data, and
there is often very little RAM on micro controllers, so copying it from
flash to RAM is simply not an option. Therefore efficient access to
flash is required and flash and SRAM need to share the same
address space. The good thing is that you can still use a Harvard
architecture.

>>Having 2 or more address spaces doesn't make a CPU a
>>Harvard. Many CISCs have a separate IO space for example.
>>
>>> Something like a TMS320C4x with a single address space but 3
>>> different physical memory busses is a harvard archicture?
>>
>>Yes. Most Harvards have a single address space.
>
> That would be quite stupid when one think about bit efficiency. If the
> I space is 16 bit wide with word addressing and D-space is 8 bits wide
> with byte addressing, 16 bit pointers could access 64 KiW (128 KiB)
> I-space and 64 KiB of D-space without any special tricks, such as
> segment registers. The need for data access from I-space, so this does
> not affect the overall efficiency.

Yes, that is why only a few small 8/16 bitters go for a pure Harvard
architecture - being able to use twice as much memory matters.
But for high level languages a unified memory is the way to go.


>>Without that
>>you'd need special instructions to access the different address
>>spaces (eg. LPM on AVR, MOVC on 8051). Not good for C...
>
> The issue about higher level languages is more the question if the
> architecture includes a call stack at all and were it is located
> (internal registers/data space RAM) and if it is accessible from the
> data space.

You don't need to access the call stack in C, it is perfectly possible
to use separate stacks for data and return addresses. If the hardware
doesn't allow any access to the call stack the only issue is setjmp/
longjmp, but they are not that useful anyway.

Wilco