Just what makes an architecture "C Friendly"?

Yes, we've talked about this before, and I do (or have done) exactly the same thing - design in C, then hand-compile from there.

However my point was that this thread seems to be confusing compiler

*platforms* and compiler *targets*. For all the projects I've done since around '84, I've used a PC as a compiler platform. But targets have included 64180, 8051, 68k, H8 (many flavours), Rabbit, probably a few others I'm forgetting about - and occasionally the PC itself. By "C-friendliness", I'm presuming we're talking about the target. The platform is not relevant.

Unless, as I said, I'm missing something.

Steve

And, as has since been pointed out elsewhere in this thread, that has nothing to do with Harvard vs. von-Neumann architecture. Whether read-only data should be treated as data or code is a separate issue from whether data and code share the same memory space.

It's not the Harvard architecture that makes C on, say, 8051s tricky. It's the decision to stuff constants into code memory.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

There's a confusion of terms here (no doubt it's my fault). What I refer to as the register stack in MIPS is not like the PIC, where the return stack is implemented as hardware registers, but that the registers form a stack. For each function call entry, the "stack pointer" moves up by 16. Code can directly access the top 24 elements of the register stack (the other 8 registers being global "normal" registers). It's a nice architecture from some viewpoints - calls and returns are very cheap, but a pain from others - context switches are, I believe, expensive.

That's true, but in the context of embedded programming, it's nit-picking. It is theoretically possible to have a Harvard architecture flash-based microcontroller where both the code and data buses had direct access to the flash so that read-only data could be stored in flash and accessed in the same address space as ram. It is also theoretically possible to have two flash blocks - one on the code bus, and one on the data bus. But such a device would not be economically practical (except perhaps for specialised usage - some DSPs have multiple memories like that).

What on earth does the size of the compiler have to do with it??

--
Grant Edwards                   grante             Yow!  Don't hit me!! I'm in
                                  at               the Twilight Zone!!!
                               visi.com

In the real world _it's_the_same_thing_.

Sure, in some fantasy world there probably are Harvard architecture processors with ROM in data space.

What decision? If all of the ROM is in code space (which it is on the Harvard architecture uControllers I've used), where do you propose we _put_ the non-volatile, read-only data?

You're argument the equivalent of "Pigs aren't slow because if they had wings they could fly."

--
Grant Edwards                   grante             Yow!  Hello, GORRY-O!! I'm
                                  at               a GENIUS from HARVARD!!
                               visi.com

A mouse will fit in your pocket, an elephant will not.

We're not trying to fit the compiler onto the target.

--
Grant Edwards                   grante             Yow!  I appoint you
                                  at               ambassador to Fantasy
                               visi.com            Island!!!

The problem is the lack of RAM space here, not the Harvard architecture itself. If there were enough, then you could just put the non-volatile, read-only data into code space, and then copy it to RAM at system startup. This is what many larger systems do in order to take advantage of faster access speeds in RAM.

The real hurdle here perhaps is that the majority of processors with a Harvard architecture also have very little writeable memory.

-- Darin Johnson

Such a hardware register stack is called "register windowing", and it is a feature of SPARC, not MIPS - MIPS uses a software stack like most architectures.

Wilco

Some of the 'we', that I know, do it from time to time.

Ah, that explains it - sorry for the confusion. I've not used either the MIPS or SPARC, only read about them, although I've used the NIOS (original type, not the NIOS II) which also uses register windowing. I thought that the SPARC would be more familiar to others than the NIOS, but of course it helps if I get the right architecture name! Thanks for the correction.

David

When designing a chip that has to be as small (die area) as possible, and which frequently must start running its code as fast as possible, why would you want to duplicate your memory requirements (especially with static RAM cells being bigger than flash cells), and take force a longer startup time?

If you really want to make a C-friendly Harvard architecture microcontroller, the only practical way to do it is by including a bridge between the buses, so that the flash (on the code bus) can be read by data instructions. Most microcontrollers (except, of course, the bizarre PIC) have something like that, but it's not transparent. They need a special instruction (LPM, "load program memory", for the AVR), breaking the single data address space requirement. All that's needed is for a section of the data memory space to be mapped transparently via the bridge onto part of the main flash (it wouldn't even be hard to do, especially since it would not cause problems adding a wait state or two). Of course, you couldn't access the whole of the flash in this way, but it would be a 95% ideal solution.

Actually a solution that would please a lot of developers for Havard AND Von Neuman architectures, would be two flash areas, where the data area can be erased in blocks and written while reading the code flash. The amount of times a simple power safe logger application could be performed this way, without adding external devices, comes up too often in my view. Often there is not enough RAM available for swapping in the code and data space required for a flash loader as well as application requirements, without using a much larger chip, just for the RAM, that then puts the cost up.....

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

I was pleasantly surprised that the Analog Devices ARM7 ADUC702x parts allow exactly this. I expected to have to relocate a flash driver in RAM and disable interrupts during flash programming. But none of that was needed - it can happily erase/program one block while reading & executing from another. The datasheet does not even mention this important property!

Only 64kB flash so may still be too small for many datalogger applications. But it is great as a replacement for on-chip EEPROM and for storing settings etc.

--

John Devereux