lucky
Microchip staff
Reged: Oct 06 2003
Posts: 1184
Loc: Brisbane, Australia
|
|
I've started this new thread to discuss the development of the PICC PRO compiler.
This is continued from this thread.
Quote:
Quote:
Code:
var = (var << 1) | (var >> 7);
will result in:
Code:
rlf _var,w
rlf _var,f
This is a lot more optimized compared to what the standard PICC code generator can produce.
Very interesting. But may I ask, any side effect?
Sorry, what do you mean by side-effects?
Basically, it looks for an appropriate expression and optimizes the shifts into rotate instructions.
--------------------
Matt Luckman
Microchip Technology Inc.
|
G.Neiss
Reged: Dec 26 2004
Posts: 474
Loc: germany
|
|
Quote:
This is mainly because of the limitations of the C language.
Quote:
jtemples: C doesn't have a rotate operator, so you have to manage bits moving between bytes on your own.
Yeh, that's the problem. In C You can't use rotate directly.
But what's about a pseudo inline function ??
Instead of trying make a code generator that optimizes such cryptic C constructs into the best asm sequence, I would suggest using 'pseudo inline function' !
A user might use:
#define NumberOfBytes 6
char Rx[ NumberOfBytes ];
PseudoFunc_ShiftLeft( Rx, NumberOfBytes );
PseudoFunc_ShiftLeftCarry( Rx, NumberOfBytes );
PseudoFunc_RotateLeft( Rx, NumberOfBytes );
PseudoFunc_RotateLeftCarry( Rx, NumberOfBytes );
witch is then translated into:
Rotate_Macro MACRO adr,bytes;
LOCAL index;
index set 0;
REPT bytes;
rlf adr+index;
index set index+1;
ENDM
ENDM
; PseudoFunc_ShiftLeft( Rx, NumberOfBytes );
bcf _STATUS,0;
Rotate_Macro MACRO _Rx,NumberOfBytes;
; PseudoFunc_ShiftLeftCarry( Rx, NumberOfBytes );
Rotate_Macro MACRO _Rx,NumberOfBytes;
;PseudoFunc_RotateLeft( Rx, NumberOfBytes );
bcf _STATUS,0;
btfsc _Rx+NumberOfBytes-1,7
bsf _STATUS,0;
Rotate_Macro MACRO _Rx,NumberOfBytes;
; PseudoFunc_RotateLeftCarry( Rx, NumberOfBytes );
Rotate_Macro MACRO _Rx,NumberOfBytes;
Most of such sequences may be represented by such 'pseudo inline functions'.
All that has to be done is:
- Writing a H-file that contains declarations of this functions
- Integrate into the code generator a mechanism that detects the usage of such functions, who then emit's the desired asm sequence.
Some of Your competitors use such a way and it's IMHO a very good way (it's althougth ANSI complicant).
|
lucky
Microchip staff
Reged: Oct 06 2003
Posts: 1184
Loc: Brisbane, Australia
|
|
Quote:
Yeh, that's the problem. In C You can't use rotate directly.
But what's about a pseudo inline function ??
Yes - we have actually already implemented something like this in our standard ARM compiler and we could do so in the PIC compilers.
This type of solution fits nicely with rotate, however, the philosophy we are using with new PRO compilers is to move away from non-standard things (qualifiers, etc..) when dealing with hardware specific things. For example, PICC PRO no longer requires the bank qualifiers. This alone, will make writing code for the PIC much easier.
--------------------
Matt Luckman
Microchip Technology Inc.
|
John Payson
Reged: Oct 16 2003
Posts: 1133
|
|
Quote:
For example, PICC PRO no longer requires the bank qualifiers. This alone, will make writing code for the PIC much easier.
Maybe I'm a masochist, but I like banking qualifiers, and find myself annoyed that HT-PIC18 doesn't allow more useful forms thereof.
My preferred "memory model" for the PIC-18 would be to have four storage classes:
-1- Objects which are kept in the common bank
-2- Objects which are kept in one "primary" 256-byte bank shared among all routines
-3- Objects which are kept in one page per module
-4- Objects which located anywhere.
Pointers would have four storage classes:
-1- Pointers to common-bank objects
-2- Pointers to primary-bank objects
-3- Pointers to any RAM objects
-4- Pointers to any RAM or code objects
The present banking methodology often works very poorly, requiring scores of "movlb" instructions even in cases where all memory objects total less than 384 bytes (and thus one movlb instruction would suffice for the entire program!) Having a compiler try to allocate things intelligently may be more convenient than dividing them into the above storage classes, but would have a major drawback: even a slight change to the source could cause very major changes to the produced code. This could easily break things, especially if the program uses any embedded assembly-language routines. In many cases, it would be more useful to let the programmer force certain conditions upon the banking.
|
lucky
Microchip staff
Reged: Oct 06 2003
Posts: 1184
Loc: Brisbane, Australia
|
|
Quote:
Maybe I'm a masochist, but I like banking qualifiers, and find myself annoyed that HT-PIC18 doesn't allow more useful forms thereof.
I'm sure I don't have to point out the number of posts on this forum (let alone submitted to support@htsoft.com) which involve the error messages "Can't find space in..." or "fixup error in..." which are usually caused by not using the bank qualifiers at all/enough or inappropriately.
If you know what you are doing, then having them can be good because you have control over data placement - the downside is portability and learning how to use them.
It is likely that there will be an option in PICC PRO to re-enable the bank qualifiers, but out of the box, you won't need them.
Quote:
My preferred "memory model" for the PIC-18 would be to have four storage classes:
To discuss PICC-18 further, a new thread has been started - this one is for PICC PRO only.
--------------------
Matt Luckman
Microchip Technology Inc.
|
jtemples
Guru
Reged: Oct 16 2003
Posts: 1607
Loc: Southern California
|
|
Quote:
But what's about a pseudo inline function ??
I vote for the compiler figuring it out on its own.
|
YT Lee
Reged: Oct 16 2003
Posts: 83
|
|
Quote:
Sorry, what do you mean by side-effects?
One of the side effect that popped into my head when I read the original thread:
What if I don't want the carry flag involved in the operation?
|
Mark Pappin
Reged: Nov 01 2004
Posts: 599
Loc: Brisbane, Australia
|
|
Quote:
Quote:
Sorry, what do you mean by side-effects?
What if I don't want the carry flag involved in the operation?
If you're using C, you don't care.
If you care, you're not using C.
--------------------
Mark Pappin - HI-TECH Software
|
John Payson
Reged: Oct 16 2003
Posts: 1133
|
|
Quote:
I'm sure I don't have to point out the number of posts on this forum (let alone submitted to support@htsoft.com) which involve the error messages "Can't find space in..." or "fixup error in..." which are usually caused by not using the bank qualifiers at all/enough or inappropriately.
There should be a storage class to specify, in essence, "put this variable wherever you can find room for it", and an option to make that storage class the default (note that, for the 14-bit PICs, this would require adding a "bank0" storage class). If parts of a program run too slowly, the programmer could explicitly specify the storage classes of variables used in those parts.
On the 14-bit PICs, when speed is important, I don't really see any way around the programmer specifying explicit bank numbers (for non-"wherever" variables), since the banks on those chips are not isomorphic. On the 18-bit PICs, a programmer's concern would generally be having certain variables in the same bank, without regard for which bank that happened to be.
A compiler that manages to arrange variables so that there are only ten bank-switching instructions in the entire program might seem very nice, but if those ten bank-switching instructions end up increasing by 50% the execution time of a time-critical loop that's necessary to shut down a piece of equipment before it overheats, it might not be so nice in practice. I would expect programmers to know far more than the compiler about the things that really matter.
|
lucky
Microchip staff
Reged: Oct 06 2003
Posts: 1184
Loc: Brisbane, Australia
|
|
Development of the PICC PRO compiler continues. Some of the things that you are likely to see in the new compiler are:
- No requirement to use the bank qualifiers (automatic memory allocation over all banks).
- Whole-program (across modules) optimizations
- Automatic pointers (pointers can point anywhere and automatically adjust in size).
- Reduced interupt context save/restore (worst case saves/restores ~5 bytes).
- Re-entrant function support (can call a function from an interrupt & main code)
- Autos/parameters not restricted to bank 0
- Identification of stack overflow and automatic use of jump instructions to avoid stack usage and permit deeper calls.
Want to help?
Sign up to be a beta tester. In the coming weeks we will begin a beta testing period. As a beta tester, you will get access to an early build of PICC PRO. This will give you a chance to trial some of the new features of the compiler and (hopefully) give us some feedback. The first beta will support mid-range (14-bit instruction word) devices.
cheers,
--------------------
Matt Luckman
Microchip Technology Inc.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
