[ixp1200] Running IXP sample code in Unoptimized mode

[Deepa Srinivasan]

I saw another variant of this problem (reported by Francis Chang for the the
example in Chapter 5 of the IXP book).  When run in unoptmized mode, the
compiler generates the following code (My comments start with //*** )

For:
buf_handle = receive_packet(0, 5, &cur_pkt_len);

Code generated:
/******/   buf_handle = receive_packet(0, 5, &cur_pkt_len);
    l_8#:
immed[port_num_96_V$bc$2$5:a4, 0, <<0]        //*** USES SAME REGISTER a4
immed[rfifo_num_96_V$bd$2$5:a4, 5, <<0]        //*** USES SAME REGISTER a4
br[_receive_packet#], defer[1]
load_addr[a2, l_55#]
------------------
The same register is being used for both the in parameters.
-----------------

If I change the function receive_packet to use temporary variables:

buffer_handle_t receive_packet( unsigned int port_num ,
        unsigned int rfifo_num ,
        unsigned int *pkt_length)
{
 unsigned int a = 0, b = 0;        //*** temp variables
 rcv_state_t rcv_state = { 0 };
 rcv_cntl_reg_t rcv_control;
 __declspec(sdram) void *buf_data_ptr;

 a = port_num; //*** temp variables
 b = rfifo_num; //*** temp variables

 do
 {
  rcv_control = get_mpacket(a, b); //*** use temp variables instead of
original code:  rcv_control = get_mpacket(port_num, rfifo_num); ***
...
...
}
-------------
This produces the following code:

immed[port_num_96_V$bc$2$5:a0, 0, <<0]    //*** USES different register a0
***
immed[rfifo_num_96_V$bd$2$5:a4, 5, <<0]    //*** USES different register a4
***
br[_receive_packet#], defer[1]
load_addr[b3, l_55#]
/******/   scratch_incr(cntr, no_signal);
    l_55#:
scratch[incr, --, cntr_105$2$4:b0, 0, 1], no_signal
/******/   *byte_count += cur_pkt_len;

scratch[read, $0, byte_count_105$2$4:a2, 0, 1], ctx_swap
sram[read, $1, pkt_length_96_V$be$2$5:b3, 0, 1], ctx_swap
.....
.....

----------------
On return from the function call, the value of cntr is overwritten by code
within the function (that writes the out value pkt_lenth to the same
register b0). I can send more detailed code if required. Is there a
workaround/fix for this, (where the registers do not get corrupted in Debug
mode)?

Thanks,
Deepa


From: "Francis" <francis at francischang.com>
To: <ixp1200 at CS.Princeton.EDU>
Subject: [ixp1200] IXA SDK Bug
Date: Mon, 12 Aug 2002 07:58:52 -0700

There seems to be a bug in the uEngine C Compiler, when run in unoptimized
mode. I was wondering if anyone's seen this behaviour before, and if they
can suggest work-arounds.

One of the sample IXA applications (single-threaded-packet counter) I'm
looking at exhibits this bug. It works on the "optimize for speed" settings,
but when I put it into the non-optimized mode, it generates questionable
micro-engine assembly output.

The compiler seems to want to use GPR a0 to store both a pointer into
scratch memory, as well as function return address. Predictably, this causes
problems :)

This behaviour is consistent in the Intel IXA Software Developers Kit for
IXP1200, versions 2.0, 2.01 and 2.01a.

--
Francis