I thought about that too, although probably not enough. This comes down to statistics and a complex set of probabilities relating to positive and negative integers in certain ranges and positive and negative floats versus certain exponent values. That is, it's not really more complex once it's hidden by the compiler; this only affects the probability of generating a second instruction. But to prevent us from going crazy right now, I'm going to make it set the high bit to zero.
Also, I'm going to stipulate that the immediate logicals leave the high 16 bits UNAFFECTED. On Sun, Apr 21, 2013 at 4:39 AM, Chris Matrakidis <[email protected]>wrote: > On Sun, Apr 21, 2013 at 4:57 AM, Timothy Normand Miller <[email protected] > > wrote: > >> BTW, I've changed some of the opcodes: >> http://www.cs.binghamton.edu/~millerti/ins-formats4.pdf >> > > I don't understand the reasoning behind this change: "The LL instruction > loads a 31-bit immediate into R1. The number IS sign-extended!" If the > immediate is sign extended, then it complicates loading floating point > constants, which I understood was the main use case for this opcode. > > Best Regards, > > Chris Matrakidis > -- Timothy Normand Miller, PhD Assistant Professor of Computer Science, Binghamton University http://www.cs.binghamton.edu/~millerti/ Open Graphics Project
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
