Re: Slow nasm

Keith Kanios wrote:
There is a slight logical flaw going on here in assuming that NASM is
the problem. Has anyone ever stopped to think that maybe nagoa+.inc
isn't designed all that well???

One could, of course, examine it and determine if this is true, or not.

I've worked with nagoa+.inc before, and I've found it to be a pig of a
include file and a poor substitute for a real linker. Some like to use
it for direct PE processing or hackish DLL endeavors, but it is really
not worth it... and you lose out on being able to link with other
files.

True if you "%define ONLY_NASM". The example in question does not - uses Alink.

Just because your car has a trailer hitch, doesn't mean you should be
towing a cruise ship ;)

I'm not sure what the analog to the trailer hitch is. Nasm's got plenty of "towing capacity" - might have to downshift and go slow...

The Tasm version works. The Nasm version does not. Obviously, Nasm is emitting "bad code". This could be a bug in Nasm. It could be that Nasm is being *told* to emit bad code. I know which way *I'd* bet!

The use of nagoa+.inc, whether it's "efficient" or "correct" aside, results in code that can't easily be evaluated by looking at it. For example:

CONST ID_LBOX_EXPORTS, equ 102

Does the author of that code understand what code this generates? Not only a jump to the very next instruction, but a near jump! Even used as intended, it doesn't generate what I'd call "elegant" code. Betov complained about putting data in the middle of the code segment and jumping over it - a near jump, no less. I agree with him. I favor "small", generally, but I'll accept the bloat of adding an .rdata section, and putting my "write it in the middle of code" data *there*, in preference to putting it smack dab in the middle of the .text section and jumping over it, any day!

Well... that's just the particular beef that got me disgusted looking at the code... If Volcano seriously wants to get a working Nasm version of that code, the first thing I'd do is "de-macro-ize" it a little and put the instructions right out in front of our face so we can pick at it. No harm in including nagoa+.inc (or better) for the equates, but that code looks to me like it was written by someone who used the macros without really understanding 'em. I'd be willing to bet that's where the problem lies.

Best,
Frank
.

Relevant Pages

  • Re: Problem with NASM
    ... I am using the DOS versions of NASM which may be slighty older than the Win ... to use a CS segment override to access data in the DS segment, ... a lot of bootsectors that count on that, *without* the far jump. ... In a way, a bootsector isn't a good project for a beginner, although a lot of 'em want to do it - too hard to troubleshoot, and too easy to get something that works on "my machine" but isn't "generic". ...
    (alt.lang.asm)
  • Re: Rid of Multi-Pass
    ... accept this with the branch instruction? ... In practice, this proves an intolerable PITA, so Nasm picks a "default" if you don't specify. ... (the signed byte instructions are a different issue than the subject of this thread - jump optimization is ...
    (alt.lang.asm)
  • Re: edit box population in a dialog box (win32)
    ... NASM complains about the distance to the jump. ... Nasm shouldn't complain about a "jmp" unless you specify "jmp short target". ... Specifying the "-O" switch overrides this behavior, and Nasm chooses the size you need, as well as using "signed byte" forms of instructions that have such a form, if appropriate. ...
    (comp.lang.asm.x86)
  • Re: supporting multiple memory models in masm 3.0 and valarrow 1.00d
    ... I'd be delighted to see you choose Nasm - I think it's pretty well ... Supporting multiple memory models in Nasm isn't going to be too easy. ... ; indirect far jump ... jmp fword ptr roffs ...
    (alt.lang.asm)
  • Re: Most efficient - ADC or JNC
    ... I think jump tables are beautiful things but I'm ... branch prediction problem. ... I think I'm mixing up NASM and MASM syntax. ...
    (comp.lang.asm.x86)