Slow nasm
in [ASM]
|
From: Betov on 27 Oct 2007 09:32 Herbert Kleebauer <klee(a)unibwm.de> �crivait news:47231CF4.98C027ED(a)unibwm.de: > The code is working OK for small DLLs, such imagehlp.dll > but if bigger, application is freezing. Not here. It always hangs. And, not to sound unpleasant, but, given the way it is written this is not a big surprise, to me. I suspect a wrong return value in the Dialog Initialization, or someting like that (I did not looked that deeper inside...). > Maybe NASM doesn't optimize his sort algorithm (a well designed > assembler doesn't only look at the instructions the programmer gives > it to assemble but analyses the complete program and replaces a slow > algorithm itself by a faster one) and therefore it gets extremely > slow ("freezing" when compared to the human life time). ? You saying that ? Sorry, but i never heard of any Assembler optimizing anything. I suppose you did not wrote what you had in mind... Or, are you drunk ? Betov. < http://rosasm.org >
From: volcano on 27 Oct 2007 09:35 Hi, As i said, my complains about freezing application with bigger circles. But not sure. I would debug if it give an error. But is working well with 30-40 circles. Anyway, looked at code with olly. I saw lots of useless "00". So, thought that the compiled code is not optimized well. The link In my first post, there is a Tasm code too. It is working good. Maybe i can try on the code for a working copy. Or use masm etc. But if nasm is wrong, this must fix. I want to give a chance to it. Anyway, one of the component(code,nasm,alink,nagoa.obj) is wrong.
From: Betov on 27 Oct 2007 11:34 volcano <vkdemir(a)gmail.com> �crivait news:1193492104.804557.53650 @v3g2000hsg.googlegroups.com: > As i said, my complains about freezing application with bigger > circles. Sorry for miss-understanding, then. > But not sure. I would debug if it give an error. But is > working well with 30-40 circles. It is usually difficult to debug faults coming out during the intialization of a DialogBox. RosAsm's Debugger also fails to point to the faultive instruction. Two cues: * Possible wrong return value out of the DialogProc. * Possible unpaired Stack. [Sorry, but i have no time for debugging your app completely] > Anyway, looked at code with olly. I saw lots of useless "00". So, > thought that the compiled code is not optimized well. This sentence does not mean a thing. > The link In my first post, there is a Tasm code too. It is working > good. This does not mean that your NASM port is right. > Maybe i can try on the code for a working copy. Or use masm etc. But > if nasm is wrong, this must fix. I want to give a chance to it. You can't give a chance to NASM: NASM owe you nothing. This was you who got a chance, and let me tell you that NASM will agrea giving you as many chances as you will want to get. :) > Anyway, one of the component(code,nasm,alink,nagoa.obj) is wrong. No. You Code is wrong. Period. First, do something clean. That is, not mixing Data right in between Code with stupid jumps around the Data. Set your Declarations together in a normal Section. Then re-organize your procedure the correct standard way. After doing this, if the app still hangs, verify your API calls to make sure that the wanted number of parameter is correct. If still nothing, verify the return Codes of the DialogProc. Betov. < http://rosasm.org >
From: Herbert Kleebauer on 27 Oct 2007 12:23 Betov wrote: > > (a well designed > > assembler doesn't only look at the instructions the programmer gives > > it to assemble but analyses the complete program and replaces a slow > > algorithm itself by a faster one) > ? You saying that ? > > Sorry, but i never heard of any Assembler optimizing anything. > I suppose you did not wrote what you had in mind... Or, are > you drunk ? Because of the other posts But I used HLA to learn assembly. HLA is a perfect tool for learning how to program in Assembly Language. The code is working OK for small DLLs but if bigger, application is freezing. Is (code generated by) nasm so slow I thought this is the fairytale day in a.l.a
From: Betov on 27 Oct 2007 12:25 Herbert Kleebauer <klee(a)unibwm.de> �crivait news:472365FA.5CCFC1F0(a)unibwm.de: > Because of the other posts > > > But I used HLA to learn assembly. > > HLA is a perfect tool for learning how to program in Assembly > Language. > > The code is working OK for small DLLs but if bigger, application > is freezing. Is (code generated by) nasm so slow > > > I thought this is the fairytale day in a.l.a Ooopppsss... I still have progresses to do on the front line of humour. :]]]]] Betov. < http://rosasm.org >
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Super Basic 80x86 Assembly Homework Help Next: Bootstrapping DOS boot disk |