Amber ARM-compatible core

The following code

  // set the carry up
  MOV  R1,#0xFFFFFFFF
  ADDS R1,R1,#1
  // do the test
  MOV  R1,#0x00800000
  TST  R1,#0x00FF0000
  MOVCC R0,#0
  MOVCS R0,#1

After this code executes on amber R0 is 1 After this code executes on a real arm R0 is 0

Also verified on ARM3,Armulator, ARM610 and StrongARM.

I have however modified my version of Amber heavily but this seems to originate in the barrel shifter which i havent touched. I am using the non-FPGA version of the barrel shifter and i havent tried the FPGA version yet.

I've run a slightly different sample code set using the BBC Basic ARM assembler on an Acorn A540 (admittedly with an ARM3 + FPA but that shouldnt make a difference in this case) and my FPGA setup running the same operating system and code.

This is the A540 output.. notice it prints a zero a the end.

https://www.dropbox.com/s/b2ufyc240k6wgru/A540.JPG?dl=0

This is the Amber output.. notice it prints a one at the end.

https://www.dropbox.com/s/jl95aodt0qbhexr/amber.jpg?dl=0

PRINT USR code% basically prints the value of R0 after the code has completed.

I have a theory that TST with a large immediate operand could put the barrel shifter into an unexpected / odd state.

I'll try and produce a VCD of this.

Sample vcd file running the same code as in the photos above.

https://www.dropbox.com/s/09tmr9oexgvujth/amber.vcd?dl=0

I think i know whats wrong.

The code that works out the immediate operands in a23_decode

assign imm32_nxt = ...

etc, would on a real arm be done by the barrel_shifter and would set the flags. Looks like this is just a really odd edge case thats missing. I propose doing something to set the carry for those immediate instructions.

The list will be fixed.

Fixed in release 83