VON NEUMANN VS HARVARD

[Flash Gordon]

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.

OK, I can accept that.

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.

In some respects C is a horrid language and there are a number of things
I wish were different.

 

[John Devereux]

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

Then your programs must not have had much constant data.

You need pragmas, or something equivalent in practice, if you have
significant amounts of constant data (e.g. strings, lookup tables,
menu structures). The C run time system has to copy all such into RAM
in order for it to be accessed as data. Most "harvard" processors
these days seem to be microcontrollers, which have comparatively
little RAM to begin with. It would be much better if constant data can
be left in ROM.

An alternative is for the compiler to embed extra information into
pointers, indicating whether the pointer is to "data" or "program"
space. But this makes the code slow and bulky, since each pointer has
to be interpreted at runtime.

This is the main problem with the AVR IMHO. It is much nicer working
with the newer ARM microcontrollers.

 

[Ken Smith]

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.

I wouldn't characterize the PIC as "reduced" instruction set for the same
reason as I wouldn't say a PDP-8 was a RISC machine. They are both "very
simple processors" out of the need to keep the number of transistors low.

 

[Keith]

Bullshit. I have a Pentium2 motherboard that uses simple SRAMS as L2
cache.

No you don't. PIIs had the L2 on the backside of the bus, on the
cartridge. The original Pentiums (socket 5/7) had SRAMs on the board.

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 are *SO* wrong.

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.

You'd better study Computer Architecture 101 a bit harder.

When? Caches were single ported on most CPUs up to 2001.
1960s.

And on most CPUs they are still single ported to this day, at most they have
separate read and write port.
Nope.

What CPU implements this massively multiport cache you're talking
about?

All current High-end CPUs.

You know, before the I and D units were too far apart?

At least S/370 ->

 

[[email protected]]

Then your programs must not have had much constant data.

All the compilers above recognises "const" which is standard C to mean
constant data and will optimise them away into a look-up table in
program memory/ROM. No pragmas needed.

 

[John Devereux]

All the compilers above recognises "const" which is standard C to mean
constant data and will optimise them away into a look-up table in
program memory/ROM. No pragmas needed.

No, they do not. In the case of AVR gcc, look at avr-libc, there is a
whole infrastructure of "program space" macros and functions that are
required in order to achieve this. If you do not use these, and stick
to standard C, then the linker will put the constant data in the data
section, which will be copied to RAM by the c startup.

 

[Mark Zenier]

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.[/QUOTE]

No, the ability to pass and return structures was added
into Unix Version 7 C. Along with the enumeration type.

_Recent Changes to C_,
November 15, 1978,
Page 277, Unix Programmers Manul, V.2
1979, 1983, Bell Telephone Laboratories
Holt Reinhart and Wilson

There was a warning that the PDP-11 version didn't handle
reentrancy within an interrupt properly, though.

Mark Zenier [email protected]
Googleproofaddress(account:mzenier provider:eskimo domain:com)