Ok, here's the updated ISA doc: http://www.cs.binghamton.edu/~millerti/ins-formats4b.pdf
The integer MULs (high, low, etc.) aren't yet implemented correctly. On Sun, Apr 21, 2013 at 1:47 PM, Timothy Normand Miller <[email protected]>wrote: > 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 > -- 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)
