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

Forgot the one that is RARELY needed in embedded situations, and relying on it, would mean a bad design anyway - printf returns the number of characters output which I have not *yet* seen an application use.

Makes a lot of assumptions, works on one library, for better code reuse for MINIMAL footprints, use a stripped down one for usability on more compilers and targets.

Assuming the library module for that function, is actually a separate module whereby you can save space, otherwise you will have it *POTENTIALLY* included but not used.

That solution is very compiler/linker/library dependant.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter
Loading thread data ...

that

that

where a pointer points to is not the issue, what a pointer is pointing to is.

Consider a pointer to a "char". No mater where the pointer is pointing the compiler knows it is pointing to a "char". Regardless of how you manipulate the pointer the compiler will always derefernce it as a char pointer. You can play hide and seek and force a non char pointer into it but that is not the point. Here "char" is an attribute of the pointer and the attribute is tracked throughout the use of the pointer at compile time NOT runtime. Another attribute could easily be the address space (RAM, CODE, I/O etc). The actual runtime contents is not important, the compile time attribute is.

With regard to seperate compilation: don't make me laugh!

Yes it may have been necessary 20 years ago to compile a 10,000 line C program as seperate 1,000 line modules because each module took 5 minutes to compile (on a state of the art PDP/11). But today a 1,000,000 line program takes less than 2 minutes to compile AND given that most programs for a tiny MCU are much smaller than this, seperate compilation is not necessary and in many cases it is actually counter productive from an optimisation standpoint.

Regards Sergio Masci

formatting link
- optimising PIC compiler FREE for personal non-commercial use

.
Reply to
Sergio Masci

Hi-Tech's C compilers for the PIC have RAM/ROM pointers without the use of extensions. Const objects (those which have storage allocated) and string literals reside in ROM. Other objects reside in RAM. Pointers to const point to ROM and RAM, with the appropriate address space determined at runtime. Other pointers point only to RAM.

--
John W. Temples, III
Reply to
John Temples

Where?

Reply to
Andreas Schwarz

No what you said was "using a layer of software" not "with software" these are different things.

We hide the underlying architecture with software every time we use a high level language.

Writing any half decent compiler "requires a lot of effort"

Yes compilers that generate VERY EFFICIENT executables for the PIC do exist. And at least one assembler (XCASM) that performs analysis of RAM and code page useage does exist and yes it does insert RAM and code page select instructions at optimal locations. I guess the gripes is that this is not done by the FREE Microchip assembler.

Also, using the XCSB compiler, you can add lots of embedded (inline) assembler and not worry about RAM and code paging.

Yes tools that do the job (and do it very well) do exist. You just obviously don't know about them.

To claim that the underlying PIC architecture is a problem is nonsense. It's crap compilers and assemblers that are the problem.

Regards Sergio Masci

formatting link
- optimising PIC compiler FREE for personal non-commercial use

.
Reply to
Sergio Masci

errrr..... in a custom FPGA :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

There's a serious danger of going round in circles here because that's just what the OP was doing with printf.

Ian

Reply to
Ian Bell

Wow.

Well, looking at your signature, I feel a little bit better, because now I understand how come someone can write paragraphs like the one above.

Reply to
Mochuelo

Sergio Masci schrieb:

We were talking about AVRs and RAM/ROM. Still looking for a compiler that can "do the job".

Reply to
Andreas Schwarz

Surely you're not suggesting that it is a good practice to have a single "compilation unit" as a general rule. And it would be even worse to *require* such a technique.

Code is not modularized based on compilation time. That's not even my close to my first consideration.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

Pass.

Ian

Reply to
Ian Bell

In article , Sergio Masci writes

So why are there so many crap compilers for PIC?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

In what way?

It is almost impossible to write sensible programs on many MCU unless you do use them.

Again this is often not possible.

Very few are. There are good reasons for this.

Can you name any?

However the are very open and undefined in some areas.

It has been done.

However there are no C99 conforming compilers.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Some uC's use harvard designs, but 'flatten' the memory map in hardware to make things simpler for novice C users - others have FLASH that can map into DATA space.

The AVR sort-of does HW-Overlay that with IO and RAM, and they COULD have done it with CODE - but there are a couple of problems in doing that :

** if you look at the execution times, the LPM instruction is SLOWER than the LD opcodes. (Flash is slower than RAM) ** It makes most sense on the smallest cores, (where the small library savings might make a difference) but on the bigger cores, you cannot reach ALL the code, so that adds complications to something that was intended to simplify....

The AVR also has a natural opcode reach limit at 64K, so above that you need to introduce the Page-handling for LPM and CALLs. On their biggest parts, they do handle RET with an extra cycle/byte

Also, last time I looked, the MSP430 had poor/none external RAM handling ?

Better uC also map their EEPROM, into data space, so that allows users to have simpler mixing of CONST and VAR strings. Of course, it's a little more work to get the CONST String info into the EEPROM, but I have seen this done to save valuable code space, and simplify the libraries...

Of course, in the new ARM uC, their 32 bit indexes mean you can map everything into one space. Code size is larger, but life is simpler....

-jg

Reply to
Jim Granville

Because the market tolerates them.

Regards Sergio Masci

formatting link
- optimising PIC compiler FREE for personal non-commercial use

.
Reply to
Sergio Masci

Yes and no. I am stating that it is good to have the compiler compile all the source in one go but I am not suggesting that all the source is presented in one file.

I'm not surprised given the speed of modern PCs.

Regards Sergio Masci

formatting link
- optimising PIC compiler FREE for personal non-commercial use

.
Reply to
Sergio Masci

Sorry I thought we were talking about RAM / CODE on the PICs.

Anyway it is still trivial to write an assembler that emits a machine code instruction based on the address space of the operand. There really is no need to have different nmeonics for instructions that handle different address spaces.

I could probably add this functionallity to the XCASM meta assembler in less than a day.

Regards Sergio Masci

formatting link
- optimising PIC compiler FREE for personal non-commercial use

.
Reply to
Sergio Masci

that

that

A char* pointer does not necessarily always point to a char. Like it or not, C code (both libraries and user-written code, and not just bad code either) is full of code that messes around with pointers and what they point to. In particular, char* and void* are used to point to any old bit of memory. And it is perfectly legal to add a "const" qualifier (though not to remove one), so it cannot be used to mean "in flash" without breaking from ANSI standards. C specifically requires one single memory space - any method of supporting different memory spaces requires either proprietary extensions (such as IAR), standard-breaking shortcuts (such as using "const" to mean "in flash", as used by ImageCraft - convenient and natural, but still not "C"), or ugly macros (avr-gcc). You can, however, get very close to perfect by compiling the entire program at once and having the compiler figure out what goes in each memory space - then your only problem is with code that is sometimes called with a ram pointer, and sometimes with a flash pointer.

Reply to
David Brown

I think he is suggesting that all the modules are compiled at once, not that you only have one module. I fully agree with him in this case - separate compilation made sense long ago, and still makes sense on large systems, but the traditional compile-assemble-link cycle is absurd for small microcontrollers. Compiling all the modules at once gives much greater opportunities for optimisation - even gcc (a traditional tool if ever there was one) now has options for program-at-once compilation, and can then do cross-module optimisations.

Reply to
David Brown

Which is reasonable for small programs, however, I would not think it would scale well to larger systems.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.