Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

This is simply wrong. A compiler can trace the use of a pointer throughout the code at compile time. What you need to do is add an attribute to the pointer that says "this pointer can only ever point to RAM" or "this pointer can only ever point to CODE". If you want you could call this attribute "const" and insist that all const pointers point to code and all non-const pointers point to RAM.

The fundamental problem with your "transparency" assertion is that you are picking up on a particular language shortfall and translating it to the underlying architecture.

Regards Sergio Masci

Actually, I would say it's more of a language issue.

I'm not really suggesting a dynamic "RTTI like" solution, just a more complete static type model that recognizes different memory spaces.

No they don't what?

I am referring to pure harvard architecture, (e.g. AVR) where ROM and RAM address spaces are accessed with different instructions. IOW pointers to to different address spaces are possible.

For embedded use, C/C++.

By definition, "extensions" are not standard.

and allocate it

This is more than a "const" issue. For architecture such as the AVR, there are two entirely separate address spaces, each of which is accessed with different instructions.

The C/C++ const qualifier only tells the compiler that a particular object may not be written (and thus may be placed in a read-only section of memory.)

A function which accepts a pointer/reference to a const variable/object can also accept a pointer/reference to a non const variable/object without problem.

The same semantic cannot be applied to pointers to two separate address spaces.

(or something like that ;-)

Microchip has a *new* architecture for the 16-bit chips like the dsPIC and PIC24, it is actually quite good.

Leon

Nobody uses printf for simple printing of constant strings. If you need only some of the functions like number formatting printf can already be useful, and looking for a cheaper function while the program fits in your target controller is wasted time.

Sergio Masci schrieb:

As I said, in theory you can hide any architecture issue from the programmer with software. But if none of the compilers does this (because it would require a lot of effort or would create too much overhead), this knowledge is of little value for me.

Sounds to me like a case of the tail wagging the dog.

Ian

Precisely my point - they are general purpose routines and do a whole bunch of things you don't need them too i.e. wasted space in a memory constrained product.

Ian

Apart from the fact that Acorn claimed to have started development of their own CPU due to 32-bit processors at the time lacking the latency they were used to from the 6502, the only thing that's a callback to the 6502 is the strict three letter mnemonics. It's most obvious in ORR, which obviously comes from ORA. But the architectures are otherwise too different to have much in common.

If the library sources are available, it should be easy to disable the floats etc.

However, if the library sources are not available, but if the library object files have been divided intelligently, e.g. the actual printf function in printf.obj and the floating point printing routines in print_float.obj, it should be possible to create dummy_float.c containing e.g.

void print_float (double d.....) { return ; }

Put the dummy_float.obj on the linker command line _before_ the library files. When the linker detects the printf reference in he application program, it extracts the printf.obj from the library. Since that printf module contains a reference to print_float, the linker already knows where it is, since it has been provided by the dummy_float.obj and does not need to retrieve the print_float.obj from the library.

Paul

In article , Andreas Schwarz writes

point taken

In article , Andreas Schwarz writes

ICE or JTAG

only understand a single contiguous address space

There are quite a few Harvard architecture MCU about. They all have compilers that handle it with no problems.

what do you mean by "traditional compilers/languages" There are many Harvard compilers about. C and C++ They are separate languages have know knowledge of HW architectures.

There are no compilers you would use for embedded work that don't have extensions to ISO C. Actually there are no Standard C compilers anyway.

from little acorns.... Wiki is good on ARM

martin

that

that

Particulary not in the face of separate compilation. Even if the entire source is available, it still may not be able to determine where a pointer points (a number is a number is a number...).

And if we want to get even a little more picky about it, the AVR has a third address space (I/O) which (somewhat) overlaps the RAM address space and includes the register set.

Some compilers can help with this. For example HI-TECH says about a feature of their upcoming "Pro" compiler series:

"Automatic Generation of printf Code: The code associated with the C library function printf() has been removed from the library files. After a preliminary scan of the user's C source code, an appropriate printf routine is "written" by the compiler that will suit the function's usage, based on the placeholders used in the format string in calls to printf()."

-- Dan Henry

And where do you get 78 bit micros?