Assembling takes literally forever

[mterwoord]

I'm working on a compiler, which outputs an asm file, which is being fed to nasm. This used to work, but larger changes i'm working on suddenly make Nasm eat all my cpu (well, 1 core), with a fixed memory usage. Is there any way to trace what's going on?

Thanks!

[mterwoord]

I'd be perfectly happy to share the .asm file that's giving the problems.

[mterwoord]

After a bunch of investigations, compilation actually does succeed, but after 5-7 minutes.

Once I add "near" to all conditional jumps, compilation goes down to 6-7 seconds.

[Frank Kotler]

Hi mterwoord,

Welcome to the forum.

"Literally forever" sounds like a bug, but how would you know, so soon?

Seriously, access to the "problem file" would probably help. As I recall, the forum won't let you attach a file on your first few posts. I would hate to suggest making a few "chit-chat" posts just to run the count up, but... whatever it takes. We'll find some way to make the file available, if you're willing.

Meanwhile, what "sort" of changes have been made since it worked? I assume the file is of finite size? Lots of jumps to optimize? Any other "odd" features to it?

Besides the "usual" tools, Nasm will let us limit to two passes (like the old days) with "-O0". We can report the number of passes with "-O99v" or such. We can "preprocess only" with "-e" (doesn't always work well). We can assemble preprocessed output with "-a". At one time, we could define "LOGALLOC" at compile time and log allocations and frees (huge output). None of these things will solve the problem, but "might" help figure out what's going on.

I haven't a clue at this point - sounds like it might be a bug.

Best,
Frank

P.S. Your last observation gives a clue...