Reply by Art Johnson September 30, 20022002-09-30
If you are using the SDK Interrupt Dispatcher with a "Normal" or a "Fast"
interrupt, you can free up a lot of the CPU resources if you use a "Super Fast"
interrupt instead. This is one that completely bypasses the SDK Interrupt
Dispatcher. We use "Super Fast" interrupts in a system that has four 115200
baud serial ports (2 on-chip and 2 off-chip), which create an interrupt every
86.8us on each port. Even at this rate, the interrupts use up less than 5% of
the total CPU time, when all ports are active simultaneously. The "Super Fast"
interrupts are described quite well in the Motorola on-line documentation, but
here's a quick description of what is involved.

The most important thing to remember is that all registers used by the interrupt
must be saved on the stack and restored at the end of the interrupt. Also, if
you want use R0 and R1 as general-purpose memory pointers and M01 has been set
for Modulo Arithmetic, you will have to save M01 on the stack, set it to 0xFFFF
for the duration of the interrupt, and restore its value at the end of the
interrupt.

Here's how we use a "Super Fast" interrupt for one of the on-chip serial ports:

In the file "appconfig.h":
// Definitions for the SCI #0 Transmitter Ready interrupt,
// which is vector number 51, and the SCI #0 Receiver
// Full interrupt, which is vector number 53.
//
// These definitions are required so the interrupt vector
// and priority are set by the standard files "vector.c",
// "config.c", and "const.c"
//
#include "sci0_task.h" // To get function prototypes
#define GPR_INT_PRIORITY_53 6
#define INTERRUPT_VECTOR_ADDR_53 Sci0_Task_Rx_Interrupt
#define GPR_INT_PRIORITY_51 5
#define INTERRUPT_VECTOR_ADDR_51 Sci0_Task_Tx_Interrupt

In the file "sci0_task.h":
void Sci0_Task_Rx_Interrupt(void);
void Sci0_Task_Tx_Interrupt(void);

In the file "sci0_task.c":
void Sci0_Task_Rx_Interrupt(void)
{
// Save the registers that are used
asm (lea (sp)+ );
asm (move x0,x:(sp)+ );
asm (move y0,x:(sp)+ );
asm (move r2,x:(sp)+ );
asm (move r3,x:(sp) );

.
. (process the interrupt)
.

// Restore the registers that are used
asm (pop r3 );
asm (pop r2 );
asm (pop y0 );
asm (pop x0 );
asm (rti );
}

void Sci0_Task_Tx_Interrupt(void)
{
// Save the registers that are used
asm (lea (sp)+ );
asm (move x0,x:(sp)+ );
asm (move y0,x:(sp)+ );
asm (move r2,x:(sp)+ );
asm (move r3,x:(sp) );

.
. (process the interrupt)
.

// Restore the registers that are used
asm (pop r3 );
asm (pop r2 );
asm (pop y0 );
asm (pop x0 );
asm (rti );
} I hope this information is useful for you.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

-----Original Message-----
From: Christian Brauchli [mailto:]
Sent: Monday, September 30, 2002 10:02 AM
To: Art Johnson;
Subject: RE: [motoroladsp] Compiler efficiency article Hi,

I can also confirm what Art is talking about. The compiler is quite
inefficient. While doing the prototying of a motion Control Application we
used C-Programming language. Our Interrupt service routine which has been
called each 33us used about 30us(C-Code)(just about 3us or 10% for doing
other things) . So the processor 56807 was at the limit. While translating
the C-Code into Assembly (manually) we could reduce the 30us runtime down to
14us(so we have now more than 57% of available ressources). So the Code made
by hand was at least twice as fast as the C-Code.

We started using this processor in March 2001 and we have a lot of
experience with the processor and Code-Warrier IDE. There are many bugs in
the compiler. Usually if the C-Code is not running we check for the assembly
code and implement a work-arround.

rgds
Chris Brauchli
Head of Software Development Dep.

__________________________________
BRAUCHLI NETSOLUTION BERG
Bahnhofstrasse 7
CH- 8572 Berg
Switzerland
Tel. +41/ 71 / 638 00 45
Fax. +41/ 71 / 638 00 46
Mob. +41/ 78 / 616 22 14
email.
www.brauchli-netsolution.ch
__________________________________ -----Original Message-----
From: Art Johnson [mailto:]
Sent: Montag, 30. September 2002 16:04
To:
Subject: [motoroladsp] Compiler efficiency article Hi,

I thought you might be interested in reading this article about the
efficiency of modern compilers, especially when they're used with DSP chips.
As you know, in my opinion the CodeWarrior 56800 compiler is extremely
inefficient at generating object code, compared to the best that can be done
manually. I reported this to Metrowerks (SR Number: 1-13810245 -- Suggested
improvement in the compiler), and they say that the 56800E compiler has this
fixed already, but they're not sure when it will be fixed in the 56800
tools.

