Found out what the intruction that was causing the exception was, the 3Dnow! instruction FEMMS, which obviously doesn't work on my EMT64 Celeron. Now having not worked much with 3Dnow! I have little idea as to what that instruction does, but removing it doesn't from what I can see impede the execution of the program.

Yes, it so. Intel's processors of all models not supports commands 3DNOW!. It's one of the reasons on which I have bought to myself AMD's processor.

Dare I ask, but do people actually use 3dNow! much in their programs? (Did they ever?) I remember recently reading one FASMer comment that it was not as useful now that SSE (1,2,3, etc.) has entered the picture.

You are right, from its part. Advantage in distribution of commands SSE (1,2,3,4...) above commands 3DNOW it is caused by one factor - dictation of "fashion" on technology. Intel and Microsoft always were the companies partners and consequently Microsoft first of all supports in all products of ideas and technologies from Intel. All market is guided by processors Intel, and on the technologies which have been built in these processors. And it is not important, they are good or not. On it there are not enough the compilers supporting features of other processors. And on own experience it was convinced, that actions above numbers with a floating point by means of commands 3DNOW work more quickly, than analogues from commands SSE. However, it not so if you process the files filled by numbers when it is possible use commands of parallel processing of several numbers. But here to whom they it is necessary, except for the programmers who are engaged 3D-graphic?

P.S. We can argue very long about it, but all is equal, what for to buy the processor which expensively costs and does not support the whole sets of commands which though and it's rather rare, but everyone are used on a PC-platform?

Is there not a portable way to detect 3dNow! availability? Just test for it, and if it's there, use it. (At least, that'd be better than bombing out on Intel chips.) I'm not opposed to it, use what you want!

according to the compactibility between AMD64 and EM64T femms was abandoned and replaced with slower (but compactible) emms instruction since 000D (2007 january 01) version of fdbg
thanks for reports and testing on EM64T guys, I hope everything works fine now and there aren't incompactible instructions there anymore
disasm engine keeps strictly AMD64 manuals
I have never bought other CPU than AMD. The main reason was price 10 years ago, 64-bits 2 years ago. Intel CPUs haven't had any advantages for me yet. If any of them has then I will prefer it of course.

have not a big wish - that in a window of data it would be possible to enter a name of the register and not just the address to view data.

Hi Feryno again!

I have still some questions to you

1. That the command on which the debugger has now stopped, showed not to the first line in a window of a code, and, for example, in the central line. It will enable to not forget sequence of the previous commands. Whether it's possible?

2. Whether there is an opportunity to intercept a command "int 3" globally for all programs? I know the driver need to make it, but it would be super

3. Whether I not can make some changes to a source code of a debugger for personal use? (for example, global hot keys for show\hide of the basic window)

Certainly, AMD seems to be loved as much as Intel these days, so I see no reason not to use 'em. (Also, being cheaper doesn't hurt! )

