NASM - The Netwide Assembler

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2 3 ... 10
 1 
 on: April 28, 2017, 07:42:09 PM 
Started by sal55 - Last post by sal55
I noticed recently that Nasm slows down considerably as input gets above a certain size.

It was only a problem on special test files, not on normal input. But now I have a real program and the time to assemble it is becoming a nuisance. So I'm reporting it as a problem.

Nasm is used to assemble the output of a C compiler. It takes the compiler about 0.1 seconds to turn 20K lines of C, into 80K lines of ASM. It has taken Nasm 40 or 25 seconds to process those lines (25 seconds using -O0 to minimise passes).

The latest version version takes 33/20 seconds. A welcome reduction, but still, IMO, far too long for the task, and still an annoyance. That test file is here:

https://github.com/bartg/langs/blob/master/test.asm

(click in View Raw to see the text then perhaps copy and paste. It's 80,000 lines and 1.3MB).

I ran Nasm on an Intel 3.2GHz 64-bit machine with 4GB, using:

  nasm -fwin64 test.asm

Nasm does the job but it just takes a magnitude or two longer than you might expect!

 2 
 on: April 27, 2017, 09:03:57 PM 
Started by akasei - Last post by Frank Kotler
I suppose...
Code: [Select]
struc RIZE_STRUCTURE_OBJECT
.x resb 8
.y resb 8
.width resb 8
.height resb 8
.state_address resb 8
endstruc

struc RIZE_STRUCTURE_WINDOW
.RIZE_STRUCTURE_OBJECT resb RIZE_STRUCTURE_OBJECT_size
.size resb 8
.width_virtual resb 8
.height_virtual resb 8
.status resb 1
.background_color resb 4
.border resb 1
.elements resb 8
.SIZE:                     resb 8 ;?
endstruc
Didn't I just answer this?

This is rather horrible, with ".size" and ".SIZE" as elements, plus "struc_name_size", but it ought to work(?). Untested!

Probably should note that you've just got a "typedef" here - no memory allocated for it/them as yet. Use "istruc" to initialize it/them or "resb ..._size" in section .bss.

Best,
Frank

EDIT: Ah, yes, here:
https://forum.nasm.us/index.php?topic=2325.0
I don't think this is exactly what Kazu wanted. May not be what you want either...

 3 
 on: April 27, 2017, 07:54:30 PM 
Started by akasei - Last post by akasei
Is it possible in some way to attach the structure to another?
eg.
Code: [Select]
struc RIZE_STRUCTURE_OBJECT
.x resb 8
.y resb 8
.width resb 8
.height resb 8
.state_address resb 8
endstruc

struc RIZE_STRUCTURE_WINDOW
RIZE_STRUCTURE_OBJECT
.size resb 8
.width_virtual resb 8
.height_virtual resb 8
.status resb 1
.background_color resb 4
.border resb 1
.elements resb 8
.SIZE:
endstruc

 4 
 on: April 26, 2017, 03:30:30 AM 
Started by droid - Last post by Johanno81
Funny how the interwebs works droid haha. Pretty much the same thing happend to me :). You guys really have something special here!

 5 
 on: April 24, 2017, 04:27:51 PM 
Started by Olsonist - Last post by Olsonist
This is only a warning and disassembling the resulting binary shows correct code.
I'm wondering what the warning is about.

SOLUTION FOUND! If I move foo: before the lea then the warning goes away.
Of course, I don't understand why and I guess I'm still wondering what the warning was about.
But the emitted code is correct and so this works for me.

This is on OSX 10.12.4 with nasm -f macho64 xxx.s -o xxx.o
nasm -v gives NASM version 2.12.02 compiled on Sep 14 2016

default         rel
      ...
      lea      RAX,[foo]
      ...
foo:   blah blah blah
      ...

With this code, I get warning: absolute address can not be RIP-relative.
However, disassembling the resulting binary with objdump:

   objdump -D -macho -x86-asm-syntax=intel -no-symbolic-operands xxx

the relevant instruction is:

   7022:       48 8d 05 10 00 00 00            lea   rax, [rip + 16]

and this indeed looks correct. It's exactly what I want to do. So what's up with the warning?
FWIW, I tried local labels (.foo) and they don't change the warning.
Also, foo is not declared global.

There is a manual section on absolute labels, ABSOLUTE: Defining Absolute Labels,
but nothing on relative labels.

 6 
 on: April 24, 2017, 05:02:44 AM 
Started by d3x0r - Last post by zolugynnav
The international online game development association took some steps for the development of this environment. I like this guide how to write a dissertation for your details.

 7 
 on: April 22, 2017, 01:58:27 PM 
Started by coldflame - Last post by coldflame
For anyone curious about what was wrong:

- something was wrong with alignment - I've changed all aligned MOV unstructions to unaligned ones and it works fine now.

 8 
 on: April 21, 2017, 10:16:35 PM 
Started by xjapan2 - Last post by Frank Kotler
If the code is stdcall, the procedure will end:
Code: [Select]
ret 10h
The caller shouldn't have to do anything at all to clean up the stack. Just comment out the "add esp, 10h". If it's taking 10 minutes to crash, this may not be the problem. Easy to try, anyway...

Best,
Frank


 9 
 on: April 21, 2017, 10:04:40 PM 
Started by xjapan2 - Last post by xjapan2
Thanks. I'm glad you like the Forum, but I doubt if we're going to be able to help you much. "Code is code", or so I like to claim, but syntax differs from one assembler to another. If your code is stdcall, trying to clean up the stack in the caller isn't going to work. That isn't a syntax issue.

Best,
Frank

I wanted to know how i clean the stack in this code? my knowledge in assembly is very limited  :(
I use this in a loop. and causes crash in 10 minutes, i would like to avoid it

I think i made the wrong use of the "add esp, 10h" :(

You can write in Nasm, i can convert to pascal.

 10 
 on: April 21, 2017, 08:42:36 PM 
Started by xjapan2 - Last post by Frank Kotler
Thanks. I'm glad you like the Forum, but I doubt if we're going to be able to help you much. "Code is code", or so I like to claim, but syntax differs from one assembler to another. If your code is stdcall, trying to clean up the stack in the caller isn't going to work. That isn't a syntax issue.

Best,
Frank


Pages: [1] 2 3 ... 10