Please follow this link:
http://www.electronicstimes.com/story/OEG20020516S0032

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/


Reply by Christian Brauchli September 30, 20022002-09-30
Hi,

I can also confirm what Art is talking about. The compiler is quite
inefficient. While doing the prototying of a motion Control Application we
used C-Programming language. Our Interrupt service routine which has been
called each 33us used about 30us(C-Code)(just about 3us or 10% for doing
other things) . So the processor 56807 was at the limit. While translating
the C-Code into Assembly (manually) we could reduce the 30us runtime down to
14us(so we have now more than 57% of available ressources). So the Code made
by hand was at least twice as fast as the C-Code.

We started using this processor in March 2001 and we have a lot of
experience with the processor and Code-Warrier IDE. There are many bugs in
the compiler. Usually if the C-Code is not running we check for the assembly
code and implement a work-arround.

rgds
Chris Brauchli
Head of Software Development Dep.

__________________________________
BRAUCHLI NETSOLUTION BERG
Bahnhofstrasse 7
CH- 8572 Berg
Switzerland
Tel. +41/ 71 / 638 00 45
Fax. +41/ 71 / 638 00 46
Mob. +41/ 78 / 616 22 14
email.
www.brauchli-netsolution.ch
__________________________________ -----Original Message-----
From: Art Johnson [mailto:]
Sent: Montag, 30. September 2002 16:04
To:
Subject: [motoroladsp] Compiler efficiency article Hi,

I thought you might be interested in reading this article about the
efficiency of modern compilers, especially when they're used with DSP chips.
As you know, in my opinion the CodeWarrior 56800 compiler is extremely
inefficient at generating object code, compared to the best that can be done
manually. I reported this to Metrowerks (SR Number: 1-13810245 -- Suggested
improvement in the compiler), and they say that the 56800E compiler has this
fixed already, but they're not sure when it will be fixed in the 56800
tools.

Please follow this link:
http://www.electronicstimes.com/story/OEG20020516S0032

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com
_____________________________________
Note: If you do a simple "reply" with your email client, only the author of
this message will receive your answer. You need to do a "reply all" if you
want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/


Reply by gcoonley September 30, 20022002-09-30
Hi,

I thought I would chime in concerning the compiler
efficiency. We have ported our Networking stack to
run on the 800E EVM boards with our Ethernet Daughter
card. Unfortunately due to optimizer issues we are
not able to turn on the optimizer for our current
release. However, to give them a little credit
with the optimizer off our Networking stack is
about 30% larger than our corresponding ARM port.
They have cleaned up most of the optimizer issues on the
upcoming 2.0 release for the 800E. So we will see
how well they do compared to ARM. So only time will
tell if they get it correct with the 800E.

Regards
Greg
----------------
Greg Coonley
DSP OS, Inc.
327 Dahlonega Rd Suite 1801-A
Cumming, GA 30040
Phone: 678-208-2250
Fax: 678-208-2254
e-mail:
URL: www.dspos.com
----------------
--- In motoroladsp@y..., "Art Johnson" <art@p...> wrote:
> Hi,
>
> I thought you might be interested in reading this article about the
efficiency of modern compilers, especially when they're used with DSP
chips. As you know, in my opinion the CodeWarrior 56800 compiler is
extremely inefficient at generating object code, compared to the best
that can be done manually. I reported this to Metrowerks (SR Number:
1-13810245 -- Suggested improvement in the compiler), and they say
that the 56800E compiler has this fixed already, but they're not sure
when it will be fixed in the 56800 tools.
>
> Please follow this link:
> http://www.electronicstimes.com/story/OEG20020516S0032
>
> Regards,
>
> Art Johnson
> Senior Systems Analyst
> PMC Prime Mover Controls Inc.
> 3600 Gilmore Way
> Burnaby, B.C., Canada
> V5G 4R8
> Phone: 604 433-4644
> FAX: 604 433-5570
> Email: art@p...
> http://www.pmc-controls.com


Reply by Art Johnson September 30, 20022002-09-30
Hi,

I thought you might be interested in reading this article about the efficiency
of modern compilers, especially when they're used with DSP chips. As you know,
in my opinion the CodeWarrior 56800 compiler is extremely inefficient at
generating object code, compared to the best that can be done manually. I
reported this to Metrowerks (SR Number: 1-13810245 -- Suggested improvement in
the compiler), and they say that the 56800E compiler has this fixed already, but
they're not sure when it will be fixed in the 56800 tools.

Please follow this link:
http://www.electronicstimes.com/story/OEG20020516S0032

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com