BTW, I just remembered (and surprised no one mentioned it here), Intel Core 2 does have SSSE3 (Supplemental SSE3, unlike AMD's latest cpus).

new releases for Linux and Win
win64 special edition for Garthower (thanx for idea!)
please note that you can quickly transfer address by:
double clicking on reg/disassembled instruction (opens Edit Control) -> double clicking on address (selects it) -> CTRL+C -> double clicking on target addres in code/data/stack (opens Edit Control) -> double clicking on value (selects it) -> CTRL+V
It seems a lot of operations, but everybody is able to manage it in less than 2 seconds (especially you can "quadru-click" instead of 2 doubleclicks...)
putting rip in code, rsp in stack as address quickly sets code/stack window to the default if you are faraway (after lot of PGUPs/PGDOWNs...)
Double clicking on disassembled instruction of code win opens Edit Control for you be able to select string and copy it (this wasn't supported in previous version). It doesn't support putting new instruction there.
That's new.
The old still stays:
Code 1st displaying start address is updated every single step / step over / exception during run
Code 2nd displaying start address isn't updated so this is probably the answer to Garthower's question No. 1
Question No. 3 - of course, you can do everything what you want, modify it for your best usage and post here every good ideas. fdbg is meant to help in coding in asm so every idea, every change, every improvement which could help to somebody is good and welcomed
Question No. 2 - would you explain it more please (fdbg needn't any driver for user mode programs running in ring3 mode, it is not any kernel mode debugger)

to rugxulo - I hope AMD will answer and implement these instructions. It's not good when CPUs from AMD and Intell differs.

edit 2007 March 26 deleted attachment because quota limit

feryno: finally tried FDBG for linux. It's nicer to use than ALD or GDBTUI, nice job.

Here are few things:
- you could add possibility to specify number of instructions after "c" command, like "c 100000 10" would show 10 instructions.
- maybe general purpose registers name abbreviations?
i=rip, a=rax, b=rbx, c=rcx, d=rdx, s=rsi, d=rdi, ?p?=rbp, s=rsp
- in "r" command, change "r9=" to "r9= "(with space after =), to align output.

I shall try to explain on more precisely wash a my question N2. I had in view of interruption (with loading interrupted programm) at any performance of a command "int 3". So, for example, it has been realized in Numega SoftIce if into consoles to enter a command "i3here on".

Not a big specification about my offer for a window of a code. I had in view of scrolling a window that the line on which the interrupted command is now displayed, was in the center of a window, instead of in the top.

special edition for Garthower
(Face -> Various face settings -> Code 1st disassemble back ... instructions
0 is default there so increase it (direct enter the nuber, or press UP arrow or click with rat on Up-Down control)

samples contain new antidebug trick (thanx vid) with FPU instruction pointer, FPU data pointer (they are destroyed after another app or OS uses FPU - ? aren't saved when switching task ???) - FPU\a00.asm
just run any background thread executing any FPU instruction e.g. every 1 ms and you aren't able to single step throug this antidebug (winamp 2.09 with visualization plugins on is enough by me...) - fortunatelly you can go through antidebug by putting SW BP after fnstenv and executing run

edit 2007 March 26 deleted attachment because quota limit

Thanks Feryno, perfect work!

There's one glitch - it acts like Visual Studio's debugger in this matter:
both movq and movd are translated to movd. Not a big problem if you realize the 48h prefix and r as the first letter of the GPR, but may confuse some people :S
db 66h,48h,0Fh,7Eh,0C2h - movq rdx,xmm0 for example

I'm sorry if I sound OllyDBG-biased, but its more comfortable if the GPR+RIP+flags+(maybe DR+Seg) are in one place and MM/ST+Floatflags in another. First it preserves room and second you won't have to manually arrange them by pixels. One can hog more visually when there's more code to see where the debugger is.

And yes - I agree that r08, r09 are great for visual beauty

Don't get me wrong - I'm not here to criticize. The functionality is great. Maybe if I'll understand the code better, I'll make the changes myself and then you can accept/refuse the changes

2Feryno: Whether you in the future plan to add an opportunity of debugging of drivers?

Grrr, so much talk about FDBG but i have no 64-bit CPU!!! ;(

Well, see for you two ways:
1. To buy to itself the processor
2. As the debugger is open-source and the author allows to do there any changes of an initial code, you can re-write it on 32 bit

to Madis731
according 26568.pdf revision 3.07 december 2005 from www.amd.com
movd instruction is encoded 66 0F 6E or 66 0F 7E and is used to move quadword as well (although it's movd name)

movq isn't used to move anything with GPR register (really, see that strange fact in pdf)

so according AMD manuals, this instruction
movq rdx,xmm0
has to be encoded movd rdx,xmm0 even it moves quadword, no doubleword

the other fact is that FASM is human-like and uses correct movd for move dw and movq for move qw. AMD manuals are rigid and seem unlogical, but I keep their rules in disasm engine

Modify what you want and post any good releases here
I can't make app to fit to everybody - somebody may like to see only xmm regs and iconize mm registers to have more space for displaying anything etc. Sources are included for everybody to be able to modify them to his/her best personal usage.
Functionality is great - thank bro ! Now I don't have enough time to test new things thoroughly (year ago developpment looked like 50% of time with coding, 50% with testing but now: 95% time coding and only 5% testing)

to Garthower - opportunity of debugging of drivers has been my dream which isn't documented enough for me to implement it. If I know the way how to do it then I will certainly implement it.
These thoughts are only my imaginations:
for debugging driver loaded during OS boot it is necessary to have another connected PC to catch informations sent by e.g. USB or another type of cable (display isn't initialized, winlogon isn't invoked...)
for debugging driver loaded after logging on perhaps only another kernel driver is enough

to Raedwulf
Man, be optimistic and say to yourself: It's only a question of time untill I get 64-bit CPU !

to everybody:
in fact, when I started to play with win debug apis, I only wanted to know what are they doing... I haven't anything else to code so I continued with that playing... then I realized that fdbg is in a stage to be usefull to somebody. At begin of playing, I didn't thought that sometimes it would be usefull app... It's only thank to enough time and lack of other things to do.

Cannot QEMU and/or BOCHS emulate 64-bit? (Sorry, never tried to do so, but that's what I hear ...).