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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use



.



Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

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.

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

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it
that
Quoted text here. Click to load it
that
Quoted text here. Click to load it

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.

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


Quoted text here. Click to load it

Hi David,

I'm afraid you're missing the point. What you are talking about is the run
time value of a pointer. What I am talking about is the compile time
attributes of a pointer.

You can stuff an invalid value into a pointer at run time but at compile
time the compiler knows that pointer by its attributes. If you decalre a
pointer to char and then stuff a pointer to func in it the compiler will
(or should) complain. Yes you can coerce the compiler into doing your
bidding but then you also take responsibility for the correct use of the
pointer thereafter - you can't blame the compiler for generating invalid
code.

Also, by talking explicitly about specific 'C' compiler implementations we
are getting side tracked from the issue which is that IT IS POSSIBLE for a
compiler to track the use of a pointer and if you give the pointer a
dedicated address space attribute, it is possible for *** A *** compiler
to generate good efficient runtime code without the "decode at runtime"
overhead. Think back to the 8086 'C' compilers that allowed "near"
addressing modes for segmented pointers.

My XCSB compiler generates efficient executables for the PIC despite the
fact that it allows pointers to RAM and CODE sapce and this is because it
does track pointer use.


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use



.


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

You can mess around with pointers to a great extent in C - and if the
compiler is following the ANSI standard, it must allow most of these
coercions.  Like it or not, you cannot call a compiler "standard" if it
is not possible to (say) convert a "char*" to a "const char*", and you
*are* free to blame the compiler if it generates invalid code.  In
particular, it is not uncommon to want functions that will handle a
string or a block of memory through a pointer, and the data pointed to
may be either "const" or not.  The only standards-compliant general
solution (on Harvard architectures) is for the "const" data to go in
ram.  Note that I don't think that slavishly following the standard is
necessarily a good thing here.  And if your compiler can figure out, at
least for the majority of cases, whether pointers and data should be
"flash" or "ram", then that is excellent.

Quoted text here. Click to load it

Exactly where in the ANSI C standards documents is the "near" pointer
qualifier described?  It is a proprietary extension to C to help
generate more efficient code.  It is non-standard.  Again, this is not a
bad thing here - I am just saying that the C standard allows for certain
types of pointer manipulation (some of which are actually useful) that
conflict with attempts of separating memory spaces, and that any way of
getting round this is necessarily a compromise.

Quoted text here. Click to load it

I think that is the best way to handle the problem, in general.  But how
do you deal with a function such as:

void sendString(const char* p);

