pouët.net

FPU debugger

category: code [glöplog]
 
Hello!

I started learning FPU x86 coding so that my future 256btros won't suck.
Problem, the stack logic is such a nuisance, it's not easy to know if you are doing something wrong.

I never used a debugger before for my intros. Which do you suggest? I have searched on google and found OllyDBG but it seems to not take com files (and how would I debug a DOS intro from windows?). I would gladly use a DOS one from DosBox if there is no window alternative. We are talking about 256b intros always.

So, what are the 256b coders using? Heeelp, FPU code is driving me crazy!
added on the 2011-09-24 18:19:37 by Optimus Optimus
A charming solution I found recently is to develop the intro entirely in Visual Studio and just copy the finished source into a NASM file when done.
added on the 2011-09-24 18:25:22 by Gargaj Gargaj
Otherwise, Turbo Debugger does just fine.
added on the 2011-09-24 18:26:05 by Gargaj Gargaj
Maybe that's not one of the answers you wanted to read but well (= It helps a lot to write the values of the stack next to your code to keep control where which value is and what you do (a lot of [commented] sources provide that).
yes, Turbo Debugger
added on the 2011-09-24 19:12:20 by lsl lsl
Pah.. Turbo Debugger.. Real men use the Watcom Debugger!
added on the 2011-09-24 19:15:01 by torus torus
Come on, it's a stack! No more than 8 elements deep too! Man up, do some Forth coding, then come back :)
added on the 2011-09-24 19:56:27 by ryg ryg
Well the x86 FPU stack is a bitch. Anyway, debugging helps, so basically what Gargaj said.
added on the 2011-09-24 20:08:34 by doomdoom doomdoom
You can debug your ASM code using Visual Studio, no problem.
added on the 2011-09-24 21:15:48 by trc_wm trc_wm
what Gargaj and the rest said: Turbo Debugger..
added on the 2011-09-24 22:50:49 by rudi rudi
what's an x86?
added on the 2011-09-25 00:40:28 by ferris ferris
Debugger? What's that? Just keep a running list of comments on the next of each instruction like this:

Code: fld [angle] ; st(0) = angle fldpi ; st(0) = pi, st(1) = angle fmulp st(1), st(0) ; st(0) = pi * angle fsincos ; st(0) = cos(angle), st(1) = sin(angle) fld [whatever] ; st(0) = whatever, st(1) = cos, st(2) = sin fld [whatever2] ; st(0) = whatever2, st(1) = whatever, st(2) = cos, st(3) = sin fmul st(0), st(2) ; st(0) = whatever2*cos, rest is the same fmul st(1), st(3) ; st(1) = whatever*sin, rest is the same faddp st(1), st(0) ; st(0) = whatever*sin + whatever2*cos fstp [result] ; st(0) = cos, st(1) = sin
added on the 2011-09-25 02:04:53 by Preacher Preacher
I'll go for Turbo Debugger then, but Visual Studio is an interesting solution too (I guess, that explains the windows compatible versions in few of the intros).

I'll try to put some comments now, I didn't, I had all in my mind. Though, I still think something is going wrong, problem since I am not sure yet which commands pop and which not, without seeing the state of the regs in a debugger, and the bug seems to be there.
added on the 2011-09-25 10:25:55 by Optimus Optimus
Grab some book with the commands or some website. 'P' (like in faddp, fstp, fistp and so on) at the end pops (=
My problem was, I thought fsubr st1,st0 does st1-st0 to st0 while it doesn't
it should be fsubr st0,st1. I somehow thought r, reversed where it's loaded, not the operation :P
added on the 2011-09-25 11:14:07 by Optimus Optimus
Anyway, the debugger helped :)
added on the 2011-09-25 11:14:24 by Optimus Optimus
well then keep on coding :D
http://www.posix.nl/linuxassembly/nasmdochtml/nasmdoca.html:
Quote:
FSUBR does the same thing, but does the subtraction the other way up: so if TO is not given, it subtracts ST0 from the given operand and stores the result in ST0, whereas if TO is given it subtracts its operand from ST0 and stores the result in the operand.

:)
added on the 2011-09-25 13:10:37 by Gargaj Gargaj
use SSE instead of FPU. You'll get better performance and you won't have to deal with that fpu stack mess.
added on the 2011-09-25 15:21:40 by zerkman zerkman
Isn't SSE code generally larger due to the needed escape opcodes; besides good luck doing SSE sin/cos/tan/exp etc in 256 byte intros.
added on the 2011-09-25 16:29:45 by trc_wm trc_wm
Yeah SSE isn't terribly well suited for it. FPU! Other than that, what people said about stackcomments and what Ry said.. don't fucking overthink this.
added on the 2011-09-25 21:45:27 by superplek superplek
What's the problem with the FPU stack? I had no problems with when I was coding assembly 6 years ago. Like ryg said it's a stack. You push. You calc. You pop. Maybe it gets big if you're trying to do a 256B. That I don't know.
added on the 2011-09-25 22:41:38 by xernobyl xernobyl
SSE assembly is very unintuitive.
added on the 2011-09-25 22:42:33 by xernobyl xernobyl
It's really not.
added on the 2011-09-25 22:59:35 by superplek superplek
I am getting used to it. It's not that bad.
Problem with the stack logic, you weren't sure what was stored at each place after a lot of operations (that's why you need the comments).
Anyway, if you get used to it and learn to write good code, it's quite convinient.
SSE, I might look at it one day. Not for intros but out of curiosity.
added on the 2011-09-26 10:10:42 by Optimus Optimus

login