Closed meklort closed 9 years ago
the example should have been; .extAuxRegister rom_version, 65530, r|w sr 1024, [%rom_version]
Note: I did modify the negative check to remove it for the .extAuxRegister case
Hi meklort,
Thanks for the report. I've assigned to Joern Rennecke (amylaar) to take a look at this.
Jeremy
Hi meklort,
I've exchanged email with Joern Rennecke and Claudiu Zissulescu about this.
Architecturally, ARCompact can address a 32 bit auxiliary register address space, by using register indirect or LIMM addressing. However implementations usually restrict themselves to 12-bit addresses, since such addresses can be encoded in a 32 bit instruction word. That's more efficient when you want to use absolute addressing (which is quite common for auxiliary registers). This is probably why no one has found this problem before.
Is lack of 32-bit support causing you an actual problem at present?
Thanks for bringing this to our attention, and of course if you have a patch we'd be interested to see it!
Best wishes,
Jeremy
HI Jeremy,
Yes, this is an issue for us. We are using the AUX address space in our design. As per Synopsys's suggestion, the extension aux registers are located between -2048 and -1 to ensure that we use the LIMM /register indirect adressing scheme
Some sample code showing this problem (partially posted above):
Note: VERSION is defined by teh build script.
.extAuxRegister rom_version, 0xFFFFF853, r|w
_start: sr VERSION, [%rom_version]
We can instead change this to the following sr VERSION, [-1965] and this will compile (and work properly), however I'd prefer not to change away from symbolic names, especially since everything compiles fine with the full metaware suite
Hi Meklort,
Thanks for this. I've put the information in to the Synopsys system, but I suggest you also draw your account manager's attention to the issue.
Jeremy
Thanks. I've just opened an issue in solvnet and pointed it here.
I'm assuming this issue was handled long ago over Solvnet and closing. Please open new issue if still facing problems. Thanks.
in tc-arc.c, there is a check to make sure that the address is non zero for all three opertypes classes, this check is not valid for opertype == 2
number = get_absolute_expression (); if (number < 0) { as_bad ("negative operand number %d", number); ignore_rest_of_line (); free (name); return; }
Note: Later on in this function, the following assignment is made: ext_oper->operand.value = number;
operand.value is defined as a short, however we need operand.value as a 32bit value to fit the complete 32bit aux address space.
Also note that when a large aux value is specified, the emitted assembly is incorrect. Specifying an AUX register at address 65530 result in the following output asm: sr 1024, [65530] hex: 0x27ffffff Note: This is not the sr opcode.
Also note, this is with compiling for the ARCv2EM