On Tuesday 18 May 2010 16:44:24 Philip Pemberton wrote:
> I'm not using the Milkymist hardware

Why not? You don't need a big FPGA for that, a small version works on the $39 
Avnet Spartan 3A devkit: http://github.com/fallen/milkymist-avnet

>  > Did you have a look at the disassembly?
> 
> OK, maybe it isn't a compiler bug:
>    18:        78 0b 40 00     mvhi r11,0x4000
>    1c:        78 0e 40 00     mvhi r14,0x4000
>    20:        b9 60 08 00     mv r1,r11
>    24:        b9 c0 10 00     mv r2,r14
>    28:        38 21 00 00     ori r1,r1,0x0
>    2c:        38 42 01 00     ori r2,r2,0x100
>    30:        58 21 00 00     sw (r1+0),r1
>    34:        34 21 00 04     addi r1,r1,4
>    38:        5c 22 ff fe     bne r1,r2,30 <memtest+0x30>
> 
> So it's generating the correct code for the RAM test, but for some
> reason the code isn't executing properly...

You can use QEMU and GDB to debug those problems (this one and the hexadecimal 
print error). They make the job A LOT easier.
What do you mean with "not executing properly"? SDRAM controllers are often a 
lot of trouble and I would not be surprised that this execution problem simply 
stems from your SDRAM controller not working.

> It's not just that lm32-gcc is bad, it's that:
>    - the cache apparently doesn't work when the LM32 is synthesized for
> Xilinx targets (or using the Xilinx synthesizer)

Again, that's a Xst problem, not a LM32 problem. The cache works correctly on 
Xilinx targets e.g. when using the Synplify synthesizer.
If this blocks you, it seems older versions of LM32 (like the one in Joerg 
Bornschein's soc-lm32) didn't tickle this bug. Xilinx is also not the only 
option, Lattice's tools are based on Synplify and Altera's tools are less 
buggy than Xst. Somebody ported parts of Milkymist to the Altera DE2 board and 
did not encounter significant problems.

>    - the sign-extender won't enable on Xst  -- you can uncomment the 
> `define, but the CCR still reports that the SX isn't present.

Hmm... true. Checking that out, I found out it's just a documentation error. 
The positions of the X and U bits are reversed. The LM32 source code reads:
assign cfg = {
              `LM32_REVISION,
(...)
`ifdef CFG_USER_ENABLED
              `TRUE,
`else
              `FALSE,
`endif
`ifdef CFG_SIGN_EXTEND_ENABLED
              `TRUE,
`else
              `FALSE,
`endif
`ifdef LM32_BARREL_SHIFT_ENABLED
              `TRUE,
`else
              `FALSE,
`endif
(...)
};
Furthermore, the "U" bit means that the CPU support user instructions (the 
documentation says it's "reserved").
Nonetheless, the sign extender does work when enabled.

> > Did you have a look at LLVM?
> 
> I wasn't aware that LLVM had an LM32 backend...

It doesn't, but the documentation to write one is there and the code is not an 
horrible mess (contrary to GCC). Doing so would be an interesting move forward 
instead of complaining about GCC's brokenness.

Sébastien
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkym...@freenode
Webchat: www.milkymist.org/irc.html
Wiki: www.milkymist.org/wiki

Reply via email to