August 2002 - ixp1200 - lists.cs.princeton.edu

Running IXP sample code in Unoptimized mode
by Deepa Srinivasan 04 Sep '02

04 Sep '02

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(a)francischang.com> To: <ixp1200(a)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

2 1

SDK2.01 on Linux 2.4.x kernel
by Ravi modgekar 31 Aug '02

31 Aug '02

Hi, Just out of curiosity ...I would like to know if we can use INTEL IXP1200 SDK 2.01 with Linux kernel version 2.4.x on Boston Harbour. Thanks in Advance Ravi --------------------------------- Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes

1 0

RE: [ixp1200] problem with the simuator
by Kunze, Aaron 29 Aug '02

29 Aug '02

Hey! Try setting the hash multiplier in the FBI CSRs. If the multiplier is 0, the hash unit will return 0. A ------------------------ Aaron Kunze Intel Labs aaron.kunze(a)intel.com -PGP Key ID: 0x81124B7C- -NOT SPEAKING FOR INTEL- ------GO BOILERS!!------ > -----Original Message----- > From: damien [mailto:damien@cse.ogi.edu] > Sent: Thursday, August 29, 2002 4:54 PM > To: ixp > Subject: [ixp1200] problem with the simuator > > > Hi all, > I'm trying to use the developer workbench > to simulate the hash unit. > My problem is the function hash_64() always returns 0... > Could someone please tell me what's wrong in the following code: > > / long long data_to_hash = 0x1234567899; > __declspec(sram_write_reg) long long hash_Input; > __declspec(sram_read_reg) long long hash_Output; > long long result; > > while(1) > { > if(ctx() == 0) > { > hash_Input = data_to_hash; > hash_64((__declspec(sram_write_reg) void *)&hash_Input, > (__declspec(sram_read_reg) void *)&hash_Output, 1, sig_done); > ctx_wait(fbi); > result = hash_Output; > > } > else > { > ctx_wait(voluntary); > } > }/ > > --Damien >

2 1

problem with the simuator
by damien 29 Aug '02

29 Aug '02

Hi all, I'm trying to use the developer workbench to simulate the hash unit. My problem is the function hash_64() always returns 0... Could someone please tell me what's wrong in the following code: / long long data_to_hash = 0x1234567899; __declspec(sram_write_reg) long long hash_Input; __declspec(sram_read_reg) long long hash_Output; long long result; while(1) { if(ctx() == 0) { hash_Input = data_to_hash; hash_64((__declspec(sram_write_reg) void *)&hash_Input, (__declspec(sram_read_reg) void *)&hash_Output, 1, sig_done); ctx_wait(fbi); result = hash_Output; } else { ctx_wait(voluntary); } }/ --Damien

1 0

RE: [ixp1200] ixp1200 absolute register programming problem
by Johnson, Erik J 23 Aug '02

23 Aug '02

The problem is not in the compiler, the problem is that an absolute register is not allowed with either a shift specifier (alu_shf) or an immediate operand. So the real problem is with the 1. The documentation is misleading, but if you read after the example in the alu[] instruction documentation, this restriction is hinted at. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson Intel Research & Development erik.j.johnson(a)intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: xtan@mail [mailto:xtan@csnet1.cs.tsinghua.edu.cn] Sent: Thursday, August 22, 2002 6:27 PM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] ixp1200 absolute register programming problem Hello everybody: Here is an absolute register programming problem that I encountered with IXP1200 C (asm) compiler. The detail code goes here: __declspec(shared gp_reg) a; void main() { __asm alu[a, 1, +, a]; } The compiler will report an error: (0): error : #0: Inst has bad operands (d:\cvs\uc\ixp1200\uEngineC\pdev\ixp_cg\ixpasm.c, line 2109) While the IXP programming guide said the B operand and the dest_reg could use absolute register leaving A operand a immediate data. Is there anything wrong with my syntax or it is just a compiler bug? Besides, using global absolute register is convenient in the communications between threads, but this failure will lead to an exaggerate code generation which dramatically decrease the performance. I will very appreciate if anyone could help me. Zhanxi Tan Dep. of CS Tsinghua Univ.

1 0

ixp1200 absolute register programming problem
by xtan＠mail 22 Aug '02

22 Aug '02

Hello everybody: Here is an absolute register programming problem that I encountered with IXP1200 C (asm) compiler. The detail code goes here: __declspec(shared gp_reg) a; void main() { __asm alu[a, 1, +, a]; } The compiler will report an error: (0): error : #0: Inst has bad operands (d:\cvs\uc\ixp1200\uEngineC\pdev\ixp_cg\ixpasm.c, line 2109) While the IXP programming guide said the B operand and the dest_reg could use absolute register leaving A operand a immediate data. Is there anything wrong with my syntax or it is just a compiler bug? Besides, using global absolute register is convenient in the communications between threads, but this failure will lead to an exaggerate code generation which dramatically decrease the performance. I will very appreciate if anyone could help me. Zhanxi Tan Dep. of CS Tsinghua Univ.

1 0

Optimization
by Vaishnavi Krishnamurthy 22 Aug '02

22 Aug '02

Hi Francis, I have had the same problem as you..when optimized for size or speed there are no errors but when the program is made to run without any optimization it gives some error. Is there any way to remove these errors? Please let me know. Thanks, vaish.

3 4

Booting ENP-2505 IXP1200 Board
by Jo Ueyama 21 Aug '02

21 Aug '02

All, I am trying to boot the IXP1200 board but I simply can not do it, since the 'bootixp' script calls minicom program and then it gets stuck. Likewise, a message appears on the screen saying that minicom has not found the configuration file. Can anyone please tell me how to solve this problem? Thanks a lot! Regards, Jo Ueyama

3 2

Wrong results in Workbench
by Tommy Tran 16 Aug '02

16 Aug '02

Hi all, have problem running the l3fwdr app in workbench mode. The board kept dumping packats to all 4 of its ports and cause the host linux box to crash soon after. Here is the content of the packats captured by tcpdump: 15:33:08.562578 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 15:33:08.572013 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 15:33:08.619845 0:0:0:0:0:0 1:80:c2:0:0:1 8808 60: 0001 0f01 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ...

1 1

Gerry Murphy/Radisys_Corporation/US is out of the office.
by Gerry.Murphy＠radisys.com 16 Aug '02

16 Aug '02

I will be out of the office starting 08/14/2002 and will not return until 09/02/2002. I will respond to your message when I return.

1 0