digitalmars.D.debugger - FPU stack and XMM registers in ddbg
- Daniel Keep (25/25) Apr 27 2007 Jascha,
- Jascha Wetzel (4/26) Apr 28 2007 you'll have it.
- Jascha Wetzel (3/30) Apr 28 2007 oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm
- Frits van Bommel (5/7) Apr 28 2007 That doesn't mean they won't be used in (mostly-)D programs. You can
- Jascha Wetzel (65/74) Apr 28 2007 that's right. Ddbg doesn't support debugging non-D code, though.
- Daniel Keep (18/97) Apr 28 2007 Many thanks for this. The only thing is that the MM and XMM registers
- Jascha Wetzel (8/100) Apr 29 2007 yeah, i was going the lazy way of always printing them in all possible
- Daniel Keep (13/20) Apr 29 2007 I wasn't going to ask for that since I figured it would be more work,
- Jascha Wetzel (2/16) Apr 29 2007
- Thomas Kuehne (12/14) Apr 28 2007 -----BEGIN PGP SIGNED MESSAGE-----
- Jascha Wetzel (5/16) Apr 28 2007 you're right. what i meant were the AMD specific SSE2 extensions.
Jascha, any chance we could get the following commands in an upcoming release of ddbg? df: Dumps FPU stack, formatted as floating point numbers. dx TYPE: Dumps the XMM registers, formatting them as the given type (ie: float to display as 4 32-bit floats, ubyte to display as 16 8-bit unsigned integers, etc.). I've been using ddbg to play around with optimising some of my vector code, and being able to dump the XMM registers would be massively helpful (why are you returning 9 and not 14 you silly dot product?!). The FPU stack one is more out of curiosity than anything else :) Also, I don't think I've said this before, but thanks very much for writing and working on ddbg: it's an absolute god-send, especially since WinDBG seems to crash on disassembling SSE code and NASM can't seem to disassemble it properly either. -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Apr 27 2007
you'll have it. they'll all come with the dr command though, with a separate switch for the register sets x86, x86 segs, x87, MMX, SSE, SSE2, 3DNOW! Daniel Keep wrote:Jascha, any chance we could get the following commands in an upcoming release of ddbg? df: Dumps FPU stack, formatted as floating point numbers. dx TYPE: Dumps the XMM registers, formatting them as the given type (ie: float to display as 4 32-bit floats, ubyte to display as 16 8-bit unsigned integers, etc.). I've been using ddbg to play around with optimising some of my vector code, and being able to dump the XMM registers would be massively helpful (why are you returning 9 and not 14 you silly dot product?!). The FPU stack one is more out of curiosity than anything else :) Also, I don't think I've said this before, but thanks very much for writing and working on ddbg: it's an absolute god-send, especially since WinDBG seems to crash on disassembling SSE code and NASM can't seem to disassemble it properly either. -- Daniel
Apr 28 2007
oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm doesn't support them... Jascha Wetzel wrote:you'll have it. they'll all come with the dr command though, with a separate switch for the register sets x86, x86 segs, x87, MMX, SSE, SSE2, 3DNOW! Daniel Keep wrote:Jascha, any chance we could get the following commands in an upcoming release of ddbg? df: Dumps FPU stack, formatted as floating point numbers. dx TYPE: Dumps the XMM registers, formatting them as the given type (ie: float to display as 4 32-bit floats, ubyte to display as 16 8-bit unsigned integers, etc.). I've been using ddbg to play around with optimising some of my vector code, and being able to dump the XMM registers would be massively helpful (why are you returning 9 and not 14 you silly dot product?!). The FPU stack one is more out of curiosity than anything else :) Also, I don't think I've said this before, but thanks very much for writing and working on ddbg: it's an absolute god-send, especially since WinDBG seems to crash on disassembling SSE code and NASM can't seem to disassemble it properly either. -- Daniel
Apr 28 2007
Jascha Wetzel wrote:oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm doesn't support them...That doesn't mean they won't be used in (mostly-)D programs. You can still use a separate assembler and link the output in. (And for the really perverse, db and friends can emit any code you like from within the inline assembler :P)
Apr 28 2007
that's right. Ddbg doesn't support debugging non-D code, though. on the other hand SSE2 only means new registers on AMD cpus and 3dnow is just a reinterpretation of the mmx registers. i added all the interpretations of the XMM and MM registers but didn't bother to get the AMD specific SSE2 extensions. therefore it's going to be MMX, 3DNOW!, SSE and SSE2 intel. the switches will be cpu, fpu, mmx, sse. here is what the new full register dump looks like: EAX = 00000002 EBX = 00000004 ECX = 00000004 EDX = 0012ff20 EDI = 00000001 ESI = 00000001 EBP = 0012ff30 ESP = 0012fedc EIP = 004020ea EFL = 00000302 CS = 0000001b DS = 00000023 ES = 00000023 FS = 0000003b GS = 00000000 SS = 00000023 FCW = 137f FSW = 2100 FTW = 00ff FOP = 0014 IP = 00000000 CS = 0000 DP = 00000000 DS = 0000 ST0 = 1.0300000000000000e+01 ST1 = 3.8000000000000000e+00 ST2 = 2.4000000000000000e+00 ST3 = 5.6000000000000000e+00 ST4 = 4.6891198690254339e-4932 ST5 = 3.6451995318824746e-4951 ST6 = 8.1918522314966046e+4456 ST7 = 0.0000000000000000e+00 MM0 = a4cccccccccccccd = [-1.07374e+08, -8.88178e-17] MM1 = f333333333333333 = [4.17233e-08, -1.41977e+31] MM2 = 999999999999999a = [-1.58819e-23, -1.58819e-23] MM3 = b333333333333333 = [4.17233e-08, -4.17233e-08] MM4 = b2857a24805b09dd = [-8.36057e-39, -1.55388e-08] MM5 = 0000000000000001 = [1.4013e-45, 0] MM6 = badb0d00804fd645 = [-7.33187e-39, -0.00167122] MM7 = 00000017e62a9390 = [-2.01381e+23, 3.22299e-44] MXCSR = 00001f80 XMM0 = 406d5224dd2f1aa0405edd2f1a9fbe77 = [6.60686e-23, 3.48225, -7.88598e+17, 3.70814] = [123.456, 234.567] XMM1 = 406d5224dd2f1aa0405edd2f1a9fbe77 = [6.60686e-23, 3.48225, -7.88598e+17, 3.70814] = [123.456, 234.567] XMM2 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM3 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM4 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM5 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM6 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM7 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] Frits van Bommel wrote:Jascha Wetzel wrote:oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm doesn't support them...That doesn't mean they won't be used in (mostly-)D programs. You can still use a separate assembler and link the output in. (And for the really perverse, db and friends can emit any code you like from within the inline assembler :P)
Apr 28 2007
Jascha Wetzel wrote:that's right. Ddbg doesn't support debugging non-D code, though. on the other hand SSE2 only means new registers on AMD cpus and 3dnow is just a reinterpretation of the mmx registers. i added all the interpretations of the XMM and MM registers but didn't bother to get the AMD specific SSE2 extensions. therefore it's going to be MMX, 3DNOW!, SSE and SSE2 intel. the switches will be cpu, fpu, mmx, sse. here is what the new full register dump looks like: EAX = 00000002 EBX = 00000004 ECX = 00000004 EDX = 0012ff20 EDI = 00000001 ESI = 00000001 EBP = 0012ff30 ESP = 0012fedc EIP = 004020ea EFL = 00000302 CS = 0000001b DS = 00000023 ES = 00000023 FS = 0000003b GS = 00000000 SS = 00000023 FCW = 137f FSW = 2100 FTW = 00ff FOP = 0014 IP = 00000000 CS = 0000 DP = 00000000 DS = 0000 ST0 = 1.0300000000000000e+01 ST1 = 3.8000000000000000e+00 ST2 = 2.4000000000000000e+00 ST3 = 5.6000000000000000e+00 ST4 = 4.6891198690254339e-4932 ST5 = 3.6451995318824746e-4951 ST6 = 8.1918522314966046e+4456 ST7 = 0.0000000000000000e+00 MM0 = a4cccccccccccccd = [-1.07374e+08, -8.88178e-17] MM1 = f333333333333333 = [4.17233e-08, -1.41977e+31] MM2 = 999999999999999a = [-1.58819e-23, -1.58819e-23] MM3 = b333333333333333 = [4.17233e-08, -4.17233e-08] MM4 = b2857a24805b09dd = [-8.36057e-39, -1.55388e-08] MM5 = 0000000000000001 = [1.4013e-45, 0] MM6 = badb0d00804fd645 = [-7.33187e-39, -0.00167122] MM7 = 00000017e62a9390 = [-2.01381e+23, 3.22299e-44] MXCSR = 00001f80 XMM0 = 406d5224dd2f1aa0405edd2f1a9fbe77 = [6.60686e-23, 3.48225, -7.88598e+17, 3.70814] = [123.456, 234.567] XMM1 = 406d5224dd2f1aa0405edd2f1a9fbe77 = [6.60686e-23, 3.48225, -7.88598e+17, 3.70814] = [123.456, 234.567] XMM2 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM3 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM4 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM5 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM6 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM7 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] Frits van Bommel wrote:Many thanks for this. The only thing is that the MM and XMM registers can store quite a few different types. For instance, IIRC, all the original MMX instructions dealt with integers, whilst 3DNow! added floats. SSE2 also adds integer types for the XMM registers, so being able to say "dump the XMM registers as, oh let's call them uint's" would be handy :) Other than that, looks perfect :) -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/Jascha Wetzel wrote:oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm doesn't support them...That doesn't mean they won't be used in (mostly-)D programs. You can still use a separate assembler and link the output in. (And for the really perverse, db and friends can emit any code you like from within the inline assembler :P)
Apr 28 2007
yeah, i was going the lazy way of always printing them in all possible types, but i guess for XMM regs there are too many. imho, the right way to do this is to allow registers in expressions. then they can be cast to the desired type. ->= cast(float[4])xmm0 That should also come in handy if you want to do something like ->= cast(MyClass*)eax Daniel Keep wrote:Jascha Wetzel wrote:that's right. Ddbg doesn't support debugging non-D code, though. on the other hand SSE2 only means new registers on AMD cpus and 3dnow is just a reinterpretation of the mmx registers. i added all the interpretations of the XMM and MM registers but didn't bother to get the AMD specific SSE2 extensions. therefore it's going to be MMX, 3DNOW!, SSE and SSE2 intel. the switches will be cpu, fpu, mmx, sse. here is what the new full register dump looks like: EAX = 00000002 EBX = 00000004 ECX = 00000004 EDX = 0012ff20 EDI = 00000001 ESI = 00000001 EBP = 0012ff30 ESP = 0012fedc EIP = 004020ea EFL = 00000302 CS = 0000001b DS = 00000023 ES = 00000023 FS = 0000003b GS = 00000000 SS = 00000023 FCW = 137f FSW = 2100 FTW = 00ff FOP = 0014 IP = 00000000 CS = 0000 DP = 00000000 DS = 0000 ST0 = 1.0300000000000000e+01 ST1 = 3.8000000000000000e+00 ST2 = 2.4000000000000000e+00 ST3 = 5.6000000000000000e+00 ST4 = 4.6891198690254339e-4932 ST5 = 3.6451995318824746e-4951 ST6 = 8.1918522314966046e+4456 ST7 = 0.0000000000000000e+00 MM0 = a4cccccccccccccd = [-1.07374e+08, -8.88178e-17] MM1 = f333333333333333 = [4.17233e-08, -1.41977e+31] MM2 = 999999999999999a = [-1.58819e-23, -1.58819e-23] MM3 = b333333333333333 = [4.17233e-08, -4.17233e-08] MM4 = b2857a24805b09dd = [-8.36057e-39, -1.55388e-08] MM5 = 0000000000000001 = [1.4013e-45, 0] MM6 = badb0d00804fd645 = [-7.33187e-39, -0.00167122] MM7 = 00000017e62a9390 = [-2.01381e+23, 3.22299e-44] MXCSR = 00001f80 XMM0 = 406d5224dd2f1aa0405edd2f1a9fbe77 = [6.60686e-23, 3.48225, -7.88598e+17, 3.70814] = [123.456, 234.567] XMM1 = 406d5224dd2f1aa0405edd2f1a9fbe77 = [6.60686e-23, 3.48225, -7.88598e+17, 3.70814] = [123.456, 234.567] XMM2 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM3 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM4 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM5 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM6 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] XMM7 = 43e464fe43acd6c9436a912742f6e979 = [123.456, 234.567, 345.678, 456.789] = [5.98235776617e+16, 1.17566315604e+19] Frits van Bommel wrote:Many thanks for this. The only thing is that the MM and XMM registers can store quite a few different types. For instance, IIRC, all the original MMX instructions dealt with integers, whilst 3DNow! added floats. SSE2 also adds integer types for the XMM registers, so being able to say "dump the XMM registers as, oh let's call them uint's" would be handy :) Other than that, looks perfect :) -- DanielJascha Wetzel wrote:oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm doesn't support them...That doesn't mean they won't be used in (mostly-)D programs. You can still use a separate assembler and link the output in. (And for the really perverse, db and friends can emit any code you like from within the inline assembler :P)
Apr 29 2007
Jascha Wetzel wrote:yeah, i was going the lazy way of always printing them in all possible types, but i guess for XMM regs there are too many. imho, the right way to do this is to allow registers in expressions. then they can be cast to the desired type. ->= cast(float[4])xmm0 That should also come in handy if you want to do something like ->= cast(MyClass*)eaxI wasn't going to ask for that since I figured it would be more work, but whatever makes you happy :) -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Apr 29 2007
the right way (tm) makes me happy ;) Daniel Keep wrote:Jascha Wetzel wrote:yeah, i was going the lazy way of always printing them in all possible types, but i guess for XMM regs there are too many. imho, the right way to do this is to allow registers in expressions. then they can be cast to the desired type. ->= cast(float[4])xmm0 That should also come in handy if you want to do something like ->= cast(MyClass*)eaxI wasn't going to ask for that since I figured it would be more work, but whatever makes you happy :) -- Daniel
Apr 29 2007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jascha Wetzel schrieb am 2007-04-28:oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm doesn't support them...Are your sure that SSE2 and 3DNOW! aren't supported by DMD? While there are a number of FPU and cvtp* related bugs, SSE1/2/3 and 3DNOW! seem to work on my box. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFGM5UlLK5blCcjpWoRAiTBAJkBVeFziy4tbE5yJkc2vigdnbjdGQCdEsi4 phHf8/X9Lge+gC8c5kBCRcg= =5vIH -----END PGP SIGNATURE-----
Apr 28 2007
you're right. what i meant were the AMD specific SSE2 extensions. and i was wrong about the 3DNOW! registers, there is no such thing - i didn't know that (it's just a different interpretation of the MMX registers, which are a different interpretation of the FPU registers). Thomas Kuehne wrote:Jascha Wetzel schrieb am 2007-04-28:oh ok, forget SSE2 and 3DNOW! - makes little sense as long D inline asm doesn't support them...Are your sure that SSE2 and 3DNOW! aren't supported by DMD? While there are a number of FPU and cvtp* related bugs, SSE1/2/3 and 3DNOW! seem to work on my box. Thomas
Apr 28 2007