In the attachment is a screenshot of the description of the ORI instruction taken from "Nios II Processor Reference Guide Updated for Intel ® Quartus ® Prime Design Suite: 19.4", page 217. Notice where the IMM16 field is located.
Here is a an ORI instruction the .objump file from my first test program:
ori gp, gp, %lo(_gp)
2c: 8000d694 ori gp,gp,32768.
Here is the matching line from the .hex file created by elf2hex with the instruction in bold (32-bit hex file, so the instruction is at 0x2c/4=11):
:200008000005D8340000DED40004D0348000D694000410340000109400041834001018D4EB
Clearly the instruction set reference and the .hex file do not match. The IMM16 field in the .hex file is the most significant two bytes of the word. The instruction set reference shows it in the middle of the word.
I'm using Quartus 18.1, not 19.x, but I can't believe the instruction format would be changed like that.
The reason I asked was that I could not get Platform Designer+Quartus to initialize the program ROM from the .hex file. I thought I might have to hand assemble some code to get the NIOS to do something. I did not not know which to believe because the .hex did not match the documentation. I was afraid I had some option wrong in the EDS resulting in a bad .hex file.
I've since discovered what I believe to be a file caching problem in PD+Quartus that prevented my .hex file from being incorporated into the SOF file, but that's a separate issue. I have a workaround, so I finally got a very simple program running using the .hex file above. Now it's just a curiosity why the documentation does not agree with the compiler output.
Thanks,
Larry