April 2001 - ixp1200 - lists.cs.princeton.edu

RE: [ixp1200] Problem in microcode optimizer
by Heaton, Eric D 30 Apr '01

30 Apr '01

All, This assembler bug is documented in the uca_rel_notes.txt file and in the Release Notes (found in the IXA SDK installation), as well as one additional: o) The optimizer has the following defects: 1. The optimizer will illegally place a P1 stage ctx_arb immediately after a P3 stage branch. 2. The optimizer will incorrectly move +ifsign and +carry ALU operations, changing the instructions from which they get the condition codes. One more <undocumented> optimizer bug concerns using it with the find_bset instruction and indirect shifting: alu[--, shift, b, tmpa] find_bset[search_reg, >>indirect] That is, the optimizer will move the alu statement used as the indirect shift value incorrectly somewhere below the find_bset instruction. Also note that the optimizer does not support is not currently supported for multiple segments (i.e. across the 2k control store), but will be in a future release. Be sure to keep these in mind when using the optimizer in the assembler! Eric Heaton Technical Marketing Engineer Intel Corporation -----Original Message----- From: Alok Kumar [mailto:alok@cs.utexas.edu] Sent: Monday, April 30, 2001 6:28 PM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] Problem in microcode optimizer Hello Everyone, I found a problem in microcode optimizer in the Developer Workbench, so I thought to send it through in the mailing list so that you can turn off the code optimizer is your optomized code has similar problem. The problem is when we use "alu" instruction with operation "+ifsign". Probably, optimizer does not account for the fact the resulf of alu with +ifsign depends on the condition code. For example the following code is optimized incorrectly .local num den res diff alu[num, num, -, den] ; instr 1 alu[--,--, B, num] ; instr 2 alu[res, 1, +IFSIGN, res, <<1] ; instr 3 alu[num, den, +IFSIGN, num] ; instr 4 alu[den, --, B, den, >>1] ; instr 5 alu[diff, diff, -, 1] ; instr 6 br<0[header_stored#] ; instr 7 .endlocal The optimizer expands it as: .local num den res diff alu[l000!num, l000!num, -, l000!den] ; instr 1 alu[--,--, b, l000!num] ; instr 2 alu_shf[l000!res, 1, +ifsign, l000!res, <<1] ; instr 3 alu_shf[l000!diff, l000!diff, -, 1, 0] ; instr 6 br<0[header_stored#], ; instr 7 defer[2] ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu[l000!num, l000!den, +ifsign, l000!num] ; instr 4 ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu_shf[l000!den, --, b, l000!den, >>1] ; instr 5 .endlocal Here semantics of instr 4 changes in optimized code and it works on condition code set by instr 6 instead of condition code set by instr 2 as it should. Using +carry in alu instruction also has similar problem. I think optimizer assumes that alu instruction does not depend on any condition codes. Please, turn off optimizer if you are using +ifsing or +carry. Thanks Alok ____________________________________________________________________________ ___ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok ____________________________________________________________________________ ___

1 0

Problem in microcode optimizer
by Alok Kumar 30 Apr '01

30 Apr '01

Hello Everyone, I found a problem in microcode optimizer in the Developer Workbench, so I thought to send it through in the mailing list so that you can turn off the code optimizer is your optomized code has similar problem. The problem is when we use "alu" instruction with operation "+ifsign". Probably, optimizer does not account for the fact the resulf of alu with +ifsign depends on the condition code. For example the following code is optimized incorrectly .local num den res diff alu[num, num, -, den] ; instr 1 alu[--,--, B, num] ; instr 2 alu[res, 1, +IFSIGN, res, <<1] ; instr 3 alu[num, den, +IFSIGN, num] ; instr 4 alu[den, --, B, den, >>1] ; instr 5 alu[diff, diff, -, 1] ; instr 6 br<0[header_stored#] ; instr 7 .endlocal The optimizer expands it as: .local num den res diff alu[l000!num, l000!num, -, l000!den] ; instr 1 alu[--,--, b, l000!num] ; instr 2 alu_shf[l000!res, 1, +ifsign, l000!res, <<1] ; instr 3 alu_shf[l000!diff, l000!diff, -, 1, 0] ; instr 6 br<0[header_stored#], ; instr 7 defer[2] ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu[l000!num, l000!den, +ifsign, l000!num] ; instr 4 ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu_shf[l000!den, --, b, l000!den, >>1] ; instr 5 .endlocal Here semantics of instr 4 changes in optimized code and it works on condition code set by instr 6 instead of condition code set by instr 2 as it should. Using +carry in alu instruction also has similar problem. I think optimizer assumes that alu instruction does not depend on any condition codes. Please, turn off optimizer if you are using +ifsing or +carry. Thanks Alok _______________________________________________________________________________ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok _______________________________________________________________________________

1 0

Re: Princeton IXP1200 SA Environment
by Scott C. Karlin 29 Apr '01

29 Apr '01

Taroon Mandhana writes: > > On Fri, 13 Apr 2001, Scott C. Karlin wrote: > > > > Hal Rosenstock writes: > > > > > > In the Princeton work with the IXP1200, what environment runs in the > > > StrongArm of the IXP1200 ? Is it vxWorks ? > > > > We run our own code on the StrongARM. We temporarily remove > > the flash memory from the evaluation board (it is socketed), > > and use an external device programmer to get our firmware > > into the device. > > > > The code sets up the board to act as a PCI peripheral so that > > we can plug it into a standard PC. The firmware implements a > > simple protocol which allows the host CPU to download StrongARM > > code to the IXP1200 evaluation board over the PCI bus. We run > > Linux on the Pentium and have our own device driver which > > interacts with the board. > > > > We run an unmodified GCC configured as a cross-compiler to > > compile the StrongARM code. > > Are you running your own OS on strongarm. Or are you running > VxWorks or Linux ? We run our own OS. The OS is currently a library of support routines which are linked with the application to form an executable. Scott

2 1

Princeton IXP1200 SA Environment
by Hal Rosenstock 13 Apr '01

13 Apr '01

Hi, I'm new to the mailing list so you'll have to excuse me for asking a newbee question. In the Princeton work with the IXP1200, what environment runs in the StrongArm of the IXP1200 ? Is it vxWorks ? Thanks. -- Hal Rosenstock

2 1

updated admin info
by Scott C. Karlin 12 Apr '01

12 Apr '01

I have updated the "info" file for the mailing list (see below). The main change to note is that the postings will now have their "reply_to" field set to the list rather than the sender. Scott OVERVIEW -------- The purpose of this list is to facilitate discussion on the topic of the IXP1200 Network Processor including its Ethernet Evaluation System. POSTING MESSAGES ---------------- To send mail to the people on the list, send your ASCII message (not HTML) to ixp1200(a)cs.princeton.edu Note that this list has been setup so that replies go to the entire list. This is to encourage discussion on the list. GUIDELINES ---------- While informative announcements of products or services that benefit most subscribers are allowed, blatant advertising is not. Please do not clutter the archive with HTML messages or attachments. Use plain ASCII text only. (Place code, papers, etc., on a WWW or FTP site and provide a URL reference instead.) UNSUBSCRIBING ------------- See "unsubscribe" in the COMMANDS section below. ARCHIVE ------- All postings to this list are archived by month into files having extensions which represent the year and month of the archives. See "index" and "get" in the COMMANDS section below for access. COMMANDS -------- Majordomo handles the ixp1200 mailing list. To "execute" a command, send mail to majordomo(a)cs.princeton.edu (NOT ixp1200(a)cs.princeton.edu) Include the command in the *body* of the message (the subject line is ignored and may be blank). Commands include: unsubscribe ixp1200 remove yourself from this list index ixp1200 get a list of available archive files get ixp1200 <filename> retrieve an archive file. info ixp1200 get the most current version of this message (works only if you are on the list) who ixp1200 get a list of subscribers to the list (works only if you are on the list) subscribe ixp1200 request to be added to this list (must be approved by the list admin) help general help from Majordomo ADMINSTRATOR ------------ If you have administrative questions or comments about the list, send them to ixp1200-request(a)cs.princeton.edu LAST UPDATED ------------ April 12, 2001

1 0