| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Not yet necessary, but in case each of the threads
is allowed to initiate an atomic, will come in handy
|
|
|
|
don't allow enquing from other threads if servicing and atomic for a thread
|
|
|
|
|
|
|
|
|
|
|
|
|
|
implementation.
|
|
|
|
|
|
|
|
|
|
CMOVcc.
The manuals from both AMD and Intel say that when writing to a 32 bit
destination in 64 bit mode, the upper 32 bits of the register are filled with
zeros. They also both say that the CMOV instructions leave their destination
alone when their condition fails. Unfortunately, it seems that CMOV will zero
extend its destination register whether or not it was supposed to actually do
a move on both platforms. This seems to be the only case where this happens,
but it would be hard to say for sure.
|
|
|
|
|
|
|
|
This is my best guess as far as what these should do. Other existing microops
use implicit registers, mul1s and mul1u for instance, so this should be ok.
The microop that loads the implicit DoubleBits register would fall into one
of the microop slots for moving to/from special registers.
|
|
operations zero extend.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These changes allow to run Ruby-gems multiple times from the same
ruby-lang script with different configurations
|
|
|
|
|
|
|
|
|
|
|
|
Register values will be "picked" which will assure they don't have junk beyond
the part we're using. Immediate values don't go through a similar process, so
we should truncate them explicitly.
|
|
|
|
|
|
|
|
|
|
or more.
|
|
|
|
or more.
|
|
|
|
|
|
|
|
|
