VON NEUMANN VS HARVARD

[Burton Samograd]

Yes you are right, it works on gcc. Some years back I tried it on quite a
different C compiler and it choked. Is this a case of a bad compiler or
is it something added in, lets say, the last 7 years.

BTW: Can this be done with an array?

Dang! I don't know! How do you declare the function whose return value is
an array?

int[] foo(int[]); // ?

you should use a pointer as the return value:

int* foo(int[]);

You have to hard-code the size, I think - or maybe union it onto a
structure? Then you'd still have to have a fixed size.

or you could pass the size as a parameter (emulating multiple return
values) that can be filled in by the function:

int* foo(int[] input, int *size);

and then before your return assign size:

*size = number_of_members_in_the_returned_array
return the_array_you_want_to_return

 

[Robert Gamble]

Yes you are right, it works on gcc. Some years back I tried it on quite a
different C compiler and it choked. Is this a case of a bad compiler or
is it something added in, lets say, the last 7 years.

BTW: Can this be done with an array?

Dang! I don't know! How do you declare the function whose return value is
an array?

int[] foo(int[]); // ?

You have to hard-code the size, I think - or maybe union it onto a
structure? Then you'd still have to have a fixed size.

Probably not. Anybody want to try?

It has always been possible to return structures in C. You cannot
return an array from a function but you can return a structure
containing an array (as perhaps it's only member) or a pointer that
points into an array.

Robert Gamble

 

[Flash Gordon]

That compiler was broken. The C89 standard allowed passing and returning
structures.

Dang! I don't know! How do you declare the function whose return value is
an array?

You can't. Not directly.

int[] foo(int[]); // ?

You have to hard-code the size, I think - or maybe union it onto a
structure? Then you'd still have to have a fixed size.

Probably not. Anybody want to try?

Close. Just declare a structure with the array as an element ant return
that. Just be aware that it means the array is getting copied around
which can be rather inefficient.

struct arr_ret {
int a[5];
};

struct arr_ret foo(int*);

Generally I would pass a pointer to the first element of the return
array instead, just like memcpy, strcpy etc.

I'm gonna crosspost this to comp.lang.c , but set followups to
sci.electronics.design, because those c.l.c folks are a little touchy
about marginally off-topic posts and banter and stuff.

You're question is about C and that is fine here and we don't mind a bit
of banter so I've re-instated the cross-post. Just remove the cross-post
if the thread drifts off C on to other things.

 

[Keith Thompson]

It has always been possible to return structures in C.

No, not always. That capability, along with structure assignment, was
added not long after K&R1 (Kernighan & Ritchie, _The C Programming
Language_, 1st Edition, which was the de facto language definition
before the 1989 ANSI standard was published).

Though I suppose in this business a few decades or so is close enough
to "always".

 

[Keith]

The one with the two busses can fetch the next instruction while it's
executing the first one, simultaneously. Nowadays, with these insanely
fast processors, it's pretty much unnecessary with all that queueing
going on.

The problem is even more severe _because_ the processors are so
much faster than memory. Modern processors fetch more than one
instruction from memory (memory is fetched in cache line
increments) at a time anyway, Harvard isn't needed for that.

 

[Robert Gamble]

No, not always. That capability, along with structure assignment, was
added not long after K&R1 (Kernighan & Ritchie, _The C Programming
Language_, 1st Edition, which was the de facto language definition
before the 1989 ANSI standard was published).

I thought this might have been the case but I don't have a copy of K&R1
and wasn't able to quickly confirm this with a web search before I
posted. Thanks for the information.

Though I suppose in this business a few decades or so is close enough
to "always".

Robert Gamble

 

[Nico Coesel]

Nico Coesel wrote:
single memory space

Keep in mind not all CPUs look like x86. Most pure Harvard machines
like the PIC and AVR and some Von Neumann CPUs (PowerPC I believe?)
have built in bit set/toggle/clear instructions and can do it in
hardware in a single instruction cycle - far less wasted instructions
and much more nifty. Besides, bit read-modify-write is done on the data
memory, nobody's touching the program memory, so it doesn't matter if
it's Harvard or Von Neumann - both behaves the same and if the
instruction sets are similar requires exactly the same amount of
instruction codes. So what exactly are you talking about?

There is a limited number of instruction codes which can be executed
in one cycle. For each memory space, extra instructions are required
to access it (move, test, add, substract, etc). This leaves less room
for other instructions and may force the designer to make some
instructions longer (which will take 2 or more cycles to fetch and
execute).

 

[Nico Coesel]

Are you kidding me? Every single modern superscalar CPU is internally a
Harvard CPU. x86, PowerPC, Sparc, MIPS, ARM9 and Alpha are
microarchitecturally Harvard, only at the point of memory controllers
do they look like traditional Von Neumann CPUs. What do you think the
separation of icache and dcache is all about? It's about performance:
being able to decode the next istruction while manipulating the current
data. It's about being able to fetch and commit data and instructions
simultaneously.

Pure Harvard CPUs like the PIC and AVR have supported C for a long
time. In fact, the AVR was not only designed specifically to support C
but was designed with the input of C compiler writers/developers. I
have 5 C compilers designed for pure Harvard machines so don't tell me
that C "doesn't like" Harvard. OK, yeah the PIC is difficult to write a

C has become more than just a language. Part of the power of C lies in
the standard libraries. Show me a strcpy function which can take a
pointer in the instruction memory or data memory as the source on a
Harvard style CPU.

This problem pinpoints the problem you'll run into when you are going
to take a harvard cpu beyond plain number crunching. Working with
strings is a nightmare on a Harvard CPU if you want to use both
constant strings and variable strings. If you have enough memory, you
might choose for copying the constant strings into data memory, but
this might be limited in size or slow (like on any 8051 derivative).

 

[Nico Coesel]

binary-machine-code to the instruction stream will there be a
difference between Harvard and Von Neumann machines. Nico's statement
is still wrong.

Then tell me why I need pragma's and non-C extensions when writing C
code for Harvard CPUs to tell the compiler where the data should be
stored & fetched?

 

[[email protected]]

Then tell me why I need pragma's and non-C extensions when writing C
code for Harvard CPUs to tell the compiler where the data should be
stored & fetched?

You don't need any pragmas. I've never needed any pragmas when using
the following compilers:

1. AVR gcc
2. HITECH C
3. Keil
4. CC5x
5. CSS

So, what compiler are you using and why do you need those pragmas? I've
only ever needed pragmas for storing data when using a Von Neumann CPU:
the 8051.

 

[[email protected]]

The one with the two busses can fetch the next instruction while it's
executing the first one, simultaneously. Nowadays, with these insanely
fast processors, it's pretty much unnecessary with all that queueing
going on.

Agreed but Nico was saying that the one with the single bus is faster.
What I'm saying is, even granting him that his instructions are cached,
it will only make it just as fast as a Harvard machine. I don't see how
he can say that Von Neuman machines are faster "because" of the unified
memory space.

 

[[email protected]]

There is a limited number of instruction codes which can be executed
in one cycle. For each memory space, extra instructions are required
to access it (move, test, add, substract, etc). This leaves less room
for other instructions and may force the designer to make some
instructions longer (which will take 2 or more cycles to fetch and
execute).

For each memory space? You only access data in data space, you don't
access data in instruction space (well, on a Von Neumann machine you
can of course). No extra instructions are required. On pure Harvard
machines, jumps, branch and gotos only operate in instruction address,
read/write data access only operate in data address - actually, just
like a Von Neumann machine except instruction and data address are
separate. And most Harvard CPUs are typically also RISC CPUs - they
only have a single instruction size. I have personally never seen a
Harvard CPU with multiple instruction sizes, can you show me one?

Because the data and instruction memory are seperate CPU designers can
use different sizes for them. This allows Harvard machines to *always*
be able to be designed as a single-instruction-per-word RISC machine.

 

[[email protected]]

Baloney. You need a write and a read port for the processor and
another set for the L2/bus. Just because one instruction can't
read and write at the same time doesn't mean there is only one
instruction executing. Time multiplexing ports is still creating
ports, and complexity.

Bullshit. I have a Pentium2 motherboard that uses simple SRAMS as L2
cache. Those chips only have a single read/write port (I would know, I
salvaged them when my mobo died). Caches, even today, are not usually
multiported. Don't know about newer chips but even as late as the
Pentium3 the cache is not multiported.

You have a read and a write port for the processor. How does the
data get into the cache? A: Two more ports (at least).

Not necessary (this proven by the fact that in the real world caches
are in fact single ported). You only load cache when there's a cache
miss (or predicted cache miss). When a miss happens the data is not
available anyway so instruction processing is temporarily stalled or on
threaded CPUs switches to a thread that doesn't stall.

Actually it was done that way before because the I and D units were
too far apart.

When? Caches were single ported on most CPUs up to 2001. And on most
CPUs they are still single ported to this day, at most they have
separate read and write port. What CPU implements this massively
multiport cache you're talking about? You know, before the I and D
units were too far apart?

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[....]
Nonsense. It's trivially easy to pass and return structures - the only
limit is your stack size:
Yes you are right, it works on gcc. Some years back I tried it on quite a
different C compiler and it choked. Is this a case of a bad compiler or
is it something added in, lets say, the last 7 years.

BTW: Can this be done with an array?

Dang! I don't know! How do you declare the function whose return value is
an array?

int[] foo(int[]); // ?

You have to hard-code the size, I think - or maybe union it onto a
structure? Then you'd still have to have a fixed size.

Probably not. Anybody want to try?

It has always been possible to return structures in C.

Sorry, but you are mistaken.

"There are a number of restrictions on C structures. The essential rules are
that the only operations that you can perform on a structure are take its
address with &, and access one of its memebers. This implies that structures
may not be assigned to or copied as a unit, and that they can not be passed
===============
to or returned from functions."
=======================

The C Programming Language
Brian W. Kernighan * Dennis M. Ritchie
Copyright (c) 1978 by Bell Telephone Laboratories, Incorporated

It has been possible to pass and return _pointers to structures_ in C, but
only recent standards (i.e. 89 and after) permitted passing and returning
actual structures.


[snip]


HTH
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPu5SagVFX4UWr64RAnGiAKCdgETkkIeNzxP5Tv9eRMVoNMNDrACfZsgX
4mJdM+L09jlZnyitjMNHahw=
=ZtRY
-----END PGP SIGNATURE-----

 

[Ken Smith]

Generally I would pass a pointer to the first element of the return
array instead, just like memcpy, strcpy etc.

But if you do that, you loose the ability to check for overruns. The
point was that using pointers makes checking very hard to implement. If
you are only returning a 3 or 4 element array, the cost of the extra
overhead may be worth it.

It was part of my explaination[1] of why the C language is so horrid.
[1] troll

I have to admit it isn't as bad as C++ or Intercal.

 

[Ken Smith]

The one with the two busses can fetch the next instruction while it's
executing the first one, simultaneously. Nowadays, with these insanely
fast processors, it's pretty much unnecessary with all that queueing
going on.

Actually, it may be able to fetch more than one depending on the
instruction bus width and the instruction length.

 

[Ken Smith]

separate. And most Harvard CPUs are typically also RISC CPUs - they
only have a single instruction size. I have personally never seen a
Harvard CPU with multiple instruction sizes, can you show me one?

Are you counting number of models or number of units sold here? The 8051
and the PIC are both HA and there's a whole lot of them out there.

 

[[email protected]]

<snip>
So, what compiler are you using and why do you need those pragmas? I've
only ever needed pragmas for storing data when using a Von Neumann CPU:
the 8051.

Erk sorry.. the 8051 is indeed Harvard. Now I see why you are
complaining. I've always hated that beast.

 

[[email protected]]

Are you counting number of models or number of units sold here? The 8051
and the PIC are both HA and there's a whole lot of them out there.

Well.. both, though I'm not sure if the 8051 surpasses everyone else in
number of units. Anyone have the numbers? For the purpose of the
discussion above the PIC is more RISC-like than CISC-like especially in
terms of not having multiple instruction sizes. PICs are all one
instruction per cycle affairs (except of course for jumps) with a 2
stage pipeline (the two cycle execution of jumps is due to bubbles).
PIC, AVR and MAXQ are good examples of what I'm talking about - RISC
(or RISC-like) Harvard CPUs with constant instruction size.

 

[Ian Bell]

So, what compiler are you using and why do you need those pragmas? I've
only ever needed pragmas for storing data when using a Von Neumann CPU:
the 8051.

Er, the 8051 is very definitely Harvard old chap.

Ian