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!
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!
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.
Otherwise, Turbo Debugger does just fine.
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
Pah.. Turbo Debugger.. Real men use the Watcom Debugger!
Come on, it's a stack! No more than 8 elements deep too! Man up, do some Forth coding, then come back :)
Well the x86 FPU stack is a bitch. Anyway, debugging helps, so basically what Gargaj said.
You can debug your ASM code using Visual Studio, no problem.
what Gargaj and the rest said: Turbo Debugger..
what's an x86?
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
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.
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.
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
it should be fsubr st0,st1. I somehow thought r, reversed where it's loaded, not the operation :P
Anyway, the debugger helped :)
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.
:)
use SSE instead of FPU. You'll get better performance and you won't have to deal with that fpu stack mess.
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.
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.
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.
SSE assembly is very unintuitive.
It's really not.
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.
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.