Richard Henderson writes:
That's odd. I just booted a fedora installer and ran it part way
through. Long enough that I'm well past a "no bootable device" message
from the bios.
There were changes to my tree since the last push, but as far as I
remember they were cleanups to powerpc
On 02/20/2013 01:02 AM, Torbjorn Granlund wrote:
> I then tried something that you might consider more plain:
>
> qemu-system-x86_64 -m 512 -cpu Haswell,+adx \
> -net nic,macaddr=52:54:00:f2:18:b7,model=e1000 -net tap \
> -cdrom /u/GNU/Debian/debian-6.0.6-amd64-netinst.iso -boot d --hda disk.img
Richard Henderson writes:
On 2013-02-19 13:52, Torbjorn Granlund wrote:
> Execute. I believe correct behaviour is to print:
>
> 000d 000d 040b 000a
>
> The program under your special qemu instead prints:
>
> 00
On 2013-02-19 13:52, Torbjorn Granlund wrote:
Execute. I believe correct behaviour is to print:
000d 000d 040b 000a
The program under your special qemu instead prints:
000e 000d 040b 000a
The new gdb (7.5.1) did not change anything.
The program behaves one way inside gdb and one way outside.
The behaviour inside gdb is surely incorrect.
I think the behaviour outside of gdb is also incorrect, but I haven't
spent much time thinking about it.
To repdoduce curious behaviour:
Compile
On 02/19/2013 12:40 PM, Torbjorn Granlund wrote:
> The apparent symptom is that an
>
> adox (%rdi,%rcx,8), %r9
>
> where the 8 bytes at the memory location contains just zeros,
> and r9 is some random value, results in OF being set.
Interesting.
> I only have Intel's 327831.pdf document whi
Richard Henderson writes:
I've updated that branch; please try again.
Thanks.
I am no friend of git's, and my mercurial commands (pull -u) cause
million conflicts.
OK, I grabbed a new copy and have built it. It works better, sshd now
runs.
Somethings seems wrong with adcx and/or adox. O
On 2013-02-14 05:38, Torbjorn Granlund wrote:
Richard Henderson writes:
Yes, and "-cpu Haswell" will enable the BMI extensions.
I have used git://repo.or.cz/qemu/rth.git x86-next checked out around 15
January for a while now. The host system is Debian GNU/Linux amd64 and
the guest is FreeB
On 02/14/2013 05:38 AM, Torbjorn Granlund wrote:
> I now updated x86-next in order to get support for adox/adcx.
Hmm. I'm not quite sure what the state of that branch is atm.
I know I started splitting out work into other branches as will
be required by the eventual merge; perhaps I didn't put t
Richard Henderson writes:
Yes, and "-cpu Haswell" will enable the BMI extensions.
I have used git://repo.or.cz/qemu/rth.git x86-next checked out around 15
January for a while now. The host system is Debian GNU/Linux amd64 and
the guest is FreeBSD 9.1 amd64.
I now updated x86-next in order
Richard Henderson writes:
Then you got the wrong branch from the repository:
translate.c:4055:case 0x3f6: /* mulx By, Gy, rdx, Ey */
You need the "x86-next" branch.
I am not a git user, and misundersand the command.
Now I have the correct version, and can confirm that
Richard Henderson writes:
On 01/14/2013 10:14 AM, Torbjorn Granlund wrote:
> Is it in such a state that grabbing that repo and building a
> qemu-system-x86_64 would give me MULX support?
Yes, and "-cpu Haswell" will enable the BMI extensions.
A review of the code and docs reveals
On 01/15/2013 09:14 AM, Torbjorn Granlund wrote:
There seem to be no mention of MULX in the i386 subdirectory.
Then you got the wrong branch from the repository:
translate.c:4055:case 0x3f6: /* mulx By, Gy, rdx, Ey */
You need the "x86-next" branch.
r~
On 01/14/2013 10:14 AM, Torbjorn Granlund wrote:
Is it in such a state that grabbing that repo and building a
qemu-system-x86_64 would give me MULX support?
Yes, and "-cpu Haswell" will enable the BMI extensions.
A review of the code and docs reveals that I missed RORX
from the BMI2 insns, but
Richard Henderson writes:
> MULX implies a bunch of other instructions due to CPUID flag grouping.
> ADCX and ADOX can be implemented separately. None of these and the
> other instructions in the MULX group look very complex.
I've got a patch for (most of?) the bmi[12] insns:
gi
On 01/12/2013 03:40 AM, Blue Swirl wrote:
MULX implies a bunch of other instructions due to CPUID flag grouping.
ADCX and ADOX can be implemented separately. None of these and the
other instructions in the MULX group look very complex.
I've got a patch for (most of?) the bmi[12] insns:
git:/
Blue Swirl writes:
MULX implies a bunch of other instructions due to CPUID flag grouping.
ADCX and ADOX can be implemented separately. None of these and the
other instructions in the MULX group look very complex.
I had not realised that qemu disabled instructions when emulating a CPU
not
On Thu, Jan 10, 2013 at 1:46 PM, Torbjorn Granlund wrote:
> There are 3 instructions, MULX, ADCX, and ADOX, which would be very
> useful to see in qemu. I looked into putting them in myself, but the
> startup time for hacking qemu is longer than I can affort in this
> period.
>
> Apparently, MULX
There are 3 instructions, MULX, ADCX, and ADOX, which would be very
useful to see in qemu. I looked into putting them in myself, but the
startup time for hacking qemu is longer than I can affort in this
period.
Apparently, MULX is implemented in Haswell, while ADCX and ADOX will
appear in Broadwe
19 matches
Mail list logo
