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).
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.
You've snipped the next bit of my paragraph - "The difference between upper and lower registers is very annoying, but hardly difficult to remember - only upper registers can use immediate addressing modes." I was not referring to the immediate opcode issue here, nor the limited pointer modes (which I think is a far bigger problem than the immediate addressing modes, and which should have been a priority when the cpu was first designed).
Actually, now that I look at the datasheets again instead of relying on memory, I see that about the only one that was fixed was (E)LPM, which used to rely on a particular register R0. I had thought that the multiply instructions (which use specific registers R0:R1) was also made more general, but I was wrong there.
I was not referring to external interrupts, although the jitter on these is also substantially worse on an AVR. On a PIC, the interrupt latency is consistent, as all instructions take either 1 or 2 internal cycles, and the pipline is arranged in such a way as to equalise latency regardless of what instructions are being executed at the time. If you set up a regular timer interrupt to generate an output waveform, it will be rock-solid. Do the same on an AVR and you will see jitter due to the varying instruction times.
Correct: where jitter free interrupt vector is nice, is when you want to add some SW into the HW-Time domain. It may be to generate a clean BEEP, or to launch another peripheral, or sample a pin, or update a DAC.... Not all 80C51's have HW that can toggle pins, especially at the simpler end of the spectrum, or the HW pin may be already committed for other uses. That is improving, as over time you get more for your $$.
I agree and therefore standard library functions will not suffice. Hence my first assertion. As the specifics are micro specific I contend they are best written in assembler; hence my second assertion.
I don't know the PIC enough to comment but I'm happy to take your word for it.
Except you can do no other processing other than the timer interrupt - seems a tad pointless or at least limiting in functionality?
As does the 8051 except when in IDLE.
So it appears the only time this matters is when using an internal timer and you want a jitter free response on some software controlled output via the Timer ISR. Unless the code to do this is trivial considerable care will be necessary to ensure its execution time is constant. Perhaps the obvious application is toggling a I/O line which is IMHO trivial and anyway achievable without jitter on the 8051 via hardware.
This applies only to very trivial applications with only a single interrupt (the timer interrupt) in the system.
In systems with multiple interrupts, some concept of hardware arbitrated interrupt priority and automatic nested interrupts would be required in order to get a low latency for the highest priority interrupt.
In systems with even a few interrupts, it is often necessary to disable the interrupts for a few instructions, e.g. when the main program needs to update a 16 bit value used also by an interrupt service routine on an 8 bit processor. This could delay the interrupt service routine with a few instructions.
IMHO, the question of fixed vs. variable instruction execution times is relevant only with very trivial applications with only a single interrupt source and no non-atomic variable updates in the interrupt service routine.
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.
Just because an application has only one interrupt source, that doesn't necessarily make it trivial. (And the Pic18 range has prioritised interrupts so you can do a jitter-free timer interrupt while other interrupts are happenning)
Just to muddy the water a bit more, I'm currently doing some work for a processor having two disjoint RAM spaces. I'm certainly glad I don't have to work out the details of making the C compiler for it generate the correct code.
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.
XCSB deals with this by allowing overloaded functions. I would effectively have:
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
formatting link
- optimising PIC compiler FREE for personal non-commercial use
.
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.