> From: Dale Johannesen [mailto:[EMAIL PROTECTED] > > On Jul 21, 2005, at 5:04 PM, Tabony, Charles wrote: > > >> From: Dale Johannesen [mailto:[EMAIL PROTECTED] > >> > >> On Jul 21, 2005, at 4:36 PM, Tabony, Charles wrote: > >> > >>> Hi, > >>> > >>> I am working on a port for a processor that has 32 bit > registers but > >>> can > >>> only load 16 bit immediates. > >>> "" > >>> "%0.h = #HI(%1)") > >> > >> What are the semantics of this? Low bits zeroed, or untouched? > >> If the former, your semantics are identical to Sparc; look at that. > > > > The low bits are untouched. However, I would expect the compiler to > > always follow setting the high bits with setting the low bits. > > OK, if you're willing to accept that limitation (your > architecture could > handle putting the LO first, which Sparc can't) then Sparc is still a > good model to look at. What it does should work for you.
Earlier I was able to successfully split load immediates into high and lo_sum insns, and that has worked great as far as scheduling. However, I noticed that now instead of loading the address of a constant such as a string, compiled programs will load the address of a constant that is the address of that string and then dereference it. My guess is that this is caused by the constant in the high/lo_sum pair being hidden from CSE. I looked at the way SPARC and MIPS handle the problem, but I don't think that will work for me. If I understand correctly, they split the move into a load immediate that has the lower bits cleared, corresponding to a sethi or lui instruction, and an ior immediate. The semantics of the instructions I am working with, "R0.H = #HI(CONSTANT)" and "R0.L = #LO(CONSTANT)" are that the half of the register not being set is unmodified. Since I can not use an ior immediate like SPARC and MIPS, how can I split move immediate insns so that they can be effeciently scheduled but still eliminate the unnecessary indirection? Also, does the method used by SPARC and MIPS work for symbols? Thank you, Charles
