-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I am observing a weird behavior when trying to read / write
some registers from the Linux kernel running on the StrongARM.
Basically, it seems I can write some registers like IREG without
any problem from the StrongARM. However it seems I cannot with
RDYBUS_TEMPLATE_CTL. However both registers are described in the doc
as being r/w accessible by the StrongARM.
Below is the output of my program.
I am using the following definition for RDYBUS_TEMPLATE_CTL
(IREG being already defined in the includes files):
#define MY_RDYBUS_TEMPLATE_CTL
IXP1200_REG(MICROENGINE_FBI_BASE+0x40180)
[root@thing1 Didier]$./set_rcv
Initial value of RDYBUS_TEMPLATE_CTL Register: 0
Initial value of IREG Register: 0
Address of RDYBUS_TEMPLATE_CTL Register: f0640180
Address of IREG Register: f06401e0
New value of RDYBUS_TEMPLATE_CTL Register: 0
New value of IREG Register: 80000000
Thanks in advance for any help.
Regards, Didier.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOvMOAHqEbTtUcuwQEQIARACeIhs42jMRRCCpV/1n4zKktqZenyQAoKKp
1KiT9hDkijWgnLVYRmz1B/g4
=sb4r
-----END PGP SIGNATURE-----
Hi Eric
You should also post this to the internal mailing group so that all the
internal folks will also know about these features...
-----Original Message-----
From: Heaton, Eric D [mailto:eric.d.heaton@intel.com]
Sent: Monday, April 30, 2001 6:57 PM
To: 'ixp1200(a)CS.Princeton.EDU'
Subject: RE: [ixp1200] Problem in microcode optimizer
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
____________________________________________________________________________
___
