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 …
[View More]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
____________________________________________________________________________
___
[View Less]
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,…
[View More] 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
_______________________________________________________________________________
[View Less]
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
…
[View More]> > 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
[View Less]
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
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)…
[View More]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
[View Less]
