Documentation on MOVTS/MOVFS encoding

[alexrp]

It is not documented how the various registers should be encoded for these instructions. It's self-explanatory for the GPRs since they're just sequentially numbered, but not so for system registers.

[timpart]

If you take a look in the source at src/cpu/epiphany.cpu and search for MOVFS you will quickly find a numbered register list. I haven't verified it is right, but it looks plausible.

Tim

[alexrp]

Yeah, I can trial-and-error my way too. I'd just like to have this properly documented so others won't have to.

[alexrp]

@aolofsson can you chime in here? Thanks!

[aolofsson]

Sorry for the slow reply. The way it works is by only taking appropriate offset into the memory mapped address (as given in the register summary of the arch ref manual). So for example, CONFIG would be register 0, STATUS would be register #1, PC would be register #2, etc)

[alexrp]

OK, so I'm looking in Appendix B. There seems to be some gaps in the documented registers:

* What's at 0xF0410? Between DEBUGSTATUS and LC.
* What's at 0xF0444? Between FSTATUS and DEBUGCMD.
* What's at 0xF044C to 0xF0500? Between DEBUGCMD and the first DMA register, DMA0CONFIG.
* What's at 0xF0540 to 0xF0604? Between the last DMA register, DMA1STATUS, and MEMSTATUS.
* What's at 0xF060C to 0xF0700? Between MEMPROTECT and MESHCONFIG.
* What's at 0xF071C to 0xF07FF? Between RMESHROUTE and the end of the memory-mapped registers bank.

(Hopefully I got those right...)

Somewhat more tangentially: What happens if the program attempts to write to an RD register, or read from a WR register?

[aolofsson]

Any register address locations that are not documented in the manual are either empty or filled with experimental registers that should be left alone. Reading from unmapped locations or WR only registers will return garbage or all zeroes,depending on how the logic was implemented. (undefined).

Andreas

[alexrp]

OK, so what happens if an instruction refers to an undocumented/unmapped/experimental register? Undefined behavior? Or at least implementation-defined?

Is writing to an RD register also undefined?

[aolofsson]

In general, anything that is not written in the reference manual would create an undefined behavior. Hopefully there is a way to flag this in your simulator? When it comes to exact hardware behavior, I can only give you the my interpretation based on reviewing code that I wrote 4 years ago.

In general, writing to RD only registers or to unmapped locations will case the write to "not happen", but there may be certain locations that would cause strange behavior. Our verification environment did not test anything that was outside of the spec. In terms of undocumented experimental features, there are still a few of those left, but we want to test them properly before putting them into the etched in stone reference manual.

Does anyone volunteer to be an "alpha tester" for these experimental features?

Andreas

btw. One correction on the the local memory access. Any read/write access to location between 32KB to 1MB is aliased back to the first 32K. Please don't write programs that rely on this feature!

[alexrp]

Yeah, eventually I'll make my simulator capable of reading DWARF debug info and handing the developer a stack trace of where some kind of undefined behavior occurred. Right now it just logs a debug warning with the PC and the decoded instruction.

I'll just treat writes to RD registers and reads from WR registers as undefined, too, then.

Once I get a board, I'll be happy to play around with alpha-quality features.

On the subject of testing, do you guys have some kind of conformance suite that one could run against a simulator and real hardware to compare?

Thanks for the info as usual!