Amber ARM-compatible core

The following instruction

STRT R1,R9,#0

Is excecuted as though it was

STR R1,R9,#0

Similarly for LDRT.

I would expect this to drop the CPU core into User mode for the duration of the instruction which doesn't happen. I'm guessing this is because the core doesnt have a wishbone compliant way of announcing what mode the CPU is in during a memory cycle. This should also be added.

This prevents Amber from passing hardware tests in some systems. I'm guessing you wont fix this but there should be a record of it.

LDRT and STRT are part of the ARM v4 ISR. Amber supports the v2a ISR.

mean ISA, not ISR

???

They are in the ARM 1 instruction set manual.

http://www.chiark.greenend.org.uk/~theom/riscos/docs/ARM3-datasheet_ARM-Family-Data-Manual-VLSI.pdf

See pages 3-25 3-27.

The instructions are used in RISC OS 0.1 right up to modern 5.20.

The instruction is defined at the top of page 3-27.

The !ObjAsm & AsAsm assemblers will compile the instruction opcode for v2a.

Sorry that was the ARM 3 link. For the ARM2 its on page 2-38 and 2-39. ISBN 0-13-781618-9

http://maben.homeip.net/static/S100/acorn/hardware/ARM%20Family%20Data%20manual%201990.pdf

Conor, if you arent going to fix any bugs on this CPU core i'll be forced to fork it.

OK to be precise address translation is not part of the CPU core in v2a. It is an optional external component which is not supported in the Amber project. In the v4 ISA there is an MMU in the core which handles the address translation, making the function a requirement to any complete implementation.

Some general comments about the tone of this bug report. This is an open source project. The concept of open source is that users contribute back to the code base to fix bugs and grow its usefulness. It is not a commercial product with paid support. Bug reports demanding fixes or else are unlikely to be successful.

Users are free to fork the project, as long as they follow the open source license terms.

The best way to submit a bug report is to create a complete assembly test in the same style as the tests in the hw/tests directory, which fails because of the bug, and only for that reason. That way other users can easily reproduce the bug, fix the issue and submit a patch.

Fine Conor,

I wont contribute any more feedback to you as it is clearly not welcome. Let me know when you get over your own ego and i'll help you again.