char buffer[16];
void test(void) {
    sendString(buffer);
    sendString("Testing);
}

Quoted text here. Click to load it

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

How is having "const" data in flash not standards-compliant, if I can
access it, and RAM data, through a pointer-to-const?

Quoted text here. Click to load it

That code will work fine with the PIC C compiler I use, which stores
string literals in flash.
 
--
John W. Temples, III

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

It is not non-standard if you can access them both through a
pointer-to-const.  On von Neumann architectures, with a single address
space (such as msp430, ARM, 68k, x86, PPC) there is no problem.  There
is only an issue when the compiler must generate different opcodes to
read data from flash from reading data from ram, such as on the PIC (at
least the older ones I've used - maybe newer PICs have a single memory
space?), the AVR, or many other small 8-bit micros.  Then you can't
access ram and flash through a pointer-to-const (unless you are using
some sort of tagged pointer, which would be inefficient in both run-time
and code size).

Quoted text here. Click to load it

The last PIC I used was a PIC16.  Do newer PICs have a single address
space?  If that's the case, then I can see where I'm causing confusion -
I have been talking about Harvard architecture devices like the PIC16.

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

All PIC16 and PIC18 devices are Harvard architecture.  Hi-Tech's
compilers inspect pointers-to-const at runtime to access the
appropriate memory area.

--
John W. Temples, III

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

Ok, that's another way to handle the issue - but it costs in terms of
run-time performance and code size.  Perhaps the overhead is not
(relatively) that big on PICs - I don't remember *any* type of indirect
access being particularly efficient, although it was years ago that I
last used them.  Certainly the idea of extended pointers like this works
and gives you a lot of flexibility while sticking tightly to standards,
but on chips like the AVR, the cost is generally considered too high.

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


Quoted text here. Click to load it

Hi David,

This thread started out talking about how crap the PIC architecture is and
I have been trying to point out that it is not as crap as many people
would have "you" belive. Along the way the thread strayed into HLL (and
'C') space and now we seem to be fully entrenched in what is valid
standards complient 'C'.

Regardless of whether or not it is possible to trace the use of a RAM and
CODE space pointer in a standards complient 'C', the fact still remains
that with minor extensions IT IS POSSIBLE to do so.

I am really concerned that people with a limitted understanding of what it
is possible to do with a HLL base their critisisms of the PIC on what is
effectively a very old language developed for a mini computer with less
processing power than a modern PDA.

It is possible and practical for a modern HLL to do things that 'C'
cannot. We should be looking forward to what we can do with software not
holding ourselves back because the current software is limitted.

One of the reasons I chose to write a compiler other than a 'C' compiler
was to be able to freely take advantage of what can be done instead of
being tied to what others have been lead to expect.

Quoted text here. Click to load it

XCSB deals with this by allowing overloaded functions. I would effectively
have:

void sendString(const char* p);
void sendString(char* p);

In the future I will probably have a mechanism for automatically
generating different versions of a function to deal with both cases. Such
a mechanism is already in place to handle task safe functions
(multitasking is handled natively and not as a bolton library within
XCSB).


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use



.


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

bloody enormous SNIP

Quoted text here. Click to load it

Let's hope it is not as crap as your netiquette. Please trim quotes. Your
last post was 258 lines long.

Ian

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


<snip>

Quoted text here. Click to load it

I do not post just for your benefit.

Many people actually prefer to be able read through a single post without
having to jump around between posts to understand what is being refered
to.

When I do post something just for you I shall be sure to remove as much
useless clutter from it as possible.


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use



.


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
On Thu, 20 Oct 2005 13:13:22 +0100, Sergio Masci

Quoted text here. Click to load it

Sergio

Why don't you put all previous posts on your web site, so that the
0.1% of people unable to follow a normal usenet thread can access them
there? Or they can use some search tools.

One doesn't have to delete a post after reading it.

The rest of us prefer to have all unnecessary stuff removed from a
followup.

Tom

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

Most of us agree with Ian.  Trim posts is good.

Quoted text here. Click to load it

I'm sure sufficient context can be maintined without quoting
the entire thread.

Quoted text here. Click to load it

Please do the same for me. :)

--
Grant Edwards                   grante             Yow!  This is PLEASANT!
                                  at              
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

Well, I certainly don't feel like I gain any benefit from your posts, but
that is no excuse for bad manners.

Ian

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

<snip>

Quoted text here. Click to load it

The PIC (the old PIC16 at least - I don't know newer ones) architecture
*is* crap.  What you have managed to do (and I highly commend for it) is
write a compiler that makes this crap run well.  If you wrote a similar
compiler for a half-decent architecture like the avr, or a decent one
like the msp430, you'd get even better results.

Quoted text here. Click to load it

I think we agree that extensions or changes to C for use in embedded
systems are a necessary thing, and can often be a good thing even when
strictly-speaking unnecessary.  But if you have made extensions (like
adding "flash" or "near" keywords) or semantic changes (like changing
the meaning of "const"), it is no longer standard C.  I stress that I
don't see that as a bad thing (within reason).

Quoted text here. Click to load it

I fully agree here - C is a terrible language for small embedded systems
(or big embedded systems, or non-embedded systems for that matter).  It
should be possible to design an HLL that works far better in every way,
be it for a PIC or any other micro.  However, pretty much any reasonable
HLL will work better on better architectures - the PIC will still be
poor in comparison to others.

Quoted text here. Click to load it

I'm slightly confused here - your compiler is *not* a C compiler?  I
thought what you had written was a very smart C compiler.  If what you
have is not a "C compiler" as such, but a "modified C" or a "C with some
bits of C++" compiler (guessing from your overloaded function), then
that's fair enough.  It's likely to be a good solution - just as long as
you don't call it standard C.

mvh.,

David

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it
[snip]
Quoted text here. Click to load it

The point is not the type of object to which a pointer is
pointing, it's where the pointer physically points.

Quoted text here. Click to load it

You're going to recompile all the libraries with every job?!?
[Maybe this is a good idea.  Bye, bye linker.]

You find some calls to strcpy() that reference ROM for the
second argument and some that reference RAM.  You're going
to have function overloading in C and produce two versions
of strcpy()?

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

Quoted text here. Click to load it


All the more reason not to use library functions and a damn good one for not
using C at all.

Ian

Site Timeline